inheriting constructos

[Sean Kelly]

Michel Fortin Wrote:

> On 2009-11-29 18:03:40 -0500, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
> > Walter and I just discussed the matter of inheriting constructors. Our 
> > thought on the issue:
> > 
> > a) If a class doesn't define any constructors and adds no fields, 
> > inherit constructors. Example:
> > 
> > class MyException : Exception {}
> > 
> > b) If a class defines at least one constructor, do not inherit constructors.
> > 
> > c) If a class doesn't define any constructors but does add at least a 
> > non-static field -> undecided.
> > 
> > What do you think?
> 
> Objective-C has 'a' and 'c' acting like 'a'. There's no 'b' though, and 
> this is a small annoyance, as "constructors" in Objective-C are just 
> normal methods with a name that starts with "init".
> 
> Personally, I'd say adding a field to a class shouldn't affect its 
> constructor. If you need to initialize the field at object's 
> construction, then you add a constructor. But otherwise, if you don't 
> need to initialize it at construction (which happens fairly often when 
> fields are zeroed anyway), then you can certainly inherit super's 
> constructors.
> 
> In fact, I find it hard to see a justification for making adding a 
> field break constructor inheritance. My experience with Objective-C 
> tells me that 'c' acting like 'a' wouldn't be a problem at all because 
> D, just like Objective-C, initializes all fields to a default value 
> anyway. You only need a constructor when you want a non-default value 
> in a field.

I would hope that explicit out-of-ctor initialization would be allowed too:

class A : B
{
    // inherit B's ctors

    int x = 5;
}

Are there any instances where that calls an invisible ctor instead of just altering the init blob?