Временные таблицы связываются с сессией, поэтому если различные пользователи выполняют Вашу процедуру одновременно нет никакого конфликта...
Из связанного (но не того же) вопроса - Почему компиляторы C ++ не определяют operator == и operator! =? :
Страуструп сказал это о конструктор копирования по умолчанию в "Проектировании и развитии C ++" (Раздел 11.4.1 - Контроль копирования):
Я лично считаю неудачным, что операции копирования определены по умолчанию, и я запрещаю копирование объектов многих моих классов. Однако C ++ унаследовал свои конструкторы присваивания и копирования по умолчанию от C, и они часто используются.
Итак, ответ состоит в том, что он был включен неохотно Страуструпом для обратной совместимости с C (вероятно, причина большинства недостатков C ++, но также вероятно, основная причина популярности C ++).
Для моих собственных целей,
Из Язык программирования C ++ , раздел 11.3.4 Копирование
... для типов, для которых конструктор копирования по умолчанию имеет правильную семантику, я предпочитаю полагаться на что по умолчанию. Это менее многословно, чем все, что я могу написать, и люди должны понимать значение по умолчанию. Также компиляторы знают о дефолте и возможностях его оптимизации. Кроме того, написание поэлементной копии вручную утомительно и подвержено ошибкам для классов с большим количеством членов-данных.
В принципе, я читал это, поскольку конструктор копирования по умолчанию экономит вам усилия, избавляет от ошибок, вызванных утомлением, и помогает оптимизировать ваш код, устраняя соблазн оптимизировать его вручную (позволяя компилятору делать это).
Потому что иначе, когда вы передадите экземпляр по значению, как компилятор мог его создать?
Я не знаю, почему он изначально был разработан таким образом. Но как пользователь я могу сказать, почему я рад, что они это сделали.
Я так же отношусь к умолчанию оператор присваивания. Большинство людей либо а) неправильно определяют свой конструктор копирования / оператор равенства или не поддерживают его. Я устранил множество ошибок в коде C ++, переключившись на типы RAII и удалив операторы / конструкторы копирования вручную.
Несколько моментов:
Важно иметь возможность контролировать, можно или нельзя копировать объект.
Если вы не хотите, чтобы объект можно было скопировать, тогда вы можете объявить конструктор копирования закрытым (а в C ++ 0x вы сможете сказать = delete
). Это не изменилось с вашим предложением, однако проблема просто обратная, т.е. можно предвидеть такой вопрос: «Почему компилятор не генерирует конструктор копирования по умолчанию, когда он знает, что делать?»
Это также будет рассмотрено в C ++ 0x, поскольку я считаю, что существует = default
флаг, который позволит вам указать его:
class C {
public:
C (C const &) = default;
};
It ' Это полезно, поскольку позволяет компилятору реализовать наилучшую возможную версию конструктора копирования.
Помимо простоты использования, сегодня компилятор может выбрать наиболее эффективный метод копирования объекта. Например, он может просто использовать memcpy с объектом, если он знает, что это безопасно.
Согласно вашему предложению, для достижения подобной оптимизации сегодня компилятору потребуется проанализировать тело конструктора чтобы убедиться, что он ничего не делает, кроме неглубокого копирования всех членов. Мало того, что это нетривиально, это обычно может произойти только тогда, когда тело конструктора видно всем единицам перевода.
В C ++ 0x = default
обходится без этого.
Я не удивлюсь, если для C ++ 0x компиляторы и инструменты статического анализа начнут генерировать предупреждения о "
Экономите ваше время? Если у вас есть простой класс (т.е. если вы можете легко скопировать конструкцию всех его элементов), вам не нужно писать его.
Если у вас есть struct
, используемая кодом C, для сохранения семантики копирования структур C.
Я не уверен, что это за «официальная линия» (у меня нет книги Strastroup рядом со мной), и я уверен, что кто-то откопает ее.
Однако в большинстве случаев случаях неглубокие копии и инициализация по умолчанию "достаточно хороша", поэтому Лучше, если компилятор предоставит их, чем если разработчик будет писать их явно.
Если разработчик написал эти тривиальные конструкторы копирования, а поля позже изменятся, то пользователь должен будет внести изменения, и в случае его забывания могут возникнуть серьезные ошибки (например, из чего состоят эти поля?).
Если пользователи будут писать конструкторы копирования только тогда, когда действительно необходимо сделать что-то необычное (например, глубокое копирование), вы уменьшите частоту этих ошибок.
Поскольку C ++ не собирает мусор, он заставляет вас отслеживать всех владельцев указателей, что на практике невозможно сделать, если вы не упростите проблему, используя большое количество копий повсюду так что, по крайней мере, вы знаете, кому принадлежит копия, и, кстати, делает вашу программу медленнее, чем программа со сборкой мусора. Автоматически сгенерированные конструкторы копирования - это гвоздь в гроб, который был вставлен, чтобы скрыть зияющую дыру к черту, которая является новой и удаленной.
Я думаю, вы идете с неверного направления - если бы компилятор мог написать полное и правильное ' конструктор копирования по умолчанию для каждого класса или структуры, тогда никто не будет жаловаться, не так ли? Проблема в том, что компилятор не может сделать это надежно, поэтому для таких случаев вам нужно написать свое собственное, переопределив значение по умолчанию.