4 ms·
Is this really considered modern c++ style? Best practice as far as I've ever known it is to disallow wherever possible the allowance of having an invalid state
by albinofrenchy 9y ago
Is this really considered modern c++ style? Best practice as far as I've ever known it is to disallow wherever possible the allowance of having an invalid state; typically with constructers locking those details down.
Obviously references are better in most circumstances but only because you don't have to check for an empty or invalid state. They offer no performance or optimization on their own.
- tomjakubowski 9y agoI think GP meant "smart pointers" where they said "object references". At least, that was the only reading that made sense to me, since it would be a little bit insane (and UB) to create a C++ reference (T&) from a null pointer.
- adrianratnapala 9y agoBut then what is the difference between what he is complaining about and a traditional pointer. I always assumed that a default-constructed unique_ptr<T> was simply a NULL pointer under the hood. So you have exactly the same representations of "nothing" as you do with a T
- albinofrenchy 9y agoYes, both unique and shared ptrs default to null and in many ways are drop in replacements for naked pointers. If the empty state thing was in reference to smart pointers, it'd be a remarkable misunderstanding of how they work and how they should be used.
- tomjakubowski 9y ago> If the empty state thing was in reference to smart pointers, it'd be a remarkable misunderstanding of how they work and how they should be used. No, I don't think so. Many C++ libraries, especially those originally developed before C++11, implement their own smart pointer templates, which may end up having diverging semantics. That's exactly what OP was describing. Examples off the top of my head include: CEF, Chromium, v8, Qt, glibmm, and the internal codebase where I work.
- albinofrenchy 9y agoThere are definitely better smart pointer semantics than others -- see the now deprecated auto_ptr. But it really doesn't fit the argument as framed. All smart pointer implementations are some valuable niceties wrapped around a naked pointer. It has nothing to do with preferring references to pointers; at the end of the day you just have a pointer -- just one that gets default initialized to 0, and deletes itself when you are done with it. Frankly, the type of C++ developer that spends any serious amount of time trying to come to terms with a smart pointer API; even one they haven't seen before is the type of developer I wouldn't really want manipulating naked pointers.
- tomsmeding 9y agoThe only difference being that in the case of a smart pointer, you can't ignore the possibility of a null by accident.
- civility 9y agoYou can easily ignore null by accident while using smart pointers: struct foo { int bar; }; std::unique_ptr<foo> bug; bug->bar = 123;
- tomsmeding 9y agoTrue, didn't think of that. Then indeed they are quite useless, and IIRC they are actuallt deprecated in C++17.
- civility 9y agoI don't agree they are useless - they don't stop you from accessing nullptrs, but they do help manage the lifetimes of your dynamically created objects. And I haven't seen anything indicating unique_ptr is to be deprecated - maybe you're thinking about auto_ptr.
- albinofrenchy 9y agoSmart pointers are not at all useless and not at all deprecated (you are thinking of auto_ptr; there are still unique_ptr and shared_ptr). They don't try to address the check for null problem at all; that isn't their intent. All they mean to do is eliminate several classes of common, easy to make mistakes such as not zero initializing or not freeing the resource.