Здравствуйте, Bell, Вы писали:
B>Потому что этой функциональности легко можно добится "стандартными" средствами:
Небольшая ремарка: некоторые вещи можно проинициализировать только в конструкторе (инициализацию ссылок-членов класса, вызов конструкторов с параметрами членов классов). Их в отдельную функцию init не запихнёшь.
Здравствуйте, degor, Вы писали:
D>Тут нужно много осторожности.
Осторожность нужна повсюду. Как бы ни старался коммитет по стандартизации, всё-равно в языке останутся грабли.
Ведь "на кожну ямку соломинки не знайдеться..."
Это все понятно.
Но смысл вопроса таков, почему нельзя именно использовать chained constructors.
Т.е. использовать один конструктор только как часть инициализации и
вызывать его из другого.
Ведь помимо простейшей инициализации членов, конструктор может
содержать гораздо более сложный код.
Что-то мешает такой реализации, какие-то соображения
эффектиновсти, параллельное программирование или еще чего?
Какие факторы на этапе проектирования языка заставили
принять именно это решение?
Здравствуйте, s_anatoli, Вы писали:
_>Здравствуйте, seas, Вы писали:
S>>hi S>>Кто-нибудь знает почему так сделано?
_>Потому что (Януковича это не касается), можно сделать по-другому: _>
Здравствуйте, seas, Вы писали:
S>Т.е. использовать один конструктор только как часть инициализации и S>вызывать его из другого. S>Что-то мешает такой реализации, какие-то соображения S>эффектиновсти, параллельное программирование или еще чего? S>Какие факторы на этапе проектирования языка заставили S>принять именно это решение?
Прямого ответа я не знаю. Считаю, что использование параметров по-умолчанию позволяет добиться того же результата, что и использование цепочных конструкторов, то есть нет прямой надобности в них.
Если бы я разрабатывал компилятор, то был бы просто рад такой "горе с плеч".
Здравствуйте, seas, Вы писали:
S>Что-то мешает такой реализации, какие-то соображения S>эффектиновсти, параллельное программирование или еще чего? S>Какие факторы на этапе проектирования языка заставили S>принять именно это решение?
Тоже было бы любопытно узнать. Обычно использую специальный метод для инициализационных действий, который вызывается из всех конструкторов, но это как-то "не по нашему"
... Люди делятся на 10 категорий: те кто понимают двоичное исчисление и тех кто не понимает
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 не запихнёшь.