Re[10]: паттерн "Мюнхгаузен"
От: Николай Ивченков  
Дата: 04.09.09 15:44
Оценка: +1
MasterZiv:

MZ>Ну по идее-то код конструктора (внутри скобок) == это уже пользовательский

MZ>код, не системный. Только программист знает, какое состояние объекта
MZ>у него валидное, а какое -- невалидное, соответственно он может написать
MZ>так, чтобы наш нещастный THROW был бы в том месте, где уже всё валидно,
MZ>например, в самом конце, перед скобкой. Ведь компилятор более ничего
MZ>уже не сгенерирует, никакого кода не будет (рассматриваем естественно
MZ>ситуацию БЕЗ НАСЛЕДНИКОВ, т.е. финальный класс).

Пока конструктор не отработал до конца, объект не считается созданным. Если объект в итоге так и не будет создан, то для него не вызовется деструктор (это значит, что успешность создания объекта компилятор по-любому должен как-то контролировать).
Re[10]: паттерн "Мюнхгаузен"
От: jazzer Россия Skype: enerjazzer
Дата: 04.09.09 15:45
Оценка:
Здравствуйте, remark, Вы писали:

R>Тут именно про сам объект говорится, а не про члены. И функции у него можно вызывать и typeid и dynamic_cast можно.

ага, только как ты внутри функций будешь к членам-данным обращаться? через this, других способов нету.
R>
R>12.6.2/9
R>Member functions (including virtual member functions, 10.3) can be called for an object under construction.
R>Similarly, an object under construction can be the operand of the typeid operator (5.2.8) or of a dynamic_-
R>cast (5.2.7). However, if these operations are performed in a ctor-initializer (or in a function called directly
R>or indirectly from a ctor-initializer) before all the mem-initializers for base classes have completed, the result
R>of the operation is undefined.
R>


Ну то есть ты не видишь здесь противоречия с тем, что сказано в главе "Object Lifetime"?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[11]: паттерн "Мюнхгаузен"
От: remark Россия http://www.1024cores.net/
Дата: 04.09.09 15:58
Оценка:
Здравствуйте, jazzer, Вы писали:

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


R>>Тут именно про сам объект говорится, а не про члены. И функции у него можно вызывать и typeid и dynamic_cast можно.

J>ага, только как ты внутри функций будешь к членам-данным обращаться? через this, других способов нету.
R>>
R>>12.6.2/9
R>>Member functions (including virtual member functions, 10.3) can be called for an object under construction.
R>>Similarly, an object under construction can be the operand of the typeid operator (5.2.8) or of a dynamic_-
R>>cast (5.2.7). However, if these operations are performed in a ctor-initializer (or in a function called directly
R>>or indirectly from a ctor-initializer) before all the mem-initializers for base classes have completed, the result
R>>of the operation is undefined.
R>>


J>Ну то есть ты не видишь здесь противоречия с тем, что сказано в главе "Object Lifetime"?


В 3.8/3 у меня сказано:

[ Note: in particular, before the lifetime of an object starts and after its lifetime ends
there are significant restrictions on the use of the object, as described below, in 12.6.2 and in 12.7. Also, the behavior of an object under construction and destruction might not be the same as the behavior of an object whose lifetime has started and not ended. 12.6.2 and 12.7 describe the behavior of objects during the construction and destruction phases. —end note ]




1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[11]: паттерн "Мюнхгаузен"
От: Николай Ивченков  
Дата: 04.09.09 16:36
Оценка: +1
jazzer:

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


R>>Тут именно про сам объект говорится, а не про члены. И функции у него можно вызывать и typeid и dynamic_cast можно.

J>ага, только как ты внутри функций будешь к членам-данным обращаться? через this, других способов нету.
R>>
R>>12.6.2/9
R>>Member functions (including virtual member functions, 10.3) can be called for an object under construction.
R>>Similarly, an object under construction can be the operand of the typeid operator (5.2.8) or of a dynamic_-
R>>cast (5.2.7). However, if these operations are performed in a ctor-initializer (or in a function called directly
R>>or indirectly from a ctor-initializer) before all the mem-initializers for base classes have completed, the result
R>>of the operation is undefined.
R>>


J>Ну то есть ты не видишь здесь противоречия с тем, что сказано в главе "Object Lifetime"?


Я уже как-то отмечал этот баг стандарта на другом форуме: http://forum.sources.ru/index.php?showtopic=213131&view=findpost&p=1785951

Вероятно, в 3.8 авторы хотели сказать что-то вроде "before the constructor begins execution, but after the storage which the object will occupy has been allocated or, after the destructor finishes execution and before the storage which the object occupied is reused or released [...]". Упоминание lifetime тут не к месту совершенно.
Re[8]: паттерн "Мюнхгаузен"
От: Erop Россия  
Дата: 04.09.09 17:23
Оценка: +1
Здравствуйте, anonim_44ax, Вы писали:

_>Неправда! terminate() будет только если такой деструктор будет вызван во время раскрутки стека вызванного другим исключением. И хотя подобная техника очень "плохо пахнет", думаю вполне можно бросать исключение из деструктора, который по мнению программиста не может быть вызван во время раскрутки стека :-Р


Прлблемва в том, что С++ имеет право копировать объект исключения в специально отведённую для этого область памяти (ведь стек-то будет разрушен?)
Вот деструктор этой копии и будет вызван из каких-то недр размотки стека. Так что UB в стандерте по этому поводу обещают по делу
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[2]: паттерн "Мюнхгаузен"
От: fay Украина www.bekhter.net
Дата: 04.09.09 20:32
Оценка:
Здравствуйте, Мурлакотам, Вы писали:

М>
М>if(somethingBad)
М>{
М>  FatalException();
М>  //вместо throw FatalException();
М>}
М>


М>=>


М>
М>class FatalException
М>{
М>public:
М>  FatalException()
М>  {
М>    throw *this; // :)
М>  }
М>};
М>


М>Вполне грамотный рефакторинг. Без вмешательства в код, использующий FatalException(), удалось добиться ожидаемого поведения предельно малой кровью. Но
throw *this;
конечно, улыбает, чего уж

А меня больше улыбнул брошенный "наполовину беременный" объект.
Исключение-то улетело из конструктора
Best regards,
Oleg Bekhter
Software Developer
Re[4]: паттерн "Мюнхгаузен"
От: Кодт Россия  
Дата: 07.09.09 11:20
Оценка:
Здравствуйте, Vamp, Вы писали:

V>Я только так и не понял, почему Мюнхгаузен? Тот таскал себя за косичку из болота, и летал на ядре — вроде, ничего не применимо?


Пусть топикстартер раскроет тайну
А вообще, что только Мюнхгаузен не делал чудесного. Например, стрельнул вишнёвой косточкой в лоб оленю...
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
http://files.rsdn.org/4783/catsmiley.gif Перекуём баги на фичи!
Re[5]: паттерн "Мюнхгаузен"
От: Rostislav_Pro  
Дата: 07.09.09 12:10
Оценка:
Здравствуйте, Кодт, Вы писали:

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


V>>Я только так и не понял, почему Мюнхгаузен? Тот таскал себя за косичку из болота, и летал на ядре — вроде, ничего не применимо?


К>Пусть топикстартер раскроет тайну

К>А вообще, что только Мюнхгаузен не делал чудесного. Например, стрельнул вишнёвой косточкой в лоб оленю...

Ну вроде очевидно — барон сам себя поднимал за волосы, здесь же исключение бросает само себя. Хватает себя изнутри за конструктор и бросает
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.