Il 03/09/2013 10:02, Stephen Kelly ha scritto:
Again, this is what std::unique_ptr is for. We should not try to turn QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have a need for a std::unique_ptr, they should use it. We should not adapt QScopedPointer to fit the need instead.Adding a move contructor to QScopedPointer makes no sense, because moving means 'escaping the scope', which breaks the fundamental point of QScopedPointer. QScopedPointer is different to std::unique_ptr and should remain so.
While I partially agree with the dreaded NIH syndrome, let me forward the argument that "escaping the scope" is very explicit in the code: either one has to return it:
> return scopedPointer; or it's being moved > q = std::move(p);The move assignment in particular doesn't require anything "new" -- it's literally q.reset(p.take()).
Food for thought, -- Join us at Qt Developer Days 2013! - https://devdays.kdab.com Giuseppe D'Angelo | [email protected] | Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
