Это все понятно.
Но смысл вопроса таков, почему нельзя именно использовать chained constructors.
Т.е. использовать один конструктор только как часть инициализации и
вызывать его из другого.
Ведь помимо простейшей инициализации членов, конструктор может
содержать гораздо более сложный код.
Что-то мешает такой реализации, какие-то соображения
эффектиновсти, параллельное программирование или еще чего?
Какие факторы на этапе проектирования языка заставили
принять именно это решение?
Здравствуйте, s_anatoli, Вы писали:
_>Здравствуйте, seas, Вы писали:
S>>hi S>>Кто-нибудь знает почему так сделано?
_>Потому что (Януковича это не касается), можно сделать по-другому: _>
Здравствуйте, seas, Вы писали:
S>Т.е. использовать один конструктор только как часть инициализации и S>вызывать его из другого. S>Что-то мешает такой реализации, какие-то соображения S>эффектиновсти, параллельное программирование или еще чего? S>Какие факторы на этапе проектирования языка заставили S>принять именно это решение?
Прямого ответа я не знаю. Считаю, что использование параметров по-умолчанию позволяет добиться того же результата, что и использование цепочных конструкторов, то есть нет прямой надобности в них.
Если бы я разрабатывал компилятор, то был бы просто рад такой "горе с плеч".
Здравствуйте, Bell, Вы писали:
B>Потому что этой функциональности легко можно добится "стандартными" средствами:
Небольшая ремарка: некоторые вещи можно проинициализировать только в конструкторе (инициализацию ссылок-членов класса, вызов конструкторов с параметрами членов классов). Их в отдельную функцию init не запихнёшь.
Здравствуйте, seas, Вы писали:
S>Что-то мешает такой реализации, какие-то соображения S>эффектиновсти, параллельное программирование или еще чего? S>Какие факторы на этапе проектирования языка заставили S>принять именно это решение?
Тоже было бы любопытно узнать. Обычно использую специальный метод для инициализационных действий, который вызывается из всех конструкторов, но это как-то "не по нашему"
... Люди делятся на 10 категорий: те кто понимают двоичное исчисление и тех кто не понимает
D>>Не надо так делать. Значения по умолчанию в конструкторах есть зло. Из серии "Нам не дано предугадать...".
_>Вообще говоря, согласен. Но зло -- это отсутствие осторожности. _>Разве мы перестаём пользоваться транспортом, поняв, что можем попасть в аварию?
Тут нужно много осторожности. Компилятор в праве использовать такой конструктор для неявного приведения, и вот тут нас ждут интересные эффекты.
Здравствуйте, degor, Вы писали:
D>Тут нужно много осторожности.
Осторожность нужна повсюду. Как бы ни старался коммитет по стандартизации, всё-равно в языке останутся грабли.
Ведь "на кожну ямку соломинки не знайдеться..."
Здравствуйте, BacCM, Вы писали:
BCM>Здравствуйте, seas, Вы писали:
S>>Что-то мешает такой реализации, какие-то соображения S>>эффектиновсти, параллельное программирование или еще чего? S>>Какие факторы на этапе проектирования языка заставили S>>принять именно это решение?
BCM>Тоже было бы любопытно узнать. Обычно использую специальный метод для инициализационных действий, который вызывается из всех конструкторов, но это как-то "не по нашему"
Здравствуйте, seas, Вы писали:
S>Что-то мешает такой реализации, какие-то соображения S>эффектиновсти, параллельное программирование или еще чего? S>Какие факторы на этапе проектирования языка заставили S>принять именно это решение?
Помимо вашего кода в конструктор может содержать код инициализации указателя на таблицу виртуальных функций, etс. Не забывайте о множественном наследовании, наследовании с виртуальным базовым классом.. чего в java нет и в помине.. при этом внутреннее устройство "объекта" еще сложнее и сильно зависит от реализации. Наверно, автор и зарубил сабж. дабы не плодить неоднозначности и не усложнять реализацию.
Здравствуйте, s_anatoli, Вы писали:
_>Здравствуйте, degor, Вы писали:
D>>Тут нужно много осторожности.
_>Осторожность нужна повсюду. Как бы ни старался коммитет по стандартизации, всё-равно в языке останутся грабли. _>Ведь "на кожну ямку соломинки не знайдеться..."
Так надо ударно потрудиться на полях нашей необъятной Родины, шоб всем хватило
Здравствуйте, Igor Romanov, Вы писали:
A>>Насколько я знаю, комитетом по стандартизации рассматривается предложение ввести такое в стандарт C++.
IR>Первоисточник?
Здравствуйте, alexeiz, Вы писали:
A>Здравствуйте, Igor Romanov, Вы писали:
A>>>Насколько я знаю, комитетом по стандартизации рассматривается предложение ввести такое в стандарт C++.
IR>>Первоисточник?
A>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1581.pdf
А как будет работать наследование с этим ?
(Положим что можно вызывать конструкторы)
class A
{
int i;
public:
A() : A(0) {}
A(int x) : i(x) {}
};
class B : public A
{
int j;
public:
B() : A(0), B(0,0) {} // 2 раза вызов конструктора А ?
B(int x,int y) : A(x), j(y) {}
};
Надо будет поосторожней тогда с этой фичей обходиться
Или же придумают защиту от подобных конструкций ?
Здравствуйте, seas, Вы писали:
S>Это все понятно. S>Но смысл вопроса таков, почему нельзя именно использовать chained constructors. S>Т.е. использовать один конструктор только как часть инициализации и S>вызывать его из другого.В С++ это можно делать с помощью определений чистых виртуальных функций. С помощью того, же, кстати, можно реализовать идиому виртуального конструктора.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, alexeiz, Вы писали:
A>Здравствуйте, _nn_, Вы писали:
__>>Здравствуйте, alexeiz, Вы писали:
A>>>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1581.pdf
__>>А как будет работать наследование с этим ? __>>(Положим что можно вызывать конструкторы)
A>На первый взгляд всё кажется не сложно. Запрещаем вызов базового конструктора, если происходит делегирование.
A> ^^^^ — can't call base constructor if delegating constructor call exists
В таком случае надо чтобы в делегируемом конструкторе был вызов базового класса в нужной форме:
class A
{
int i;
public:
A() : A(0) {}
A(int x) : i(x) {}
};
class B : public A
{
int j;
public:
// B() : /*A(1),*/ B(0,0) {} // хотим A(1), а получим A(0)
B() : B(1,0) {} // не забыть какой параметр идет в базовый класс
B(int x,int y) : A(x), j(y) {}
};
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, seas, Вы писали:
S>>Это все понятно. S>>Но смысл вопроса таков, почему нельзя именно использовать chained constructors. S>>Т.е. использовать один конструктор только как часть инициализации и S>>вызывать его из другого.
В С++ это можно делать с помощью определений чистых виртуальных функций. С помощью того, же, кстати, можно реализовать идиому виртуального конструктора.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, _nn_, Вы писали:
__>Или же придумают защиту от подобных конструкций ?
Защита тривиальнейшая: конструктор либо выполняет работу (инициализирует базовые подобъекты и члены), либо делегирует (передает управление другому конструктору), но не то и другое одновременно.
Есть тонкость с разрушением. Допустим, имеем:
struct A
{
A() : A(100)
{
throw 0;
}
A(int n) :
{
m = new char[n];
}
~A()
{
delete[] m;
}
char* m;
}
int main()
{
A a;
}
Должен ли быть вызван деструктор A?
Я кончил, джентльмены, мне остается только поблагодарить вас за внимание.
Я кончил, джентльмены, мне остается только поблагодарить вас за внимание.
Re: Chained constructors
От:
Аноним
Дата:
26.10.04 12:10
Оценка:
Здравствуйте, seas, Вы писали:
S>hi
S>Как я понимаю, C++ запрещает подобную конструкцию:
S>class Chained S>{ S>public: S> Chained() S> { S> _a = 1; S> _b = 2; S> } S> Chained(int a) : Chained() S> { S> _a = a; S> } S>private: S> int _a; S> int _b; S>};
S>Хотя Java разрешает.
S>Кто-нибудь знает почему так сделано?
S>Заранее спасибо за ответ, S>seas
afik, дело в деструкторе
пример:
class Chained {
public:
Chained() { _a = 1; _b = 2; }
Chained(int a) : Chained() { _a = a; throw 1; }
~Chained() { cout << "Chained dtor" << endl; }
private:
int _a;
int _b;
};
class Other {
Chained member_;
public:
Other() : member_(4) {}
};
int main() {
try {
Other other;
// или Other* other = new Other; это неважно
} catch(...) {}
return 0;
}
вопрос: вызовется ли деструктор Chained?
переформулируя: был ли создан объект Chained?
N.B. В Java это допустимо, т.к. деструкторов нету
Re[5]: Chained constructors
От:
Аноним
Дата:
05.01.05 21:11
Оценка:
Здравствуйте, degor, Вы писали:
D>Тут нужно много осторожности. Компилятор в праве использовать такой конструктор для неявного приведения, и вот тут нас ждут интересные эффекты.
для предотвращения этих эффектов есть ключевое слово explicit
Здравствуйте, gribunin, Вы писали:
G>Небольшая ремарка: некоторые вещи можно проинициализировать только в конструкторе (инициализацию ссылок-членов класса, вызов конструкторов с параметрами членов классов). Их в отдельную функцию init не запихнёшь.