> 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.
Please, give me at least one example when I cannot replace scoped pointer with
unique pointer without losing readability and maintainability. Unique pointer
could "escape a scope" only explicitly. So I'm still not convinced that we need
to have one more redundant entity. 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. 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.
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.
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.
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.
After all, many Qt users get used to Qt naming convention and style.
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.
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.
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.
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.
On 01/02/2020, 00:48, "Giuseppe D'Angelo via Development"
<development@qt-project.org> wrote:
On 31/01/2020 23:46, Vitaly Fanaskov wrote:
> I'd suggest QUniquePointer. Honestly, I don't think we have too many
alternatives here. We can try Rust-like naming (something like QBox), but it
just looks weird and tells nothing about ownership semantics.
>
> After that we can write "using QScopedPointer = QUniquePointer"
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.
About QUniquePointer: what's the point of reinventing std::unique_ptr
under a different name?
* Is it just going to be an alias, to be more Qtish? Then why
QSharedPointer is NOT going to be an alias?
* Is it not going to be an alias? NIH all over again?
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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
