In article <4035hm$g7s@ixnews7.ix.netcom.com>, rameshs@ix.netcom.com (Ramesh Seshadri ) writes:
|> I also like this feature. But in C++ if we link some features with
|> someother one finally we are ending up with some ambiguities. OK. Here
|> what should be the behaviour for the following code ?
|>
|> struct Base
|> {
|>     Base () { ... }
|>     Base (int) { ... }
|> }
|>
|> struct Derv : Base
|> {
|>     Derv () : Base () { ... }
|>     Derv (int nVal) : Derv (), Base (nVal) { ... }
|> }
|>
|> My question:
|>     What should happen when the Derv class ctor with int argument is
|>     getting called ?

It ought to result in a compile-time error.  If you want a different
constructor to be called, I would be very surprised if initialization
of base classes and data members were not done by the other
constructor.

---------------------------------------------------------------------
 Ed Osinski
 Computer Science Department, New York University
 E-mail:  osinski@cs.nyu.edu
---------------------------------------------------------------------
"No, no, no, don't tug on that. You never know what it might be attached to."
 -- Buckaroo Bonzai to assistant during brain surgery

In <3vqm8o$g7f@hrz-ws11.hrz.uni-kassel.de> Ralf Boecker
<boecker@hrz.uni-kassel.de> writes:
>
>page@cat.rpi.edu (Lance Page) wrote:
>>I often wish I could build A::A(some args...) from A::A(different
args...).
>>I propose (for discussion) allowing a constructor
>>Example: consider the class...
>>class A {
>>  int *ptr;
>>  int x;
>>  int y;
>> public:
>>  A()                     : ptr(0) {}
>>  A(int xval, int yval)   : ptr(0), x(xval), y(yval)     {}
>>  A(const A &from)        : ptr(0), x(from.x), y(from.y) {}
>>};
>>
>>// I would like be able to write the last constructor in terms of the
>>// previous one, i.e.:
>>  A(const A &from)        : A(from.x, from.y) {}
>>
>>Motivation:
>> ** Source code advantages:
>> If there are key requirements for constructors of this class,
>>   (e.g. initializing some special pointers or references), it is
>> error-prone and bulky to have to replicate these initializations in
all
>> the constructors.
>..
>
>I agree with You.
>But you should chose a better example, where the calling of
>base class / member c-tors performs aditional operations like
>new ore some calculations: You can easyly factor out
{}-initialization-code
>in some init() funktion (but resulting in one additional function call

>execution time penalty), but code for calling c-tors is normaly
replicated.
>You can only workaround this by introducing an additional derived
'padding'
>class whose c-tor will perform necessary calculations to be reused by
the
>final class c-tors. This is tedious.
>
>I could live without it, but I can see no reason, why this handsome
>feature should not be added to the standard.
>If anybody has one, I would like to know it.
>
>--
>*** Dipl.-Ing.  Ralf  Boecker    Universitaet GH Kassel
***
>*** eMail: boecker@hrz.uni-kassel.de  FB 16 - Elektrotechnik
***
>*** Tel: (+49)561/804-6404    Wilhelmshoeher Allee 73
***
>*** Fax: (+49)561/804-6360    D-34121 Kassel (Germany)
***
>
>

I also like this feature. But in C++ if we link some features with
someother one finally we are ending up with some ambiguities. OK. Here
what should be the behaviour for the following code ?

struct Base
{
    Base () { ... }
    Base (int) { ... }
}

struct Derv : Base
{
    Derv () : Base () { ... }
    Derv (int nVal) : Derv (), Base (nVal) { ... }
}

My question:
    What should happen when the Derv class ctor with int argument is
    getting called ?

- Ramesh.S
rameshs@ix.netcom.com

In article <4035hm$g7s@ixnews7.ix.netcom.com>, rameshs@ix.netcom.com (Ramesh Seshadri ) writes:
|> I also like this feature. But in C++ if we link some features with
|> someother one finally we are ending up with some ambiguities. OK. Here
|> what should be the behaviour for the following code ?
|>
|> struct Base
|> {
|>     Base () { ... }
|>     Base (int) { ... }
|> }
|>
|> struct Derv : Base
|> {
|>     Derv () : Base () { ... }
|>     Derv (int nVal) : Derv (), Base (nVal) { ... }
|> }
|>
|> My question:
|>     What should happen when the Derv class ctor with int argument is
|>     getting called ?

It ought to result in a compile-time error.  If you want a different
constructor to be called, I would be very surprised if initialization
of base classes and data members were not done by the other
constructor.

---------------------------------------------------------------------
 Ed Osinski
 Computer Science Department, New York University
 E-mail:  osinski@cs.nyu.edu
---------------------------------------------------------------------
"No, no, no, don't tug on that. You never know what it might be attached to."
 -- Buckaroo Bonzai to assistant during brain surgery

page@cat.rpi.edu (Lance Page) wrote:
>I often wish I could build A::A(some args...) from A::A(different args...).
>I propose (for discussion) allowing a constructor
>Example: consider the class...
>class A {
>  int *ptr;
>  int x;
>  int y;
> public:
>  A()                     : ptr(0) {}
>  A(int xval, int yval)   : ptr(0), x(xval), y(yval)     {}
>  A(const A &from)        : ptr(0), x(from.x), y(from.y) {}
>};
>
>// I would like be able to write the last constructor in terms of the
>// previous one, i.e.:
>  A(const A &from)        : A(from.x, from.y) {}
>
>Motivation:
> ** Source code advantages:
> If there are key requirements for constructors of this class,
>   (e.g. initializing some special pointers or references), it is
> error-prone and bulky to have to replicate these initializations in all
> the constructors.
..

I agree with You.
But you should chose a better example, where the calling of
base class / member c-tors performs aditional operations like
new ore some calculations: You can easyly factor out {}-initialization-code
in some init() funktion (but resulting in one additional function call
execution time penalty), but code for calling c-tors is normaly replicated.
You can only workaround this by introducing an additional derived 'padding'
class whose c-tor will perform necessary calculations to be reused by the
final class c-tors. This is tedious.

I could live without it, but I can see no reason, why this handsome
feature should not be added to the standard.
If anybody has one, I would like to know it.

--
*** Dipl.-Ing.  Ralf  Boecker    Universitaet GH Kassel     ***
*** eMail: boecker@hrz.uni-kassel.de  FB 16 - Elektrotechnik     ***
*** Tel: (+49)561/804-6404    Wilhelmshoeher Allee 73    ***
*** Fax: (+49)561/804-6360    D-34121 Kassel (Germany)   ***

> I often wish I could build A::A(some args...) from
> A::A(different args...).
> ...

All you sad sounds very reasonable.
Is it too late to submit a public comment?

I often wish I could build A::A(some args...) from A::A(different args...).

I propose (for discussion) allowing a constructor
for a class A to invoke another constructor of A in place of its base
class & member initializers.

Example: consider the class...
class A {
  int *ptr;
  int x;
  int y;
 public:
  A()                     : ptr(0) {}
  A(int xval, int yval)   : ptr(0), x(xval), y(yval)     {}
  A(const A &from)        : ptr(0), x(from.x), y(from.y) {}
};

// I would like be able to write the last constructor in terms of the
// previous one, i.e.:
  A(const A &from)        : A(from.x, from.y) {}

Motivation:
 ** Source code advantages:
 If there are key requirements for constructors of this class,
   (e.g. initializing some special pointers or references), it is
 error-prone and bulky to have to replicate these initializations in all
 the constructors.
 ** Object code savings:
 If A::A(int, int) was of significant size and not inlined, then
 A::A(const A&), whether inline or not, could reuse this object code.
 (When the data members are expensive to initialize and/or copy, it is
  not efficient for two constructors to share a non-ctor function to do
  the real work, because separate construct & copy operations are then
  performed on the data members.)

Limitations:
 ** It *may* be desirable to dictate that using this feature precludes
 using any other base class/ member initializers (i.e. before the '{')
 in this constructor.

Implementation:
 ** Seems obvious (to someone who has never implemented a compiler...)
 ** Normal declaration-order and inlining rules apply.


I suspect somebody's discussed this before, but I don't remember seeing
 it in D&E...
Discussion (or pointers to prior discussion)?.....

-Lance Page