Здравствуйте, Sni4ok, Вы писали:

S>да ты просто неудачник — если на такой вопрос ответить не смог.

ЭйчАр одной крупной инвестиционной компании при рассмотрении резюме кандидатов, половину всегда выбрасывал не рассматривая, приговаривая при этом — "Неудачники нам не нужны!"
(C)тарая шутка.

Здравствуйте, fGordon, Вы писали:

G>сабж.

G> просто вот както в жизни <привык не доверять таким вот "по умолчанию" методам>. <привык описывать, если они нужны, "ручками">.

Что-то я не понял зависимости между первым и вторым

Реально полезной привычкой, при определении плюсового класса, является немедленное помещение конструктора и операратора копирования в private секцию. Я, к примеру, приучил себя в 99.9% случаев писать так

class T
{
 private:
  typedef T     self_type;
 
  T(const self_type&);
  self_type& operator = (const self_type&);

 public:
  //Тут, типа, что-угодно
};//class T

Здравствуйте, Коваленко Дмитрий, Вы писали:

G>> просто вот както в жизни <привык не доверять таким вот "по умолчанию" методам>. <привык описывать, если они нужны, "ручками">.
КД>Что-то я не понял зависимости между первым и вторым
Что не понятного? Я опишу конструктор копии руками. Я не буду использовать конструктор копии "дефолтовый".
Как еще объяснить, я не знаю...

КД>Реально полезной привычкой, при определении плюсового класса, является немедленное помещение конструктора и операратора копирования в private секцию. Я, к примеру, приучил себя в 99.9% случаев писать так
Это уже частичный оффтопик

Здравствуйте, minorlogic, Вы писали:

КД>>Курите тему исключений и атомарного перевода объекта из одного состояния в другое.

M>Это вы мне решили викторину организовать ? при чем тут атомарность , при чем тут исключения ? Вопрос был довольно конкретным.

Какая викторина

В первом варианте на эти две вещи положен ... ну вообщем, понятно, что на них положили. А во втором случае, обеспечивается "все или ничего". То есть — либо мы полностью переведем объект в новое состояние, либо (в случае исключений при копировании членов) он сохранит свое старое состояние.

Поэтому второй вариант лучше.

Здравствуйте, fGordon, Вы писали:

G>>> просто вот както в жизни <привык не доверять таким вот "по умолчанию" методам>. <привык описывать, если они нужны, "ручками">.
КД>>Что-то я не понял зависимости между первым и вторым
G>Что не понятного? Я опишу конструктор копии руками. Я не буду использовать конструктор копии "дефолтовый".
G>Как еще объяснить, я не знаю...

Ну да. А если мне конструктор копирования не нужен, то "я не напишу его руками"? И, типа, возьму на себя ответственность, что в коде программы не возникнет ситуации, провоцирующей компилятор сгенерировать оный ?

КД>>Реально полезной привычкой, при определении плюсового класса, является немедленное помещение конструктора и операратора копирования в private секцию. Я, к примеру, приучил себя в 99.9% случаев писать так
G>Это уже частичный оффтопик

Факт

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, minorlogic, Вы писали:

M>>Почему воторой вариант лучше

КД>Курите тему исключений и атомарного перевода объекта из одного состояния в другое.

M>>и что делает функция swap ?

КД>Обмен состояний объектов. Типа std::swap, но в рамках конкретного класса.

Нет, ну Сатер конечно дядька умный, не спорю, только вот одно НО, это ж надо иметь тот самый

swap

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

template<class _Ty> inline
    void swap(_Ty& _Left, _Ty& _Right)
    {    // exchange values stored at _Left and _Right
    _Ty _Tmp = _Left;
    _Left = _Right, _Right = _Tmp;
    }

как видите она использует и конструктор копирования и оператор присваивания... т.е. её нельзя использовать для их реализации ибо выйдет рекурсия, надобно иметь свою собственную.. а что делать в своей собственной кроме

 this->a1 =  x.a1;
 this->a2 =  x.a2;
 this->a3 =  x.a3;
 this->a4 =  x.a4;

?

Вобщем описанный выше метод работает красиво и непритянуто за уши только если вы используете handle-body идиому... а Вы её в каждом классе используете? в каждом в котором нужен конструктор копирования???? неверю!

Здравствуйте, Коваленко Дмитрий, Вы писали:

G>>>> просто вот както в жизни <привык не доверять таким вот "по умолчанию" методам>. <привык описывать, если они нужны, "ручками">.
КД>>>Что-то я не понял зависимости между первым и вторым
G>>Что не понятного? Я опишу конструктор копии руками. Я не буду использовать конструктор копии "дефолтовый".
G>>Как еще объяснить, я не знаю...

КД>Ну да. А если мне конструктор копирования не нужен, то "я не напишу его руками"? И, типа, возьму на себя ответственность, что в коде программы не возникнет ситуации, провоцирующей компилятор сгенерировать оный ?

Ну да
Если он не нужен — то мне и не суть важно, сгенерирован он или нет. Если понадобится, я опишу его руками.

ЗЫ: к чему полемика то?

V> — слышал но ничего рассказать не могу
V> — а привести примеры реализации
V> — если я не могу рассказать про патерн то как по вашему я могу рассказать про его реализацию
V> — а подумать не хотите
V> — нет не хочу

V>вопрос — что такое полиморфизм знаете
V>ответ — что-то припоминаю, но толком рассказать не могу

Жжош
Извиняюсь, не удержался.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Реально полезной привычкой, при определении плюсового класса, является немедленное помещение конструктора и операратора копирования в private секцию. Я, к примеру, приучил себя в 99.9% случаев писать так

КД>

КД>class T
КД>{
КД> private:
КД>  typedef T     self_type;

А вот меня всегда интересовало, зачем делается такая штука?

Здравствуйте, superman, Вы писали:

S>Вобщем описанный выше метод работает красиво и непритянуто за уши только если вы используете handle-body идиому... а Вы её в каждом классе используете? в каждом в котором нужен конструктор копирования???? неверю!

Вообще говоря "в каждом где нужен оператор копирования"

Я там выше написал

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

Если объекты класса с оператором копирования живут очень долго, то стараюсь делать именно так

Если же ошибка копирования однозначно приводит к уничтожению объекта (например, при раскручивании стека во время исключения), то, ясный пфенинг, забиваю

---

Вообще говоря, эти мелочи ложаться в основу проектов / конструкций, от сложности которых рвет на Родину. Поэтому не стоит их игнорировать, считая бестолквыми глупостями.

Здравствуйте, Hottabych1, Вы писали: ...

К собеседованию нужно готовиться, как к экзамену. Синтетические задачи и вопросы имеют свою спицифику. Работая на настоящей работе можно за 5 лет не написать ни одного конструктора копирования, ни одного const метода, не описать ни одного указателя на функцию, тем более метод класса. Но экзаменатор, если не всю муть, то уж добрую половину точно припомнит. Так что перед сменой работы Страуструпа читать от корки до корки однозначно.

Здравствуйте, Olegator, Вы писали:

КД>>Реально полезной привычкой, при определении плюсового класса, является немедленное помещение конструктора и операратора копирования в private секцию. Я, к примеру, приучил себя в 99.9% случаев писать так

КД>>

КД>>class T
КД>>{
КД>> private:
КД>>  typedef T     self_type;
O>

O>А вот меня всегда интересовало, зачем делается такая штука?

Для поддержки китайской технологии copy&paste.

Или для того, чтобы сократить писанину в случае классов с километовыми именами.

Здравствуйте, fGordon, Вы писали:

G>Ну да
G>Если он не нужен — то мне и не суть важно, сгенерирован он или нет. Если понадобится, я опишу его руками.

G>ЗЫ: к чему полемика то?

К тому, что при профессиональном программировании на C++ такое не допустимо.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>К тому, что при профессиональном программировании на C++ такое не допустимо.

Какое недопустимо?
Объясните, что мне инкриминируется то?

Пример из жизни:
Есть класс, который делает чтото. Я не пишу конструктор копии. Он создается "атовматом". Ок, с этим все понятно.
По мере написания программы, мне захотелось использовать конструктор копии (КК) для этого класса. Я пишу его "в ручную" и делаю в нем какие то дополнительные фичи, необходимые мне и которые КК конечно же не сделает для меня сам, ибо он не умеет читать мысли
А допольнительные операции в КК приходится делать в 99% случаев, ибо это жизнь, а не теория.

Так где я чтото делаю "не профессионально"?

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, minorlogic, Вы писали:

КД>>>Курите тему исключений и атомарного перевода объекта из одного состояния в другое.

M>>Это вы мне решили викторину организовать ? при чем тут атомарность , при чем тут исключения ? Вопрос был довольно конкретным.

КД>Какая викторина

КД>В первом варианте на эти две вещи положен ... ну вообщем, понятно, что на них положили. А во втором случае, обеспечивается "все или ничего". То есть — либо мы полностью переведем объект в новое состояние, либо (в случае исключений при копировании членов) он сохранит свое старое состояние.

КД>Поэтому второй вариант лучше.

Понял , то есть вы хотите и дельше использовать объект в старом состоянии, если вы его не смогли изменить. Часто вам такая возможность нужна ?

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, minorlogic, Вы писали:

КД>>>Курите тему исключений и атомарного перевода объекта из одного состояния в другое.

M>>Это вы мне решили викторину организовать ? при чем тут атомарность , при чем тут исключения ? Вопрос был довольно конкретным.

КД>Какая викторина

КД>В первом варианте на эти две вещи положен ... ну вообщем, понятно, что на них положили. А во втором случае, обеспечивается "все или ничего". То есть — либо мы полностью переведем объект в новое состояние, либо (в случае исключений при копировании членов) он сохранит свое старое состояние.

КД>Поэтому второй вариант лучше.

Еще меня удивляет , как Вы обеспечите то , что swap не кинет исключения , если обычное почленное копирование такую возможность предусматривает, используется некий механизм ?

Я правильно понял что вы Сатера цытируете ?

Здравствуйте, fGordon, Вы писали:

G>Какое недопустимо?

Просто программеры часто придерживаются правила: что не запрещено, то разрешено. Т.е. другие программеры пользуя твой код могут просто не подозревать, что конструктор копирования — это лажа от компилятора, а не задуманная фича, и наломают дров, а потом тебе руки оторвут.
Если ты видишь, что конструктор по дефолту отработает нормально, то можно и не писать, а если не уверен, то лучше запретить от греха подальше, меньше проблем будет при работе в команде, да и сам не наступишь на свои грабли.

Здравствуйте, minorlogic, Вы писали:

КД>>Поэтому второй вариант лучше.

M>Понял , то есть вы хотите и дельше использовать объект в старом состоянии, если вы его не смогли изменить. Часто вам такая возможность нужна ?

Когда пишешь библиотечные вещи, насчет "как часто" не задумываешься

В реале — я очень часто пишу вещи которые именно так и работают. Причем речь идет не про одиночные объекты, а про целые хороводы. В основном, тема связана с базами данных.

Здравствуйте, Димчанский, Вы писали:

Д>Просто программеры часто придерживаются правила: что не запрещено, то разрешено. Т.е. другие программеры пользуя твой код могут просто не подозревать, что конструктор копирования — это лажа от компилятора, а не задуманная фича, и наломают дров, а потом тебе руки оторвут.
Д>Если ты видишь, что конструктор по дефолту отработает нормально, то можно и не писать, а если не уверен, то лучше запретить от греха подальше, меньше проблем будет при работе в команде, да и сам не наступишь на свои грабли.

Мне мои руки нравятся, не надо их отрывать
По сути, КК по умолчанию будет так и так, и без моих написаний кода...
Вобщем, обсуждение перешло в разряд "если бы...". Я все же при написании кода ориентируюсь, что последователи моего кода — разумные и профессиональные люди. Просто так в моей жизни сложилось...

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Здравствуйте, superman, Вы писали:

S>>Вобщем описанный выше метод работает красиво и непритянуто за уши только если вы используете handle-body идиому... а Вы её в каждом классе используете? в каждом в котором нужен конструктор копирования???? неверю!

КД>Вообще говоря "в каждом где нужен оператор копирования"

КД>Я там выше написал
КД>

КД>Правда в последнее время, мне в голову все чаще и чаще приходя мысли, что проектировать классы нужно так, чтобы у них вообще не было реализаций конструкторов и операторов копирования.

КД>

КД>Если объекты класса с оператором копирования живут очень долго, то стараюсь делать именно так

э.. уж простите за занудство, мысль не уловил, как это "именно так"? handle-body или "так проэктировать, чтобы у них вообще не было реализаций конструкторов и операторов копирования."? и что заначит живут долго? как на меня оно скорее зависит от того надо ли их копировать а не живут ли они долго.


КД>Вообще говоря, эти мелочи ложаться в основу проектов / конструкций, от сложности которых рвет на Родину. Поэтому не стоит их игнорировать, считая бестолквыми глупостями.
+1