> Heh? Every single class in Qt has a d ptr.
>
> > How many people write libs and care about ABI
>
> All of Qt itself, and all the libs based on Qt...
Well, I don't expect Qt to switch the whole code-base to it. I meant Qt users,
but if you think it might be worth a try...
> Yeah, ask him (no
On Tuesday 27 August 2013 09:08:24 Ivan Čukić wrote:
> > Well, if it's so useful, why would it be an over-stretch to have it in Qt?
>
> Maybe it's just me, but I don't see d-ptr idiom as something ubiquitous in
> C++/Qt world, as it is in KDE.
Heh? Every single class in Qt has a d ptr.
> How ma
> Well, if it's so useful, why would it be an over-stretch to have it in Qt?
Maybe it's just me, but I don't see d-ptr idiom as something ubiquitous in
C++/Qt world, as it is in KDE. How many people write libs and care about ABI,
if libstdc++ doesn't (for example, gcc 4.7 has a different abi fo
On Friday 23 August 2013 16:37:56 Ivan Čukić wrote:
> > The few cases where I have needed d-ptr hierachies, I didn't know about
> > it in advance but was happy than I could extend my classes without having
> > to use a different smartpointer (with possibly a different size).
>
> Exactly. The *few*
> That alone is - I think - a reason to not have it.
A small update. It now supports inherited privates as well.
Ch
--
Science gathers knowledge faster than society gathers wisdom.
-- Isaac Asimov
___
Kde-frameworks-devel mailing list
Kde-fra
>
> 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 t
> The few cases where I have needed d-ptr hierachies, I didn't know about
> it in advance but was happy than I could extend my classes without having
> to use a different smartpointer (with possibly a different size).
Exactly. The *few* cases.
Most of our higher-level code do not use and do not
On 2013-08-23, Ivan Čukić wrote:
>> oh. and I think it also looks a bit like your d-ptr gets in the way when
>> you need a d-ptr hierachy.
>
> As I said, this is for non-inherited privates.
That alone is - I think - a reason to not have it.
The few cases where I have needed d-ptr hierachies,
On Fri, Aug 23, 2013 at 8:49 AM, Ivan Čukić wrote:
>
>> The paper that describes make_unique - and contains an implementation
>> - can be found here [1]. For reference, the full code to have
>> make_unique ready to paste in any file is here [2].
>
> Make unique is only a method to create a std::un
> I honestly don't see what it actually brings us over using
> QScopedPointer. It gives safety and convenience - and they are actually
> also spiffy.
QSP is as spiffy as a unique_ptr:
> std::unique_ptr with make_unique does not provide P1, P2, P5 and P4.
> P1 - safety: no access to the raw poin
On 2013-08-22, Ivan Čukić wrote:
> 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
> The paper that describes make_unique - and contains an implementation
> - can be found here [1]. For reference, the full code to have
> make_unique ready to paste in any file is here [2].
Make unique is only a method to create a std::unique_ptr, and it doesn't
provide (or, rather, inhibit) the
On Thu, Aug 22, 2013 at 6:49 PM, Ivan Čukić wrote:
> 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
>
13 matches
Mail list logo
