Hi, Il 01/02/20 22:55, Vitaly Fanaskov ha scritto:
The consensus was reached against such a decision. A scoped pointer should not be able to escape scope. Yes, in C++17 this is now not entirely true, but the name strongly implies it.Perhaps, it's a good time to reconsider it. Scoped pointer is redundant entity in light of modern C++. It's just an unique pointer without move semantic.
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?
Please, give me at least one example when I cannot replace scoped pointer with unique pointer without losing readability and maintainability.
And an example where I cannot replace a unique pointer with a shared pointer without losing readability and maintainability?
Unique pointer could "escape a scope" only explicitly.
Like this?
std::unique_ptr<Foo> ptr = ~~~; return ptr;
So I'm still not convinced that we need to have one more redundant entity.
Which one would be the redundant one?
We have more than enough. This is possible to introduce an alias just to keep naming convention people get used to, I guess, but I'm not sure if this is really required.About QUniquePointer: what's the point of reinventing std::unique_ptr under a different name?So, first of all, not reinventing. I'd say adopting. The main question I see through some your posts in this thread is "why do we need Qtish wrappers at all?". Correct me if I'm mistaken, please.
That's the question indeed. What's the tangible net benefit of having a Qt wrapper?
Until that I'll answer this question __
There are a few pros of having Qt wrappers around std smart pointers. To make it clear, saying "Qt wrapper" I mean a class that contains std smart pointer as a field and has more Qtish interface. Not inherits a std smart pointer.
And I've asked: how this Qtish interface for std::unique_ptr be different exactly?
Pros I can see: 1) Qt style STL has different naming convention that looks alien to Qt API. It leads to inconsistency. STL is not a part of C++ language itself and cannot be considered as a default standard.
What? This is absurdly false -- the Standard Library is part of the C++ standard itself.
The fact that some people might get used to some names doesn't mean that these names are good in terms of self-explanatory. > For example, how do I understand without documentation what does"weak_ptr::lock" do? Something like "asStrongRef" is easily understandable just by reading code.
With this I can totally agree. As I said countless times, the only way to influence such naming decisions is working _with_ upstream (by the way, the meetings are pretty much public) and bringing your arguments on naming there. After, it's too late, and as an overall minority in C++ we'll get those decisions made by someone else and we'll just have to live with them. It's not a good position to be in.
Between C++11, 14, 17 and 20, by heart I can only name _one_ thing that has been introduced in the Standard Library which has had an inspiration coming from Qt (C++20's std::map::contains()).
Please also see this from the eyes of someone else who comes from a general purpose C++ background, where usage lock() is established (for how much absurd that naming choice is); then gets the Qt equivalent, and wonders why it _hasn't_ got lock(), despite Qt having 0.something% of the C++ market share.
(I know QWeakPointer has got lock() now.)
I'm not 100% sure who is responsible for naming STL classes and methods, but this person(s) did really good job in terms of reducing symbols count. I'm just wondering why not "w_p::l" instead of "weak_ptr::lock", it looks much shorter! In my opinion, we shouldn't sacrifice readability to reduce symbols count.
The "who" is a lot of people.
https://isocpp.org/std/the-committee
After all, many Qt users get used to Qt naming convention and style.
And again see this the other around too: many C++ users get used to the C++/Boost/Abseil/... naming convention and may find Qt ones "unusual".
2) Flexibility It will be much easier to extend or reduce interface if we need it. Changing implementation is also will be easier if someone needs to have a different smart pointers under the hood on some platforms.
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.
3) Low maintenance costs We just need to replicate an API at first implementation. After that, introducing new methods that might occur in an upcoming standards should be easy enough.
This is wishful thinking, or, famous last words.First: it costs in terms of development bandwidth that is NOT being used to improve the areas where Qt should shine; it's instead used for reinventing wheels.
Second: history proves this false. See for instance the story with Qt containers, which are *still* missing range insertion (C++98) (and some range construction), emplacement (C++11), support for move-only types (C++11), and so on. On what grounds should one believe that after 9 years suddenly Qt will catch up with the development of these building blocks?
4) Easy to integrate with std smart pointers A few constructors/operators/methods could solve this problem. It means that it should be possible to integrate with a code written with using std pointers.
How do you integrate QSharedPointer with std::shared_ptr exactly?
Finishing this, I'd like to say that having consistent APIs that don't violate principle of less astonishment is important thing. That's the main reason why personally I vote for the option with Qt wrappers.
If I were a developer coming from standard C++ to Qt, the principle would apply in that direction too: why in the world Qt felt the need to reinvent all my vocabulary types?
My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | 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 Development@qt-project.org https://lists.qt-project.org/listinfo/development
