hi

Как я понимаю, C++ запрещает подобную конструкцию:

class Chained
{
public:
Chained()
{
_a = 1;
_b = 2;
}
Chained(int a) : Chained()
{
_a = a;
}
private:
int _a;
int _b;
};

Хотя Java разрешает.

Кто-нибудь знает почему так сделано?

Заранее спасибо за ответ,
seas

Здравствуйте, seas, Вы писали:

S>hi
S>Кто-нибудь знает почему так сделано?

Потому что (Януковича это не касается), можно сделать по-другому:

class Chained
{
public:
    Chained(int a=1, int b=2)
        : _a(a), _b(b)
    {
    }
};

Это все понятно.
Но смысл вопроса таков, почему нельзя именно использовать chained constructors.
Т.е. использовать один конструктор только как часть инициализации и
вызывать его из другого.

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

Что-то мешает такой реализации, какие-то соображения
эффектиновсти, параллельное программирование или еще чего?
Какие факторы на этапе проектирования языка заставили
принять именно это решение?

Здравствуйте, s_anatoli, Вы писали:

_>Здравствуйте, seas, Вы писали:

S>>hi
S>>Кто-нибудь знает почему так сделано?

_>Потому что (Януковича это не касается), можно сделать по-другому:
_>

_>class Chained
_>{
_>public:
_>    Chained(int a=1, int b=2)
_>        : _a(a), _b(b)
_>    {
_>    }
_>};
_>

Здравствуйте, seas, Вы писали:

S>Т.е. использовать один конструктор только как часть инициализации и
S>вызывать его из другого.
S>Что-то мешает такой реализации, какие-то соображения
S>эффектиновсти, параллельное программирование или еще чего?
S>Какие факторы на этапе проектирования языка заставили
S>принять именно это решение?

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

Здравствуйте, seas, Вы писали:


S>Кто-нибудь знает почему так сделано?

Потому что этой функциональности легко можно добится "стандартными" средствами:

class A
{
   void init() { ... }
public:
   A() { init(); }
   A(int n){ init(); /*other_initialization*/}
};

Здравствуйте, Bell, Вы писали:

B>Потому что этой функциональности легко можно добится "стандартными" средствами:

Небольшая ремарка: некоторые вещи можно проинициализировать только в конструкторе (инициализацию ссылок-членов класса, вызов конструкторов с параметрами членов классов). Их в отдельную функцию init не запихнёшь.

_>Потому что (Януковича это не касается), можно сделать по-другому:
_>

_>class Chained
_>{
_>public:
_>    Chained(int a=1, int b=2)
_>        : _a(a), _b(b)
_>    {
_>    }
_>};
_>

Не надо так делать. Значения по умолчанию в конструкторах есть зло. Из серии "Нам не дано предугадать...".

Здравствуйте, degor, Вы писали:

D>Не надо так делать. Значения по умолчанию в конструкторах есть зло. Из серии "Нам не дано предугадать...".

Вообще говоря, согласен. Но зло -- это отсутствие осторожности.
Разве мы перестаём пользоваться транспортом, поняв, что можем попасть в аварию?

Здравствуйте, seas, Вы писали:

S>Что-то мешает такой реализации, какие-то соображения
S>эффектиновсти, параллельное программирование или еще чего?
S>Какие факторы на этапе проектирования языка заставили
S>принять именно это решение?

Тоже было бы любопытно узнать. Обычно использую специальный метод для инициализационных действий, который вызывается из всех конструкторов, но это как-то "не по нашему"

D>>Не надо так делать. Значения по умолчанию в конструкторах есть зло. Из серии "Нам не дано предугадать...".

_>Вообще говоря, согласен. Но зло -- это отсутствие осторожности.
_>Разве мы перестаём пользоваться транспортом, поняв, что можем попасть в аварию?

Тут нужно много осторожности. Компилятор в праве использовать такой конструктор для неявного приведения, и вот тут нас ждут интересные эффекты.

Здравствуйте, degor, Вы писали:

D>Тут нужно много осторожности.

Осторожность нужна повсюду. Как бы ни старался коммитет по стандартизации, всё-равно в языке останутся грабли.
Ведь "на кожну ямку соломинки не знайдеться..."

Здравствуйте, BacCM, Вы писали:

BCM>Здравствуйте, seas, Вы писали:

S>>Что-то мешает такой реализации, какие-то соображения
S>>эффектиновсти, параллельное программирование или еще чего?
S>>Какие факторы на этапе проектирования языка заставили
S>>принять именно это решение?

BCM>Тоже было бы любопытно узнать. Обычно использую специальный метод для инициализационных действий, который вызывается из всех конструкторов, но это как-то "не по нашему"

Sun Workshop проглатывает

A::A()

, в VC++

this->A::A()

, gcc отвергает подобные шалости ))

Здравствуйте, seas, Вы писали:

S>hi

S>Как я понимаю, C++ запрещает подобную конструкцию:

...

S>Хотя Java разрешает.

S>Кто-нибудь знает почему так сделано?

Насколько я знаю, комитетом по стандартизации рассматривается предложение ввести такое в стандарт C++.

Здравствуйте, seas, Вы писали:

S>Что-то мешает такой реализации, какие-то соображения
S>эффектиновсти, параллельное программирование или еще чего?
S>Какие факторы на этапе проектирования языка заставили
S>принять именно это решение?

Помимо вашего кода в конструктор может содержать код инициализации указателя на таблицу виртуальных функций, etс. Не забывайте о множественном наследовании, наследовании с виртуальным базовым классом.. чего в java нет и в помине.. при этом внутреннее устройство "объекта" еще сложнее и сильно зависит от реализации. Наверно, автор и зарубил сабж. дабы не плодить неоднозначности и не усложнять реализацию.

Здравствуйте, s_anatoli, Вы писали:

_>Здравствуйте, degor, Вы писали:

D>>Тут нужно много осторожности.

_>Осторожность нужна повсюду. Как бы ни старался коммитет по стандартизации, всё-равно в языке останутся грабли.
_>Ведь "на кожну ямку соломинки не знайдеться..."

Так надо ударно потрудиться на полях нашей необъятной Родины, шоб всем хватило

Здравствуйте, Stepkh, Вы писали:

S>Так надо ударно потрудиться на полях нашей необъятной Родины, шоб всем хватило

Я же утверждаю другое: надо смотреть под ноги и ни на кого кроме себя не пенять, если всё-таки угодил.

A>Насколько я знаю, комитетом по стандартизации рассматривается предложение ввести такое в стандарт C++.

Первоисточник?

Здравствуйте, Igor Romanov, Вы писали:

A>>Насколько я знаю, комитетом по стандартизации рассматривается предложение ввести такое в стандарт C++.

IR>Первоисточник?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1581.pdf

A>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1581.pdf

thanks!

Здравствуйте, 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) {}
};

Надо будет поосторожней тогда с этой фичей обходиться
Или же придумают защиту от подобных конструкций ?