C++11 Feature Proposal: Delegated constructor

[Mounir Lamouri]

What:
Allow use of delegated constructor.

Why:
Improves code readability.

For example:

class Foo {
public:
explicit Foo(int a);
Foo(); // uses a default value for a

private:
int a_;
};

Without this feature, you would have to write:
Foo:Foo(int a) {
Init(a);
}
Foo::Foo() {
Init(kDefaultValue);
}
Foo::Init(int a) {
a_ = a;
}

With the feature enabled, you can write:
Foo::Foo(int a)
: a_(a) {
}
Foo::Foo()
: Foo(kDefaultValue) {
}

Not having to use Init() makes things more readable and more natural. It
also allows the members to be initialized in the initialization list
instead of a function.

-- Mounir

[Ryan Sleevi]

On Sep 24, 2014 3:29 AM, "Mounir Lamouri" <mou...@lamouri.fr> wrote:
>
> What:
> Allow use of delegated constructor.
>
> Why:
> Improves code readability.
>
> For example:
>
> class Foo {
> public:
>   explicit Foo(int a);
>   Foo(); // uses a default value for a

For sake of example/discussion, isn't this just default argument smuggling via a different route (e.g. something the style guide prohibits)?

I realize it's possible to do this today, but the Init() duplication is usually enough of a smell to trigger reviewers' Spidey sense.

>
> private:
>   int a_;
> };
>
> Without this feature, you would have to write:
> Foo:Foo(int a) {
>   Init(a);
> }
> Foo::Foo() {
>   Init(kDefaultValue);
> }
> Foo::Init(int a) {
>   a_ = a;
> }
>
> With the feature enabled, you can write:
> Foo::Foo(int a)
>     : a_(a) {
> }
> Foo::Foo()
>     : Foo(kDefaultValue) {
> }
>
> Not having to use Init() makes things more readable and more natural. It
> also allows the members to be initialized in the initialization list
> instead of a function.
>
> -- Mounir
>

> --
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
>     http://groups.google.com/a/chromium.org/group/chromium-dev

Note that the current style guide discourages complex work in constructors. The discussions of Init() and its reasonings are complex and lengthy, full of both pros and cons, but am I correct that you would see this as a way to de-Init() things that would otherwise have Init()?

I'm not trying to bait anything - I don't gave strong feelings one way or the other. But I do want to check what the end result may look like, and whether or not we want that.

[Hendrik]

The posted example might be a bit too simple.

Another contrived example:

struct A {

  string a;

  string b;

  A(string a, string b) : a(a), b(b) {}

  A() : a("a"), b("b") {}

};

Using an init function here would cause the string to be constructed empty, then assigned to the desired value -- less efficient.  It would also add another function which isn't needed.

I'm sure everyone here has run into the situation where they created more than one constructor and end up duplicating the default values.  This is error prone, someone may later change the default in one spot and miss the other.

It's hard to argue against using this feature.

+1

On Wednesday, September 24, 2014 3:45:28 AM UTC-7, Ryan Sleevi wrote:

> View archives, change email options, or unsubscribe:
>     http://groups.google.com/a/chromium.org/group/chromium-dev

[Viet-Trung Luu]

You're right that we shouldn't use delegated constructors to circumvent the rule on default arguments (and we should caution about that), but there are other valid use-cases.

Example 1: constructors for mostly orthogonal cases that nonetheless share some common initialization.

Example 2: delegating to a private constructor, which exists so that friended tests can mock out an internal implementation detail.

(A further advantage of delegated constructors, over e.g. a "CtorHelper()" method, is that it allows more members to be declared const where appropriate.)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Peter Kasting]

On Wed, Sep 24, 2014 at 3:44 AM, Ryan Sleevi <rsl...@chromium.org> wrote:

For sake of example/discussion, isn't this just default argument smuggling via a different route (e.g. something the style guide prohibits)?

The Google style guide explicitly allows default arguments in constructors.  The cons for default arguments it lists are mostly about what happens to code that takes function addresses and uses function pointers, and "Most of the cons listed above don't apply to constructors because it's impossible to take their address."  (More at http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Default_Arguments .)

Therefore, delegated constructors used to avoid default arguments are just fine, style-guide-wise.

I strongly support delegated constructors.  For classes with const members, using an Init() method to init the members is impossible.  Even for non-const members, most classes' constructors need to do simple work rather than what the style guide defines as complex work -- "call[ing] virtual functions or attempt[ing] to raise non-fatal failures" -- and delegated constructors eliminate copies of that boilerplate.  I've definitely written buggy code multiple times that failed to update all the constructors for a class when adding a member, and delegated constructors would help.

PK

[Vitaly Buka]

+1

[James Robinson]

On Wed, Sep 24, 2014 at 3:44 AM, Ryan Sleevi <rsl...@chromium.org> wrote:

For sake of example/discussion, isn't this just default argument smuggling via a different route (e.g. something the style guide prohibits)?

Constructors are already somewhat special in terms of the default argument rule since you can't pick the name of the constructor, like you can for other functions.

I think this feature would be pretty useful and don't see any real problems with it.

- James

[Maciej Pawlowski]

One thing a delegated ctor allows that an Init method doesn't is
constructing const members. We could not emulate this behavior with an
Init if the strings 'a' and 'b' were const.

I don't see why we wouldn't want this, can't come up with any real
drawbacks. So +1

W dniu 2014-09-24 17:40, Hendrik pisze:

> The posted example might be a bit too simple.
>
> Another contrived example:
>
> struct A {
> string a;
> string b;
>
> A(string a, string b) : a(a), b(b) {}
> A() : a("a"), b("b") {}
> };
>
> Using an init function here would cause the string to be constructed
> empty, then assigned to the desired value -- less efficient. It would
> also add another function which isn't needed.
>
> I'm sure everyone here has run into the situation where they created
> more than one constructor and end up duplicating the default values.
> This is error prone, someone may later change the default in one spot
> and miss the other.
>
> It's hard to argue against using this feature.
>
> +1
>

--
BR
Maciej Pawlowski
Opera Desktop Wroclaw

[Dana Jansens]

I know I've wanted this before. For example the 4 constructors of ResourceProvider::Resource could be simpler: https://code.google.com/p/chromium/codesearch#chromium/src/cc/resources/resource_provider.cc&l=209

--
--
Chromium Developers mailing list: chromi...@chromium.org

[Colin Blundell]

I propose that if the Google style guide allows a given C++11 feature that's currently supportable in Chromium across all platforms, the default should be that Chromium supports it. i.e., the argument would have to be made for disallowing it, not for allowing it.

~Colin

[Jeremy Roman]

To me, this seems like a stronger case for in-class member
initializers than delegated constructors. Then you could just say (in
the header):

int child_id = 0;
int gl_id = 0;
// ...

[Hendrik]

I'm not a big fan of in-class member initializers -- and I'll explain why when someone gets around to proposing them.

Don't get me wrong, I don't think they should be banned, but used in limited cases.

On Thursday, September 25, 2014 8:24:11 AM UTC-7, Jeremy Roman wrote:

To me, this seems like a stronger case for in-class member
initializers than delegated constructors. Then you could just say (in
the header):

int child_id = 0;
int gl_id = 0;
// ...

On Thu, Sep 25, 2014 at 10:22 AM, Dana Jansens wrote:
> I know I've wanted this before. For example the 4 constructors of
> ResourceProvider::Resource could be simpler:
> https://code.google.com/p/chromium/codesearch#chromium/src/cc/resources/resource_provider.cc&l=209
>
> On Thu, Sep 25, 2014 at 4:16 AM, Maciej Pawlowski 

[Antoine Labour]

On Thu, Sep 25, 2014 at 7:22 AM, Dana Jansens <dan...@chromium.org> wrote:

I know I've wanted this before. For example the 4 constructors of ResourceProvider::Resource could be simpler: https://code.google.com/p/chromium/codesearch#chromium/src/cc/resources/resource_provider.cc&l=209

In this case (and other similar ones), it easily happens that a field gets added to the struct/class, and some of the constructor's initialization list, but not others.

So +1 to delegated constructors for safety.

Antoine

 

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Peter Kasting]

It sounds as if support for this varies, but there's no real opposition, and some explicit support from notable owners.

Can we go ahead and put this in the allowed list?

PK

[Charlie]

+1 let's add this to the C++11 feature whitelist.

[James Robinson]

On Wed, Oct 29, 2014 at 1:37 PM, 'Peter Kasting' via blink-dev <blin...@chromium.org> wrote:

It sounds as if support for this varies, but there's no real opposition, and some explicit support from notable owners.

Can we go ahead and put this in the allowed list?

Only you can put things on the allowed list :)

Send a patch that moves the feature to the correct place in styleguide/c++/c++11.html *and* uses the feature in some bit of cross-platform code so we can make sure it works and I'll approve it once the trybots are green.

- James

PK

[Peter Kasting]

Send a patch that moves the feature to the correct place in styleguide/c++/c++11.html *and* uses the feature in some bit of cross-platform code so we can make sure it works and I'll approve it once the trybots are green.\

I'm unfortunately OOO for an extended period due to some broken bones right now, so I'm not in a position to write up this change.  Hopefully some other person is able to do so.

PK 

[Charlie Kehoe]

I'll see what I can do :-)

--

[Charlie Kehoe]

This CL seems to have only unrelated failures:

https://codereview.chromium.org/695683002/

However our project isn't compiled into bling or clank. I suppose that's not cross-platform enough?

[James Robinson]

Something compiled everywhere would be more useful as a first test since those platforms do use different toolchains.

- James

[Charlie Kehoe]

Makes sense. I'm a bit new to Chrome though. Can you suggest any particular examples?

[James Robinson]

Thanks Anders!

- James

On Fri, Nov 7, 2014 at 9:08 AM, Anders Hartvoll Ruud <and...@opera.com> wrote:

Delegated Constructors are now allowed.

http://chromium-cpp.appspot.com/

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Sami Kyostila]

FYI, I ran into an MSVC bug where the compiler silently generates broken code when delegated constructors are used in a diamond virtual inheritance pattern. Apparently the bug has been fixed, but it's still there in MSVC 2013 Update 4. For your sanity, I suggest avoiding delegated constructors in complex inheritance chains for now.

- Sami

[Alex Vakulenko]

Omg, I can use diamond virtual inheritance? Why did nobody told me this before? (...writing new code frantically...) :)

[Hajime Morrita]

This bit me today. It was simply daunting to hit this kind of compiler bugs.

Thanks Sami for posting this heads up. I won't decide this being the compiler bug without this report and would be just sobbing silently. 

Lesson learned: In such a big code base, the complex inheritance chains are everywhere ... without having you aware of it.

On Fri, Mar 6, 2015 at 9:05 AM, Sami Kyostila <skyo...@chromium.org> wrote:

[Nico Weber]

Does anyone have a sense how heavily we use delegated constructors already? If they're so tricky to use (in the sense that they can trigger compiler bugs) that they bit two people within a week, we probably shouldn't allow them yet.

[James Robinson]

My sense is that diamond virtual inheritance is very rare in Chromium (as it should be, it's banned by the style guide).  If my sloppy git grep is accurate the main-test uses cases are for  content::ChildThread, content::RenderWidget and content::RenderWidgetHost.  There are 2 other uses that don't seem as widely used.  The content ones are definitely complicated but I think we could avoid the delegated constructor issue in these particular places by adding big scary comments in the header files for these.  We should never get new uses of diamond virtual inheritance in chromium and at least the RenderWidget/RenderWidgetHost uses will go away eventually thanks to site isolation (although it's a very long term sort of eventually) so I don't think a general ban is needed.

- James