MasterZiv:
MZ>Ну по идее-то код конструктора (внутри скобок) == это уже пользовательский MZ>код, не системный. Только программист знает, какое состояние объекта MZ>у него валидное, а какое -- невалидное, соответственно он может написать MZ>так, чтобы наш нещастный THROW был бы в том месте, где уже всё валидно, MZ>например, в самом конце, перед скобкой. Ведь компилятор более ничего MZ>уже не сгенерирует, никакого кода не будет (рассматриваем естественно MZ>ситуацию БЕЗ НАСЛЕДНИКОВ, т.е. финальный класс).
Пока конструктор не отработал до конца, объект не считается созданным. Если объект в итоге так и не будет создан, то для него не вызовется деструктор (это значит, что успешность создания объекта компилятор по-любому должен как-то контролировать).
Здравствуйте, 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, Вы писали:
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 ]
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 авторы хотели сказать что-то вроде "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 тут не к месту совершенно.
Здравствуйте, anonim_44ax, Вы писали:
_>Неправда! terminate() будет только если такой деструктор будет вызван во время раскрутки стека вызванного другим исключением. И хотя подобная техника очень "плохо пахнет", думаю вполне можно бросать исключение из деструктора, который по мнению программиста не может быть вызван во время раскрутки стека :-Р
Прлблемва в том, что С++ имеет право копировать объект исключения в специально отведённую для этого область памяти (ведь стек-то будет разрушен?)
Вот деструктор этой копии и будет вызван из каких-то недр размотки стека. Так что UB в стандерте по этому поводу обещают по делу
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
М>Вполне грамотный рефакторинг. Без вмешательства в код, использующий FatalException(), удалось добиться ожидаемого поведения предельно малой кровью. Но
throw *this;
конечно, улыбает, чего уж
А меня больше улыбнул брошенный "наполовину беременный" объект.
Исключение-то улетело из конструктора
Здравствуйте, Vamp, Вы писали:
V>Я только так и не понял, почему Мюнхгаузен? Тот таскал себя за косичку из болота, и летал на ядре — вроде, ничего не применимо?
Пусть топикстартер раскроет тайну
А вообще, что только Мюнхгаузен не делал чудесного. Например, стрельнул вишнёвой косточкой в лоб оленю...
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Vamp, Вы писали:
V>>Я только так и не понял, почему Мюнхгаузен? Тот таскал себя за косичку из болота, и летал на ядре — вроде, ничего не применимо?
К>Пусть топикстартер раскроет тайну К>А вообще, что только Мюнхгаузен не делал чудесного. Например, стрельнул вишнёвой косточкой в лоб оленю...
Ну вроде очевидно — барон сам себя поднимал за волосы, здесь же исключение бросает само себя. Хватает себя изнутри за конструктор и бросает
Перекуём баги на фичи!
