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)?
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
One of the nicer features of Rust is explicitly showing whether parameters are mutable, non-mutable, or moved from the caller's site:
foobar(&mut foo, &bar, baz);
// ^ mutable ^ non-mutable ^ moved (copied if trivial)
In C++ we already have tools to do this:
foobar(std::ref(foo), std::as_const(bar), std::move(baz));
Yet, though std::move is standard practice, I've never seen std::as_const being used in a function call.
Is there a reason for this, other than maybe std::as_const is too verbose? Would adding simpler syntactic sugar for it provide a good new feature that makes C++ more readable?
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 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
I'm currently self-studying C++ and I'm about to finish my OOP course, till now, I've finished the OOP concepts but the course also includes an introduction to the STL, but I feel like it's too early to have a look on the STL at this stage(before studying Data Structures).
Is it a good idea to skip the last part of the OOP course and start studying Data Structures right now? or should I complete the course anyway?
In my opinion, if you already can understand OOP principles you should use STL and do not care how it really works under the hood, but after that, you should learn basic data structures and all will come clear for you.
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 8 years ago.
Improve this question
Should a thread-safe mechanism be added when a class is developed and it is known that this class will be used in multi-threaded environment (not always however) or leave it to the user?
As a general rule, it's more flexible to leave it to the user. For example, consider a map-type container. Suppose the application needs to atomically move something from one map to another map. In this case, the user needs to lock both maps before the insert-erase sequence.
Having such a scenario be automatically taken care of somehow by your class would probably be inelegant, because it's naturally something that happens across objects, and because there may be many such scenarios, each slightly different.
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.")