In article <4gognf$et@news.bridge.net>,
David Byrden  <100101.2547@compuserve.com> wrote:
><<<<<<<
>
>Why is it not allowed to delegate the initialisation to another
>constructor
>
>class X
>{
>public:
>    X (int i) : i_(i) {}
>
>    X () : X(34) {}             // Not allowed
>>>>>>>>>>
>
>
>     Why not use      X (int i = 34 ) : i_(i) {}

>[ I think he was concerned with the more general case of a complicated
>  initialization (not assignment) that must be repeated for each
>  constructor. -sdc, moderator
>]

Well, one could use a similar thing using a member function:

X (int i) { init(i); }
X () { init(34); }

where init is a member function for class X.

Anders
[ To submit articles: Try just posting with your newsreader.
        If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article gjm@sdaw04.seinf.abb.se, alindbac@sw.seisy.abb.se (Anders Lindback) writes:
>In article <4gognf$et@news.bridge.net>,
>David Byrden  <100101.2547@compuserve.com> wrote:
>><<<<<<<

>>Why is it not allowed to delegate the initialisation to another
>>constructor

>>class X
>>{
>>public:
>>    X (int i) : i_(i) {}
>>
>>    X () : X(34) {}             // Not allowed
>>>>>>>>>>>
>>
>>     Why not use      X (int i = 34 ) : i_(i) {}

>>[ I think he was concerned with the more general case of a complicated
>>  initialization (not assignment) that must be repeated for each
>>  constructor. -sdc, moderator
>>]

>Well, one could use a similar thing using a member function:
>
>X (int i) { init(i); }
>X () { init(34); }
>
>where init is a member function for class X.

That does not solve the *initialization* problem. Consider this example:

class X {
 const int i;
 ...
public:
 X() : i(0) { ... more stuff }
 X(int k) : i(k) { ... more stuff }
 X(const X& rhs) : i(rhs.i) { ... more stuff }
};

Because member 'i' is const, it cannot be assigned to, but must be
initialized. You cannot break out its initialization into a common
subroutine, but must repeat the initialization on every constructor.
In this toy example that is not a hardship, but suppose there were
many items, and each had a more complicated initialization.

Similarly, suppose 'i' were a class type that did not have a no-argument
constructor, or a reference. You would have to provide an initializer on
every constructor.

Finally, suppose 'i' were a class type that did have a no-argument
constructor, but you did not want the default initialization in
this class. You could let the default initialization occur then fix
up the value in a common subroutine. That approach is often wasteful,
particularly if it involves allocating and freeing memory, opening
and closing files, or setting and clearing locks.

I think the original question is really about a way to break out
a member-init-list into a common bit of code somehow, which cannot
currently be done. It seems to me it is (only) a convenience and ease-of-
maintenance issue.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ To submit articles: Try just posting with your newsreader.  If that fails,
                      use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

alindbac@sw.seisy.abb.se (Anders Lindback) writes:

>> Why is it not allowed to delegate the initialisation to another
>> constructor
>>
>> class X
>> {
>> public:
>> X (int i) : i_(i) {}
>>
>> X () : X(34) {}             // Not allowed

> Well, one could use a similar thing using a member function:

> X (int i) { init(i); }
> X () { init(34); }

> where init is a member function for class X.

The problem is that member functions can't initialize anything.  Often
this is just a minor nuisance: the X ctor calls the default ctor of
the data member, which gets then immediately overwritten by assignment
in init().  But you can't use this technique when you deal with const
and reference members.  Thus the syntax "X () : X(34) {}" would still
be useful.  Has anyone written a proposal?
[ To submit articles: Try just posting with your newsreader.
        If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Anders Lindback writes:

> David Byrden  <100101.2547@compuserve.com> wrote:

>> Why is it not allowed to delegate the initialisation to another
>> constructor?

> Well, one could use a similar thing using a member function:

> X (int i) { init(i); }
> X () { init(34); }

> where init is a member function for class X.

Not if you  have to initialize base  classes or references,  or member
objects without default constructors.
--
Alexandre Oliva
oliva@dcc.unicamp.br
Universidade Estadual de Campinas, S~ao Paulo, Brasil
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <4gsa2r$gjm@sdaw04.seinf.abb.se>, alindbac@sw.seisy.abb.se wrote:

<< In article <4gognf$et@news.bridge.net>,
<< David Byrden  <100101.2547@compuserve.com> wrote:
<< ><<<<<<<
<< >
<< >Why is it not allowed to delegate the initialisation to another
<< >constructor
<< >
<< >class X
<< >{
<< >public:
<< >    X (int i) : i_(i) {}
<< >
<< >    X () : X(34) {}             // Not allowed
<< >>>>>>>>>>
<< >
<< >
<< >     Why not use      X (int i = 34 ) : i_(i) {}
<<
<< >[ I think he was concerned with the more general case of a complicated
<< >  initialization (not assignment) that must be repeated for each
<< >  constructor. -sdc, moderator
<< >]
<<
<< Well, one could use a similar thing using a member function:
<<
<< X (int i) { init(i); }
<< X () { init(34); }
<<
<< where init is a member function for class X.
<<

Not very useful for const or reference data members ( here, useful ==
can't be done without explicitly initializing them, but than you "init"
will do only half the work )

My inclination, although I rarly use const or reference data members, will
be to wrap those data members in an internal structure with it's own
constructor :

class A_Class_With_A_Const_Or_Refs {
    A_Class_With_A_Const_Or_Refs(long& l);
    struct internal_Data {
        long& mLong;
        const long mClassID; // when there was no RTTI, for instance
        internal_Data(long& inLong, const long inID);
        } mInternalData;
    };

A_Class_With_A_Const_Or_Refs::A_Class_With_A_Const_Or_Refs(long& l) :
mInternalData(l, 'MYID') {}

and so on.

In my opinion, those cases will be very rare.

--
-- Etay Bogner
-- Etay_Bogner@mail.stil.scitex.com
-- Scitex Corp.
-- Israel.
--
-- There are two rules for success in life:
-- Rule 1:  Don't tell people everything you know.
--
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Why is it not allowed to delegate the initialisation to another=20
constructor, if that constructor is *the only thing* in the=20
member initialisation list?=20

It seems to me that in many cases, one could avoid some code=20
duplication and gain some clarity, at no conceptual or runtime cost.
The increased clarity would come from folding different constructor
cases into one case by calling the most general constructor in
the member initialisation list of the other constructors.
(I know this is not always clearer, but sometimes it is.)

Is it a case of: "Yes, it is basically a good idea, but it is too=20
late in the standardisation process. Anyway, we have to draw the
line somewhere."

Or is it more like: "Of course you should not do it that way, look here..=
."


A small example to illustrate the technical (not the conceptual)
detatils of my question:

#include <iostream.h>

class X
{
public:
    X (int i) : i_(i) {}

    X () : X(34) {}  // Not allowed

    int i() {return i_;}

private:
    int i_;
};



int
main ()
{
    X a(55);
    X b;

    cout << a.i() << ' ' << b.i() << endl;
}
=09

---
Jonas M=F6ls=E4, jbm@nada.kth.se

[ To submit articles: Try just posting with your newsreader.
        If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

<<<<<<<

Why is it not allowed to delegate the initialisation to another
constructor

class X
{
public:
    X (int i) : i_(i) {}

    X () : X(34) {}             // Not allowed
>>>>>>>>>


     Why not use      X (int i = 34 ) : i_(i) {}


                      David

[ I think he was concerned with the more general case of a complicated
  initialization (not assignment) that must be repeated for each
  constructor. -sdc, moderator
]
[ To submit articles: Try just posting with your newsreader.
        If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]