In article <3lrbt6$anb@boson.epita.fr>, tregan_l@xenon.epita.fr (loic tregan) writes:

|>  I think that this extension is fully compatible with the actual standart.

But then ctor function call resolution would act differently than virtual function call resolution with the "hiding rule."  If you want a B(int) signature in B scope, you have to provide it.

--
Phil Staite
pstaite@vnet.ibm.com

   why the ctor are not inherited like othersfunctions :

   class A {
   public :
      A() {}
      A(int i) {}
   };

   class B : public A {
    public :
      B();
      B(float f) {};
   };

A a;      // ok
B b;      // ok
B b(3.);  // ok
B b(3);   // error  : I would like A(int) then B()



   what is the matter ? wouldn't C++ be more coherent (ctor inherited like
others functions ) ?  Very useful, isn't it ?

 I think that this extension is fully compatible with the actual standart.


--
Loic.Tregan@epita.fr thanks you to read him.
                ( yes, he told mee that the other day )
warnings : no C, no C++, no 386, no UNIX, no DOS, no Delphi, no Paradox

In article <3lrbt6$anb@boson.epita.fr>, tregan_l@xenon.epita.fr (loic tregan) says:
>
>   why the ctor are not inherited like othersfunctions :
>
>   class A {
>   public :
>      A() {}
>      A(int i) {}
>   };
>
>   class B : public A {
>    public :
>      B();
>      B(float f) {};
>   };
>
>A a;      // ok
>B b;      // ok
>B b(3.);  // ok
>B b(3);   // error  : I would like A(int) then B()

 With the present language features, you can still achieve what
you want to, for this last line in the code, namely to construct A
sub object in B using the integer that you pass. You have to add in a
constructor for B that looks like :

 B(int i) : A(i) {}

 -Madhavi Bhamidipati
 Texas Instruments (India) Limited.

In article <3lrmr0$51v@tilde.csc.ti.com> madhavi@india.ti.com (Madhavi Bhamidipati) writes:


   In article <3lrbt6$anb@boson.epita.fr>, tregan_l@xenon.epita.fr (loic tregan) says:
   >
   >   why the ctor are not inherited like othersfunctions :
   >
   >   class A {
   >   public :
   >      A() {}
   >      A(int i) {}
   >   };
   >
   >   class B : public A {
   >    public :
   >      B();
   >      B(float f) {};
   >   };
   >
   >A a;      // ok
   >B b;      // ok
   >B b(3.);  // ok
   >B b(3);   // error  : I would like A(int) then B()

    With the present language features, you can still achieve what
   you want to, for this last line in the code, namely to construct A
   sub object in B using the integer that you pass. You have to add in a
   constructor for B that looks like :

    B(int i) : A(i) {}

    -Madhavi Bhamidipati
    Texas Instruments (India) Limited.


I do not think this is correct. Your constructor assumes that the
B(); constructor is empty, which might not be the case. I do not know if
it is possible to make B(int) to execute the body of B() without having to
copy it?

On the other hand I doubt that it would be wise to to inherit constructors
in the way proposed by the original poster. C++ habbit of using single
argument constructors for type conversion is sometimes confusing, and
the unexpected popup of constructors not present in the definition of
B may add to the confusion.




























--

   ====         Best regards
     \\                              Jarand Roeynstrand
      \\                           DIG-hackers department
     \====\
  .,;,\    \                     EFI
,;;;;;;;;,_/     ____          N-7034 Trondheim
           |    |              Norway
           |    |
            \__/

Phone:  +47-73 59 72 75           Email: jr@efi.sintef.no

In article <3lrbt6$anb@boson.epita.fr>, tregan_l@xenon.epita.fr (loic tregan) says:
>
>   why the ctor are not inherited like othersfunctions :
>
>   class A {
>   public :
>      A() {}
>      A(int i) {}
>   };
>
>   class B : public A {
>    public :
>      B();
>      B(float f) {};
>   };
>
>A a;      // ok
>B b;      // ok
>B b(3.);  // ok
>B b(3);   // error  : I would like A(int) then B()
>
>
>
>   what is the matter ? wouldn't C++ be more coherent (ctor inherited like
>others functions ) ?  Very useful, isn't it ?
>
> I think that this extension is fully compatible with the actual standart.

Let's give B some actual content:

 class B : public A
 {
 char *data;
 public:
     B();
 };

 B b(3);

Note that b.data has not been initialized. That's why this code is not legal.
It permits too many accidents.
 -- Pete

In article <JR.95Apr4181610@efixid.efi.sintef.no>, Jarand.Roynstrand@efi.sintef.no says:
>
>In article <3lrmr0$51v@tilde.csc.ti.com> madhavi@india.ti.com (Madhavi Bhamidipati) writes:
>
>
>   In article <3lrbt6$anb@boson.epita.fr>, tregan_l@xenon.epita.fr (loic tregan) says:
>   >
>   >   why the ctor are not inherited like othersfunctions :
>   >
>   >   class A {
>   >   public :
>   >      A() {}
>   >      A(int i) {}
>   >   };
>   >
>   >   class B : public A {
>   >    public :
>   >      B();
>   >      B(float f) {};
>   >   };
>   >
>   >A a;      // ok
>   >B b;      // ok
>   >B b(3.);  // ok
>   >B b(3);   // error  : I would like A(int) then B()
>
>           With the present language features, you can still achieve what
>   you want to, for this last line in the code, namely to construct A
>   sub object in B using the integer that you pass. You have to add in a
>   constructor for B that looks like :
>
>           B(int i) : A(i) {}
>
>           -Madhavi Bhamidipati
>           Texas Instruments (India) Limited.
>
>
>I do not think this is correct. Your constructor assumes that the
>B(); constructor is empty, which might not be the case. I do not know if
>it is possible to make B(int) to execute the body of B() without having to
>copy it?

 In the example above, I arbitrarily made the body of B(int) empty. You have
to expliclty repeat the body of B() in B(int) if B(int) has to execute whatever
B() does.
 The other alternative is that you could have a private
member function for B that does initialization and this can be called by both B()
as well as B(int) constructors.

 class B
 {
  private :
  void init(void) { //common initialization,
      //initialize members of B or whatever }

  public :
  B() { init() ; }
  B( int i ) : A(i) { init() ; }
 } ;
>
>On the other hand I doubt that it would be wise to to inherit constructors
>in the way proposed by the original poster. C++ habbit of using single
>argument constructors for type conversion is sometimes confusing, and
>the unexpected popup of constructors not present in the definition of
>B may add to the confusion.

 I think that if constructors are allowed to be inherited, it leads to
serious problems in initializing a derived class object. There is a danger of
only the Base sub object of the child, getting initialized.

 -Madhavi Bhamidipati
 Texas Instruments (India) Limited.