Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата jack128 @ 12.02.13, 06:48

кстати, а в плюсах компиляторы кидают какие нить варнинги/ошибки, если конструктор не все поля объекта инициализирует ??

Эммм... Такого (по идее) быть не может. Для каждого поля будет либо Default Initialization, либо инициализация, заданная пользователем (в списке инициализации). Ну а насколько default initialization соответствует инварианту класса после конструирования - это головная боль программиста.

jack128, некоторые тонкости

Цитата trainer @ 12.02.13, 06:07

Он "чистенький" при условии, если 0 - это "чистенькое значение". А если нет - очень даже "грязненький".

Цитата Мяут-Настоящий @ 12.02.13, 06:36

Какой смысл для таких объектов в NewInstance, который будет гарантированно возвращать невалидный объект?

Во-первых, дефолтная инициализация нулями по любому лучше (по кр.мере предсказуеемее), чем случайный мусор. В дельфях она необходима, по кр.мере, для нетривиальных ссылочных мемберов (типа интерфейсов, дин.строк и дин.массивов), а также полезна для зануления всех прочих указателей (что делает возможным = более безопасным вызов деструктора в случае неполного создания объекта). Остается последний штрих к портрету - зачем связываться со сложной выборочной инициализацией, если можно быстро скопом занулить весь InstanceSize?

Во-вторых, в дельфях NewInsance\InitInsance это по сути "неявный" дефолтный конструктор, наследуемый от базового предка TObject. Но в отличие от С++ он вызывается всегда перед любым другим явно определенным конструктором. Поэтому говорить об инициализации какими-то "грязными" или "невалидными" значениями тут просто неуместно - это эквиваленто тому, что сетовать на оператор new, который может выдавать либо мусор, либо зануленный кусок памяти в зависимости от реализации. Ну и, как уже отмечалось, NewInstance это виртуальный метод, который при желании можно переопределить (хотя убрать предварительное обнуление нельзя, т.к. оно сидит в невиртуальном InitInstance)

Цитата leo @ 12.02.13, 08:47

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

Лучше все-таки корректные данные

Цитата

что делает возможным = более безопасным вызов деструктора в случае неполного создания объекта

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

Цитата

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

Эм. operator new отвечает за предоставление памяти требуемого размера. И ни за что больше

Цитата D_KEY @ 12.02.13, 09:12

Лучше все-таки корректные данные

Это мусор на стеке или после new - корректные данные?

Цитата D_KEY @ 12.02.13, 09:12

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

Возможная утечка памяти или ненужная супер-пупер инициализация чего-то - это хорошо? Или городить в сложном конструкторе многоэтажные try\except, фактически повторяющие в запутааном виде код деструктора - это тоже хорошо?

Цитата D_KEY @ 12.02.13, 09:12

Эм. operator new отвечает за предоставление памяти требуемого размера. И ни за что больше

1) Предварительный вызов NewInstance не отменяет вызова явного конструктора.
2) Гепотетическая ошибка в NewInstance равносильна ошибке на стадии выделения памяти в new и на "корректность\не_корректность" вообще не созданного объекта никак не влияет

Цитата leo @ 12.02.13, 09:26

Это мусор на стеке или после new - корректные данные?

Нет, корректные данные - это те, которые соответствуют инварианту сконструированного объекта.

Цитата

Возможная утечка памяти или ненужная супер-пупер инициализация чего-то - это хорошо?

Какие утечки? Не надо руками удалять память, кроме редких специальных случаев. "супер-пупер инициализация чего-то" - это о чем?

Цитата

Или городить в сложном конструкторе многоэтажные try\except, фактически повторяющие в запутааном виде код деструктора - это тоже хорошо?

Зачем? Ну если по другому не умеете, то да, это лучше, чем вызов деструктора для недостроенных объектов

Цитата D_KEY @ 12.02.13, 09:47

которые соответствуют инварианту сконструированного объекта.

А объект к этому моменту еще и не сконструирован

Цитата leo @ 12.02.13, 08:47

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

Можно, при желании. Никто ведь не запрещает в NewInstance вообще не вызывать дефолтный InitInstance и провести свою инициализацию на основании, скажем, атрибутов к полям. Хотя едва ли это кому-либо надо

Добавлено 12.02.13, 09:56

Цитата D_KEY @ 12.02.13, 09:47

Какие утечки?

Ну, создаю я в конструкторе внутренний объект... А потом происходит исключение. Мне специально предусмотреть код удаления этого объекта при исключении? А зачем? Ответсвенный за его удаление - мой сконструированный объект и именно он должен удалить его в своем деструкторе. Я на это и рассчитываю

Цитата --Ins-- @ 12.02.13, 09:54

А объект к этому моменту еще и не сконструирован

Я об общей картине. Сначала зануляете поля, потом что-то меняете. У нас же сразу вызываются конструкторы полей(а те вызывают конструкторы своих полей и т.д.)...

Добавлено 12.02.13, 09:58

Цитата --Ins-- @ 12.02.13, 09:54

Ну, создаю я в конструкторе внутренний объект... А потом происходит исключение. Мне специально предусмотреть код удаления этого объекта при исключении?

Цитата

А зачем?

class A
{
public:
    A()
        : b(new B(10, 20, "aaa"))
    {
        throw "aaaa";
    }
 
private:
    unique_ptr<B> b;
};

Как видишь, я вообще деструктор не пишу

Сообщение отредактировано: D_KEY - 12.02.13, 09:59

Цитата D_KEY @ 12.02.13, 09:56

Сначала зануляете поля, потом что-то меняете.

Да. Потому что эти действия разнесены во времени и в общем случае код InitInstance не может знать, какие значения у них должны быть. Кстати, 0/nil - корректное значение для любого типа. Но как уже сказал выше - с появлением атрибутов, можно в принципе сразу инициализировать поля нужными значениями без выноса этой инициализации в Create. Только нужно ли? Не такой уж и большой оверхид

Добавлено 12.02.13, 09:59

Цитата D_KEY @ 12.02.13, 09:56

Как видишь, я вообще деструктор не пишу

Потому что объект на стеке, да?

Цитата --Ins-- @ 12.02.13, 09:59

Потому что объект на стеке, да?

Ты new там не видишь? Нет, объект класса B создается в динамической памяти. У тебя ссылка неявная, у меня явная(я выбрал unique_ptr, т.к. не собираюсь шарить объект).

D_KEY, ну, поздравляю. А если сделать то, что ты предлагаешь в Delphi - получишь либо утечку, либо необходимость вручную ловить исключение в конструкторе.

Добавлено 12.02.13, 10:17

Цитата korvin @ 12.02.13, 03:58

А BeforeConstruction и AfterDestruction?

В каком-то смысле, NewInstance - это BeforeConstruction, а FreeInstance - AfterDestruction. Ну в крайнем случае при необходимости можешь сам завести такие методы и вызывать их из NewInstance/FreeInstance

Добавлено 12.02.13, 10:28

Цитата D_KEY @ 12.02.13, 09:47

Не надо руками удалять память

Вот и правильно, и не надо руками, деструктор за конструктором все сам почистит

Цитата MyNameIsIgor @ 12.02.13, 07:16

некоторые тонкости

жесть.

про new T()

Цитата

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

то есть

struct test {
  test() {}
  std:string s;
}
 
 
auto t = new test();

в t->s будет мусор???

Сообщение отредактировано: jack128 - 12.02.13, 10:38

Цитата jack128 @ 12.02.13, 10:37

в t->s будет мусор???

Нет. У строк дефолтный конструктор инициализирует ее пустой строкой

Цитата OpenGL @ 12.02.13, 10:56

Нет. У строк дефолтный конструктор инициализирует ее пустой строкой

то есть требуется инициализация только POD типов ?

Цитата jack128 @ 12.02.13, 11:02

то есть требуется инициализация только POD типов ?

Да.