[mreiland]

I didn't read all of his examples, but I read a few.

I'm confused by his issue with calling virtual functions from the constructor. Because of the order in which C++ calls the constructors in a base/parent class hierarchy during construction, calling a virtual function can be dangerous.

This is a valid restriction in my opinion. I get that it doesn't have to result in problems, and it can be useful, but in general, the guidelines in that section of the article coincide with whats generally considered good C++ code anyway.

The example about the copy constructor being disabled by default. That's pretty sane in my opinion, some of the downsides to C++ are that sometimes you can't tell what's going on when looking at an innocuous statement such as 'a=b'. This policy just greatly tamps down on the possibility of C++ hiding a heck of a lot of 'magic' from you by doing things you didn't necessarily expect.

I'm sure there are others, but honestly it feels more like the guy has a problem with Java than C++.

[TheCoelacanth]

> I'm confused by his issue with calling virtual functions from the constructor. Because of the order in which C++ calls the constructors in a base/parent class hierarchy during construction, calling a virtual function can be dangerous.

He wasn't complaining about not calling virtual functions in ctors/dtors; he said that was understandable. He was complaining about two-stage initialization being required for any non-trivial initialization.

[mreiland]

He didn't say it was understandable, he said he "wasn't completely against it". That is not the same thing by far.

But the point is that he's misunderstanding, the guideline he posted was the following:

> Avoid doing complex initialization in constructors (in particular, initialization that can fail or that requires virtual method calls). ... Constructors should never call virtual functions or attempt to raise non-fatal failures. If your object requires non-trivial initialization, consider using a factory function or Init() method

consider using is a far cry from *required to use. It also explicitly spelled out the situations in which you should consider using something like a factory method.

- When you need to call virtual methods since a factory method implies the full construction of the object

- When you want to indicate non-fatal failures since a factory method implies being able to do so without exceptions.

If your code doesn't require virtual methods and doesn't need to indicate non-fatal failures, then there is nothing in that particular guideline that's relevant to you.

It's a sensible guideline, especially in an environment where you need to be able to avoid using exceptions.

He also took issue with the following:

> Provide a copy constructor and assignment operator only when necessary. Otherwise, disable them with DISALLOW_COPY_AND_ASSIGN.

The entire point of this guideline is to disallow the compiler from doing anymore magic than is completely necessary. Especially surrounding things like construction and operator overloading, C++ does a lot of 'magic' to keep the user syntax relatively clean, but it can also make the code misleading/hard to understand.

The point is that both guidelines are actually sensible, and nothing in them explicitly prevents you from doing anything the author complained about. The idea of "only when necessary" is not even close to "always" or "never".

I didn't read the entire thing, but a lot of the complaints appeared to be related to his misunderstanding the intent, or taking it to the extreme.

[TheCoelacanth]

> Constructors should never attempt to raise non-fatal failures

That essentially requires two-stage init for almost any non-trivial initialization.

[mreiland]

That's untrue, and for you to make that claim is ridiculous, but it does mean this conversation is no longer worth engaging in.