DMD 2.015 & DMD 1.031

> Но зато в D конструкторы базового типа нужно вызывать самому. Что черевато: 1) забыванием этого;

Вообще-то он напоминает. :) Что-то вроде "не могу понять, вызов какого конструктора суперкласса нужно здесь вставить автоматически"

2) обращением к методу базового класса до того, как конструктор базового класса отработает и установит корректные значения атрибутов базового класса (значения по умолчанию не всегда являются корректными).

"It is illegal to refer to "this" implicitly or explicitly prior to making a constructor call."

>>Далее из этого примера совершенно не видно, почему Widget не может получать контекст в конструкторе.

>А если он пользуется foo & bar?

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

>>объекты Foo, Bar и контекста инициализируются так же через некий postInit()/attach()?

>Контекст - скорее всего долгоживущий объект. Его надо было передавать через что-то с подсчетом ссылок наверно, с auto_ptr я промахнулся. Относительно Foo & Bar: это или структуры с полями или некие интерфейсы с виртуальными функциями. При отсутствии keyed parameters инициализировать десять полей структуры конструктором совершенно уныло. Для интерфейса вообще без разницы как был проинициализирован инстанс который с ним связан. Лучше конечно конструктора с параметрами там не делать чтобы не вынуждать людей которые будут его наследовать чесать репу "а что же нам передать в списке инициализации суперклассу?"

Не уловил смысла в данном параграфе. И не нашел ответа на вполне простой вопрос.

А для того, чтобы можно было удобно инициализировать объект разным количеством параметров есть несколько проверенных способов:

1. Группирование параметров в отдельной структуре (которая может содержать только указатели на параметры). Тогда объект можно будет создавать так: WidgetParams params; params.setFoo()...param.setContext(); Widget * w = new Widget(params);

2. Методы setter-ы могут возвращать ссылку на объект, что позволит записывать цепочку вызовов: WidgetParams().setFoo().setBar().setContext(). А это позволит писать, например, new Widget(WidgetParams().setFoo().setBar().setContext());

>>А если он пользуется foo & bar?

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

Бугага. Установили параметры foo & bar, вызвали attach, который безо всяких извращений зарегистрировал листенеры в этом инстансе воспользовавшись foo & bar. Но все равно это не труъ -> работать не будет.

>Группирование параметров в отдельной структуре (которая может содержать только указатели на параметры). Тогда объект можно будет создавать так: WidgetParams params; params.setFoo()...param.setContext(); Widget * w = new Widget(params);

Забыл третий класс - который Строуструпоугодно будет делать attach() из конструктора.

>И не нашел ответа на вполне простой вопрос.

Врешь. Ответ был: Конструкторы бессмыссленны и для структурообразных объектов несущих данные, и для полиморфных объектов.

>Забыл третий класс - который Строуструпоугодно будет делать attach() из конструктора.

Ну конечно, лучше по твоему, чтобы затем, как ты сам говоришь: "Но все равно это не труъ -> работать не будет."

Так за что боролись-то?

> "Конструкторы бессмыссленны и для структурообразных объектов несущих данные, и для полиморфных объектов"

Ты не поставил "(c) Absurd@LOR"

>Врешь. Ответ был: Конструкторы бессмыссленны и для структурообразных объектов несущих данные, и для полиморфных объектов.

И поэтому в 99% случаев конструкторы не используются. Но доказать это на примерах широкораспространенных библиотек (тех же Qt, ACE, Crypto++, Boost и пр.) ты не можешь.

Поэтому следует обвинить меня во вранье. Логично.

>> "Конструкторы бессмыссленны и для структурообразных объектов несущих данные, и для полиморфных объектов"

>Ты не поставил "(c) Absurd@LOR"

Кстати, а ты и вправду передаешь смарт-указатели по ссылке?

> Кстати, а ты и вправду передаешь смарт-указатели по ссылке?

Я их не передаю %) Но в общем да, когда нет передачи владения, я бы передал по ссылке.

>> Кстати, а ты и вправду передаешь смарт-указатели по ссылке?

>Но в общем да, когда нет передачи владения, я бы передал по ссылке.

А какой смысл использовать auto_ptr кроме как для передачи обекта по схеме исток->сток ? Т.е для in-параметров или возвращаемого значения? Если мы действуем локально в недрах своего кода, знаем что вызываемый код ничего с указателем делать не будет, т.к написан нами и не хотим неявных затрат на auto_ptr, то мы можем просто сделать ptr.get() и передать как простой указатель.

> А какой смысл использовать auto_ptr кроме как для передачи обекта по схеме исток->сток ?

ХЗ, но я не претендую на всезнание. Не говоря уже о том, что это могло быть ошибкой.

>> 2) обращением к методу базового класса до того, как конструктор
>> базового класса отработает и установит корректные значения атрибутов
>> базового класса (значения по умолчанию не всегда являются
корректными). 

> "It is illegal to refer to "this" implicitly or explicitly prior
> to making a constructor call."

Это явно не о том, о чем говорил я. Вот проверь сам:

import std.stdio;

class A {
	this() {
		m_i = 3;
	}

	void f() {
		writefln( "m_i=", m_i );
	}

	int m_i;
}

class B : A {
	this() {
		f();
		super();
		f();
	}
}

void main() {
	auto b = new B;
}

У меня на DMD 2.011 выдает:

m_i=0
m_i=3

Если для A.f() значение m_i == 0 не легально, то получим
ту проблему, о которой я говорил.

Логично. Потому что как раз в этой строчке: 

f(); // <-----
super();
f();

происходит неявное обращение к this до вызова конструктора суперкласса. Это ошибка.

>Не говоря уже о том, что это могло быть ошибкой.

Допускать ошибки в коде при спорах с плюсофилами?! Никогда вам не будет такого подарка.

>1) забыванием этого; 2) обращением к методу базового класса до того, как конструктор базового класса отработает и установит корректные значения атрибутов базового класса (значения по умолчанию не всегда являются корректными).

>В C++ этого нет.

И нет ничего взамен. Как это по-Строуструповски.

> Допускать ошибки в коде при спорах с плюсофилами?!

"Контекст - скорее всего долгоживущий объект. Его надо было передавать через что-то с подсчетом ссылок наверно, с auto_ptr я промахнулся"

> Никогда вам не будет такого подарка.

Почти смешно.

> происходит неявное обращение к this до вызова конструктора суперкласса. Это ошибка.

Но ни компилятор, ни run-time не бьет разработчика за это по рукам.

А в C++ такой ошибки нет в принципе. И это хорошо, т.к. я в Ruby пару раз на такие ситуации нарывался -- найти причину проблем не всегда просто.

>"Контекст - скорее всего долгоживущий объект. Его надо было передавать через что-то с подсчетом ссылок наверно, с auto_ptr я промахнулся"

Предсказуемо. Ну ладно, допустим контекст - это хэндл к настоящему долгоживущему объекту и управление счетчиком скрыто в нем.

> Предсказуемо.

Не в том дело. Я думал, ты умеешь признавать ошибки.

>А в C++ такой ошибки нет в принципе.

И конструктором невозможно пользоваться в принципе.

>И это хорошо, т.к. я в Ruby пару раз на такие ситуации нарывался -- найти причину проблем не всегда просто.

Может и сегфолтов в C++ нет в принципе? Найти причину тоже бывает непросто.

Эх, не зря заглянул - поднял настроение.
лулз.орг.ру форева.

>>А в C++ такой ошибки нет в принципе.

>И конструктором невозможно пользоваться в принципе.

Пока что виден только один факт: Absurd не может пользоваться конструктором в принципе.

А вот разработчики Qt могут, как и разработчики ACE, как и разработчик Crypto++, как и разработчик OTL. Список здесь можно продолжать очень долго.

>А вот разработчики Qt могут, как и разработчики ACE, как и разработчик Crypto++, как и разработчик OTL. Список здесь можно продолжать очень долго.

Ну мельком глянул я тут ACE для начала. Везде есть конструктор по умолчанию, а конструктору с параметрами как правило аккомпанирует open() с теми же параметрами. Могли бы конструкторов с параметрами в принципе и не делать. BTW Кто тут говорил про дублирование кода, которому противостоит RAII ?

>Ну мельком глянул я тут ACE для начала. Везде есть конструктор по умолчанию, а конструктору с параметрами как правило аккомпанирует open() с теми же параметрами. Могли бы конструкторов с параметрами в принципе и не делать.

Ну вот видишь, даже в ACE, который совсем уж в духе "C with classes" написан, проблем с конструкторами нет.

>BTW Кто тут говорил про дублирование кода, которому противостоит RAII ?

Понятия не имею. Я, по наивности, думал, что RAII к дублированию кода никакого отношения не имеет.