Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
A well-known principle of good programming style says: "explicit is better than implicit". Don't inherited constructors go against this principle? (A single using statement that includes all the constructors of the base class isn't very explicit, is it?)
No, this principle is for explicit keyword with constructors and conversion operators, not for explicitely typing a lot of code. using won't change whether the constructors are explicit or implicit.
This principle is (as most principles in C++) also quite disputable and over-generalized.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Is it recommended in C++ 20 to always favor direct-list-initialization over copy initialization or even direct initialization as a general rule of thumb? As an old C++98 programmer coming back to C++ after 15 years it still feels natural to use auto i = 5 instead of auto i {5}. I want to make sure the "new" way really is the new default before "burning in" the new way into my coding guides.
I suppose post modern C++ enables you to express "intent" instead of "operation". In that sense auto i {5}; would state you allow the compiler to choose the type and that you only care about 'i' being initialised, not caring how that happens? But if your intent is to initialise in some specific way you have chosen to be "the best" in some sense, then choose the initialisation you think comes closest to that way :)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Do the conventions in a programming language such as in C++ (such as extraction operator >> ) can be changed by a developer? Or is it restricted?
You're asking two questions here.
Who makes the C++ Standard?
The C++ Standards Committee
Can I change the behavior of an operator such as operator>>?
Yes, you can, via a capability defined in the standard. See:
http://en.cppreference.com/w/cpp/language/operators
What are the basic rules and idioms for operator overloading?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I know how to define destructor is just like this
~ClassName()
{
}
and destructor can't have parameter. then why we must write parentheses after the class name? since destructor can't have parameter and i think there is no benefit of it. or there is other function of it?
i think it will be better if there is no parantheses needed because it make clear destructor can't have parameter
~ClassName
{
}
Two reasons so far
It is a function so it needs the syntax declaration of a function.
Why is the function declaration syntax like that? It's how the grammar
was defined.
In the D programming language the parenthesis of functions are optional when there are no arguments. D is designed to be a better C++. You might be interested in that language https://dlang.org/
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I was given a question: how operator overloading in C++ impacts on performance?
I'm not pretty sure how to answer it. I fully understand the idea and how to overload operators in C++, but what about performance?
Calling an overloaded operator is the same as calling any function in the object. If you mark the operator as inline, you get the same benefits (or lack thereof) as any other inline function.
Nothing complicated at all.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Should I declare all classes that aren't inherited as final even if they don't have anything to do with inheritance and that kind of stuff?
A class should be declared final when you want to declare the statement "this class cannot be inherited". This is not the same case as the statement "this class is not inherited". It is a matter of opinion but I would not forbid the inheritance of a class, unless there is a very specific reason to do so. Therefore, I would not declare a class final unless there was a reason to do so.
Hope I helped!