> 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
>
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:
14 matches
Mail list logo