Home » Blog » Tags » intermediate

intermediate

Quick Q: In C++ are static member functions inherited? If yes why ambiguity error does not arise?

By Adrien Hamelin | Feb 20, 2018 08:44 AM | Tags: intermediate

Quick A: Yes, and there are no ambiguity with static members.

Recently on SO:

In C++ are static member functions inherited? If yes why ambiguity error does not arise?

It's fine according to the lookup rules. You see, when you write member access (obj.display();), the member display is looked up not just in the scope of the class and its base classes. Base class sub-objects are taken into consideration as well.

If the member being looked up is not static, since base class sub-objects are part of the consideration, and you have two sub-objects of the same type, there's an ambiguity in the lookup.

But when they are static, there is no ambiguity. And to make it perfectly clear, the C++ standard even has a (non-normative) example when it describes class member lookup (in the section [class.member.lookup])

To RAII or Not to RAII?--Jonathan Boccara

By Adrien Hamelin | Feb 12, 2018 10:55 PM | Tags: intermediate

Good question.

To RAII or Not to RAII?

by Jonathan Boccara

From the article:

RAII is a central concept in C++, that consists in relying on the compiler to call destructors automatically in certain cases. Putting appropriate code in such destructors then relieves us from calling that code – the compiler does it for us.

RAII is an idiomatic technique of C++, but can we use RAII for everything? Is it a good idea to shift every possible piece of code to the destructor of some class, to leave the work to the compiler and make calling code as light as can be?

Since this question comes down to asking if the proverbial hammer is a tool fit for every single task, the answer to that question is probably the proverbial No.

But then, in which cases would RAII improve the design of a piece of code?

In this article we’ll see a case where RAII is adapted, then a case where RAII is NOT adapted. And after that we’ll see a case open to discussion. We’ll then conclude with how to use levels of abstractions to make the decision to RAII or not to RAII...

Quick Q: Direct initialization with empty initializer list

By Adrien Hamelin | Feb 7, 2018 07:23 PM | Tags: intermediate c++11

Quick A: If there is an initializer list contructor, it will choose it.

Recently on SO:

Direct initialization with empty initializer list

When an argument is an initializer list ([dcl.init.list]), it is not an expression and special rules apply for converting it to a parameter type.

If the parameter type is std::initializer_list or “array of X” and all the elements of the initializer list can be implicitly converted to X, the implicit conversion sequence is the worst conversion necessary to convert an element of the list to X. This conversion can be a user-defined conversion even in the context of a call to an initializer-list constructor.

Otherwise, if the parameter is a non-aggregate class X and overload resolution per [over.match.list] chooses a single best constructor of X to perform the initialization of an object of type X from the argument initializer list, the implicit conversion sequence is a user-defined conversion sequence. If multiple constructors are viable but none is better than the others, the implicit conversion sequence is the ambiguous conversion sequence. User-defined conversions are allowed for conversion of the initializer list elements to the constructor parameter types except as noted in [over.best.ics].