Почему компилятор обеспечивает, значение по умолчанию копируют конструктора

Временные таблицы связываются с сессией, поэтому если различные пользователи выполняют Вашу процедуру одновременно нет никакого конфликта...

11
задан mahesh 30 September 2009 в 15:05
поделиться

10 ответов

Из связанного (но не того же) вопроса - Почему компиляторы C ++ не определяют operator == и operator! =? :

Страуструп сказал это о конструктор копирования по умолчанию в "Проектировании и развитии C ++" (Раздел 11.4.1 - Контроль копирования):

Я лично считаю неудачным, что операции копирования определены по умолчанию, и я запрещаю копирование объектов многих моих классов. Однако C ++ унаследовал свои конструкторы присваивания и копирования по умолчанию от C, и они часто используются.

Итак, ответ состоит в том, что он был включен неохотно Страуструпом для обратной совместимости с C (вероятно, причина большинства недостатков C ++, но также вероятно, основная причина популярности C ++).

Для моих собственных целей,

27
ответ дан 3 December 2019 в 01:00
поделиться

Из Язык программирования C ++ , раздел 11.3.4 Копирование

... для типов, для которых конструктор копирования по умолчанию имеет правильную семантику, я предпочитаю полагаться на что по умолчанию. Это менее многословно, чем все, что я могу написать, и люди должны понимать значение по умолчанию. Также компиляторы знают о дефолте и возможностях его оптимизации. Кроме того, написание поэлементной копии вручную утомительно и подвержено ошибкам для классов с большим количеством членов-данных.

В принципе, я читал это, поскольку конструктор копирования по умолчанию экономит вам усилия, избавляет от ошибок, вызванных утомлением, и помогает оптимизировать ваш код, устраняя соблазн оптимизировать его вручную (позволяя компилятору делать это).

8
ответ дан 3 December 2019 в 01:00
поделиться

Потому что иначе, когда вы передадите экземпляр по значению, как компилятор мог его создать?

6
ответ дан 3 December 2019 в 01:00
поделиться

Я не знаю, почему он изначально был разработан таким образом. Но как пользователь я могу сказать, почему я рад, что они это сделали.

  1. Если вы используете все типы RAII или POD, конструктор копирования будет делать все правильно.
  2. Конструкторы копирования не требуют обдумывания или обслуживания, они просто работают, учитывая № 1

Я так же отношусь к умолчанию оператор присваивания. Большинство людей либо а) неправильно определяют свой конструктор копирования / оператор равенства или не поддерживают его. Я устранил множество ошибок в коде C ++, переключившись на типы RAII и удалив операторы / конструкторы копирования вручную.

3
ответ дан 3 December 2019 в 01:00
поделиться

Несколько моментов:

Важно иметь возможность контролировать, можно или нельзя копировать объект.

Если вы не хотите, чтобы объект можно было скопировать, тогда вы можете объявить конструктор копирования закрытым (а в C ++ 0x вы сможете сказать = delete ). Это не изменилось с вашим предложением, однако проблема просто обратная, т.е. можно предвидеть такой вопрос: «Почему компилятор не генерирует конструктор копирования по умолчанию, когда он знает, что делать?»

Это также будет рассмотрено в C ++ 0x, поскольку я считаю, что существует = default флаг, который позволит вам указать его:

class C {
public:
  C (C const &) = default;
};

It ' Это полезно, поскольку позволяет компилятору реализовать наилучшую возможную версию конструктора копирования.

Помимо простоты использования, сегодня компилятор может выбрать наиболее эффективный метод копирования объекта. Например, он может просто использовать memcpy с объектом, если он знает, что это безопасно.

Согласно вашему предложению, для достижения подобной оптимизации сегодня компилятору потребуется проанализировать тело конструктора чтобы убедиться, что он ничего не делает, кроме неглубокого копирования всех членов. Мало того, что это нетривиально, это обычно может произойти только тогда, когда тело конструктора видно всем единицам перевода.

В C ++ 0x = default обходится без этого.

Я не удивлюсь, если для C ++ 0x компиляторы и инструменты статического анализа начнут генерировать предупреждения о "

3
ответ дан 3 December 2019 в 01:00
поделиться

Экономите ваше время? Если у вас есть простой класс (т.е. если вы можете легко скопировать конструкцию всех его элементов), вам не нужно писать его.

1
ответ дан 3 December 2019 в 01:00
поделиться

Если у вас есть struct , используемая кодом C, для сохранения семантики копирования структур C.

должен присутствовать конструктор копирования по умолчанию.
1
ответ дан 3 December 2019 в 01:00
поделиться

Я не уверен, что это за «официальная линия» (у меня нет книги Strastroup рядом со мной), и я уверен, что кто-то откопает ее.

Однако в большинстве случаев случаях неглубокие копии и инициализация по умолчанию "достаточно хороша", поэтому Лучше, если компилятор предоставит их, чем если разработчик будет писать их явно.

Если разработчик написал эти тривиальные конструкторы копирования, а поля позже изменятся, то пользователь должен будет внести изменения, и в случае его забывания могут возникнуть серьезные ошибки (например, из чего состоят эти поля?).

Если пользователи будут писать конструкторы копирования только тогда, когда действительно необходимо сделать что-то необычное (например, глубокое копирование), вы уменьшите частоту этих ошибок.

0
ответ дан 3 December 2019 в 01:00
поделиться

Поскольку C ++ не собирает мусор, он заставляет вас отслеживать всех владельцев указателей, что на практике невозможно сделать, если вы не упростите проблему, используя большое количество копий повсюду так что, по крайней мере, вы знаете, кому принадлежит копия, и, кстати, делает вашу программу медленнее, чем программа со сборкой мусора. Автоматически сгенерированные конструкторы копирования - это гвоздь в гроб, который был вставлен, чтобы скрыть зияющую дыру к черту, которая является новой и удаленной.

0
ответ дан 3 December 2019 в 01:00
поделиться

Я думаю, вы идете с неверного направления - если бы компилятор мог написать полное и правильное ' конструктор копирования по умолчанию для каждого класса или структуры, тогда никто не будет жаловаться, не так ли? Проблема в том, что компилятор не может сделать это надежно, поэтому для таких случаев вам нужно написать свое собственное, переопределив значение по умолчанию.

0
ответ дан 3 December 2019 в 01:00
поделиться
Другие вопросы по тегам:

Похожие вопросы: