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
With parameter names:
class Foo
{
public:
someType f(someType parameterName);
};
Without Parameter names:
class Foo
{
public:
someType f(someType);
};
In terms of C++, which one is recommended? Or just a personal preference?
I don't see any advantage in omitting the names from the declaration.
On the other hand, I do see several disadvantages:
Your code is less readable.
Your intention is less clear.
It gets a lot more messy to get the code to work ("wait a second, why does PowerOf2("10,2"); Gives me 1024? I was expecting 100.")
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 3 years ago.
Improve this question
Recently, I came into a situation where I need to copy an object which has a std::unique_ptr type member.
class A {
/* ... */
std::unique_ptr<A> next_;
};
A a0;
A a1{a0};
// compiler error, due to the std::unique_ptr is un-copyable
// but I do need a deep copy!
Of course, I could have a Clone function in A to get me through, but why can't STL just have a deep_ptr to make my life easier (Change next_ to std::deep_ptr<A> next_).
And IMHO, deep copy is a very common demand among the daily developing life, so why does STL lack of such thing std::deep_ptr? Does this concept make no sense especially in some high language level(e.g. the level STL sits at)?
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 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
A similar question has been already asked in stackoverflow regarding Java.
But C++ does not behaves exactly as Java and, in particular, C++ does not allow access on protected members of a class "...from another package...".
So, what is the rational to allow protected members inside class marked as final ? Is a convenient way for the developer to quickly switch a class from final to non final (if the design change) ?
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
To be honest (*this) looks a lot better than this->. They both function the same. Why shouldn't I use the former? Is it just common practice to use this->, or is there something more to it?
Actually both will have same results when accessing data-members. Though you find (*this) more elegant I would undoubtedly say most will disagree.
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!