Il 03/02/20 14:59, Vitaly Fanaskov ha scritto:
If we're going for this logical fallacy, then let's up the ante: a unique pointer is just a shared pointer without copy semantics. Why not using shared pointers everywhere?Well, I hope it was rhetorical question, please, let me know if not.
Yes, it was.
The difference between shared pointer and unique pointer is fundamental. But there is no fundamental difference between unique pointer and scoped pointer. The both uniquely own a resources and resource lifetime is equal to smart pointer lifetime unless it explicitly prolonged. The only difference is a way how you can do that. In case of scoped pointer you can invoke method "take", in case of unique pointer you can also use move semantic. Looks like that scoped pointer is just yet another redundant entity.
A scoped pointer shouldn't have a take() function (or anything similar). That's an API mistake: it enables the pointer to escape the smart pointer, which is exactly what the name says it can't happen.
Let's see a bit further over there: * boost::scoped_ptr: no release() (*) * std::unique_ptr: release() * std::lock_guard / scoped_lock: no release() * std::unique_lock: release() (*) Argument by Authority:
https://www.boost.org/doc/libs/1_72_0/libs/smart_ptr/doc/html/smart_ptr.html#scoped_ptr_frequently_asked_questions
I do agree that the type is "redundant" because it's equivalent as a const unique_ptr (as said in the other email).
But the premise of the of the argument was: "give me at least one example when I cannot replace scoped pointer with unique pointer without losing readability and maintainability". If we accept that fallacy, I can also replace any unique pointer usage with a shared pointer one.
Introducing an alias should satisfy some people who used to use scoped pointer.
An alias from what to what? I'm a bit lost now.
For example. With a scoped pointer it's a bit harder to do that, but also possible, I think, for example:std::unique_ptr<Foo> ptr = ~~~;return ptr;QScopedPointer<Foo> ptr = ~~~; return QScopedPointer<Foo>(ptr.take());
This, unfortunately, shouldn't be possible; it's an API mistake. I believe it was raised during the same discussion of making QScopedPointer movable, but we never actually fixed it.
What? This is absurdly false -- the Standard Library is part of the C++ standard itself.Which doesn't mean that this is a part of the *programming language*. If you read carefully some parts of the standard, you can notice that, for example smart pointers or containers are not mandatory. For example:"This Clause describes components that C ++ programs may use to organize collections of information."
The claim was: "STL is not a part of C++ language itself and cannot be considered as a default standard."
The claim was false. It is a part of the programming language, and it it standardized, and any conforming implementation must ship it. The specification is called "International Standard ISO/IEC 14882:2017(E) – *Programming Language* C++" (emph mine) and it includes the standard library.
Now parts of the standard library are optional in freestanding implementations. Which we don't care about anyhow.
Qt since 5.0 requires the presence of a Standard Library. We worked around missing bits by not making them hard requirements, but the more we move forward in Qt 6, the more aggressive we'll be with these requirements on compiler vendors.
Changing the interface in any way which are incompatible with the Standard counterparts is a _terrible_ idea. It kills the principle of least surprise; it makes such facilities incompatible with the STL counterparts, preventing interexchange of data and code; and come Qt (N+1), it will prevent a clean pass of s/QtFoo/std::foo/g over the codebase.It's not a big issue if we have Qt wrappers around std smart pointers. A standard smart pointer that is under the hood should be easily accessible.
And I keep asking the details: what is not good enough in the standard smart pointers to justify a reimplementation in Qt? How does this trade off with the other points I've made? (Interoperability, maintenance, teachability, etc.)
How do you integrate QSharedPointer with std::shared_ptr exactly?If QSharedPointer is just a wrapper around std::shared_pointer it should be easy. Adding one more constructor and an operator to the wrapper.
Same set of questions here. My 2 c, -- Giuseppe D'Angelo | [email protected] | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
