Smart D-Ptr in KCoreAddons

Ivan Čukić ivan.cukic at kde.org
Fri Aug 23 14:41:41 UTC 2013


> 
> P1, P2 are your preference. Why do you even need to care about access
> to the raw pointer. The d_ptr/make_unique pointer is stored as private
> class member anyway. I don't see the need for those but that might
> also be because i just don't know enough in that area. If you could
> explain that, that would be welcome.
> 
> P4 is again a matter of taste. Even in your d_ptr you still have to do
> d_ptr<Private> on the header side, only the cpp side is more clean
> with d_ptr. however, does that matter much? I think the best way to go
> here i making a "d_ptr" template that uses make_unique to combine the
> shortness of your code. But that is _way_ above my knowledge level.
> 
> P5 make_unique<Private>() works as well, right?

If you look at it like that, what is the point in std::unique_ptr / 
QScopedPointer at all? delete d, new Private(...) ... works as well.

The point is that the less you can or need to do, less errors you are able to 
make.

Ch


-- 
Acting is merely the art of keeping a large group of people from coughing.
  -- Sir Ralph Richardson



More information about the Kde-frameworks-devel mailing list