[Development] Making QScopedPointer scoped (again)

[Knoll Lars]

On 9/4/13 8:09 PM, "Peter Kümmel" <syntheticpp at gmx.net> wrote:

>On 04.09.2013 17:54, Thiago Macieira wrote:
>> On quarta-feira, 4 de setembro de 2013 10:20:39, Peter Kümmel wrote:
>>>> What's that something else? Remember that QScopedPointer was created
>>>>to
>>>> simplify handling of exceptions (when we tried to care about
>>>>exceptions).
>>>> If we have to take the pointer out and handle it manually, it defeats
>>>>the
>>>> entire purpose of QScopedPointer -- simplifying exception management.
>>>
>>> This "something else" we have to introduce in Qt (it would be very
>>>similar
>>> to QScopedPointer), because initially QScopedPointer wasn't made for
>>>it,
>>> and all "escaping from scope" questions if QScopedPointer is the right
>>> choice at this place.
>>
>> You're confusing QScopedPointer's purpose.
>
>I don't confuse it, I only insisted on correct naming.
>Passing around a "scoped pointer" is just plain stupid.

So you'd prefer us to introduce a QUniquePointer instead, that's basically
the same as the current scoped pointer with the additional move semantics?

It seems like most of the thread is purely about naming. Everybody seems
to agree that we would some way to pass a unique/scoped pointer over to
somewhere else (e.g. return it from a method).

So then there are basically two options:

1. We extend QScopedPointer and live with the fact that the name is not
perfect, as scoping can be broken explicitly.
2. We add a QUniquePointer that has pretty much the functionality that we
now have in QScopedPointer, and we revert the change that added moving to
QScopedPointer
3. We revert the patch, and hope that C++11 spreads fast enough so that
people will start using unique_ptr instead. Then we deprecate
QScopedPointer.

For stl compatibility, we could add methods to assign a unique_ptr to a
QScopedPointer (and QUniquePointer in option (2). In addition, we should
probably allow assigning of a QUniquePointer to a QScopedPointer if we go
for option (2).

Option (1) or (3) are least work for us. Option (2) requires some
implementation work and documenting a new class. It also does copy a class
from the standard.

Given that we have less then 3 weeks until feature freeze (1) or (3) sound
more attractive for 5.2.

I believe that c++11's unique_ptr is already available to most developers
using Qt, so in that case, it might make more sense to leave
QScopedPointer as in 5.1 (since an exact copy of that class is not
available in C++11), and refer people to unique_ptr for the other use
cases.

Cheers,
Lars

>
>You also got the problem by your own:
>"Despite its name, it's not just about scope",
>so what is the "Scope" in the name good for?
>
>After all I would prefer QXPointer over QScopedPointer,
>because I could not trust the naming any more, and it's less to type.
>
>I wonder which features I haven't discovered in QWidget ;)
>
>  It's about simplifying the handling of the pointer's deletion
>> when an exception is thrown.
>>
>> Taking the pointer out via take() and storing it in a raw pointer
>>defeats that
>> purpose.
>>
>> 	q.reset(p.take()); is exception-safe
>> 	return p.take();  isn't
>>
>> if we want to return exception-safely, we need this.
>>
>> Note: we don't care anymore about exceptions.
>>
>>
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development