On 9/4/13 8:09 PM, "Peter Kümmel" <[email protected]> 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 >> [email protected] >> http://lists.qt-project.org/mailman/listinfo/development >> > >_______________________________________________ >Development mailing list >[email protected] >http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
