> > IOW, is a QSharedPointer specialization feasible?
>
> To do what?
I meant, to have QSharedPointer<"derived QObject class"> using the
QObject control block, rather than creating a new one.
(in the same way this is done with QWeakPointer)
My whole reflexion was: I need to have shared ownership
> On 15 Jun 2018, at 13:31, Arnaud Clère wrote:
>
[snip]
> Most user-defined bind methods would be very simple and the type system would
> guarantee that data is well-formed (no sequence or record left open...):
>
>struct Person {
>QString m_firstName, m_lastName;
>int m_
On Thursday, 14 June 2018 23:55:33 PDT Olivier Goffart wrote:
> QDomDocument is, in fact, not deprecated.
Fair enough. But the QtXml module as a whole is Done.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
__
On Friday, 15 June 2018 00:32:13 PDT Philippe wrote:
> QObject has built-in support to a reference count block to support QPointer
> (which is composed of a QWeakPointer)
>
> When doing QSharedPointer, is there a technical reason that
> prevents the QObject control block to be used, rather allocat
-Original Message-
From: Thiago Macieira
Sent: jeudi 14 juin 2018 02:08
> This email is to start that discussion and answer these questions:
> a) should we have this API?
> b) if so, what would this API look like?
> c) if not, should we unify at least JSON and CBOR?
> c) either w
QObject has built-in support to a reference count block to support QPointer
(which is composed of a QWeakPointer)
When doing QSharedPointer, is there a technical reason that prevents
the QObject control block to be used,
rather allocating a new one, like it is necessary for common objects?
IOW,
On 2018-06-05 14:40, Daniel Teske wrote:
Hi,
I've done some research into how supporting unique_ptr in Qt might look like.
I have a patch which adds apis using unique_ptr for ownership transfer to
almost all of QtBase and a patch for Qt Creator to show how using those apis
looks like.
Qt: h
