Hi all,
We had some discussions on plasma-devel regarding the use of a smart non-
inherited D-Pointer[1] and Kevin proposed moving the pointer into KCoreAddons.
The only listed downside of including it into plasma is that it is too low
level and generic to belong to that framework (Sebas).
Cons:
C1 - they use variadic templates for P4 (noted by Kevin), but that is not
strictly necessary and the always-catching-up compilers will be covered.
Pros:
P1 - safety: no access to the raw pointer
P2 - safety: no accidental initialization errors or anything similar
P3 - safety: no possible leaks
P4 - convenience: forwarded constructor arguments (': d(1,2)' instead of ':
d(new Private(1,2))')
P5 - convenience: default constructor works for no-arg Private constructor
(nothing instead of 'd(new Private())')
P6 - convenience: no delete d;
P7 - they are spiffy (Aaron) :)
The class is header-only, that is, two headers only. It doesn't change binary
interface of the user class - it is equivalent to a raw pointer; nor the
library it should be in.
Cheerio,
Ivan
[1] http://ivan.fomentgroup.org/blog/2013/06/22/d-ptr-the-modern-way/
--
Money can't buy happiness, but neither can poverty.
-- Leo Rosten
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
