> It doesn't belong into plasma-framework,
The original mail *was* about plasma-framework - the thread was
started when Kevin removed the add_definitions("-std=c++0x") from the
repo's top CMakeLists.txt
http://mail.kde.org/pipermail/plasma-devel/2013-June/025747.html
> and you didn't answer my "why not
> QScopedPointer" question. :)
It is not really about QSP or unique_ptr - they /can/ be used directly
for this. They don't have the same features though (btw, the
implementation does use unique_ptr in the back)
Features
- if SomeClass::Private has a no-argument constructor, you don't need
to initialize it at all
SomeClass::SomeClass()
// This:
// : d(new Private())
// becomes this:
{
}
- if it has arguments, for example Private(int, int)
SomeClass::SomeClass()
// This:
// : d(new Private(2,3))
// becomes:
: d(2,3)
{
}
- it is safe. You can't not accidentally screw up the pointer it
points to. You can't accidentally access the raw pointer. You can not
delete it etc. (the only way to access the raw pointer is to use
operator->() - and you can not do that accidentally :) )
- it ensures that it points to something, you can not leave it empty
by accident.
So, in the same way QSP and u_p are improvements over a raw pointer,
this is an improvement over them - for *this* use-case - it is
tailored for this use-case.
--
Cheerio,
Ivan
--
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was staring straight into the shining sun
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
