On Friday 26 June 2015 10:45:24 Marc Mutz wrote:
> It introduces a new shared data pointer that's designed to allow users of
> the pointer to have an inline move constructor.
>
> Most of our implicitly shared types already had a move-assignment operator,
> because it's just
>
>QFoo &operator=
On Friday 26 June 2015 22:20:11 Marc Mutz wrote:
> > I tried to implement emplace, but didn't find much value because Qt
> > containers require the type contained to be default constructible and will
> > make copies in the future anyway.
>
> QList does not require the type to be default-constructi
On Friday 26 June 2015 19:59:37 Thiago Macieira wrote:
> On Friday 26 June 2015 16:45:18 Marc Mutz wrote:
> > or that they don't have range-ctor or range-insert, or emplace, or
> > allocator support.
>
[...]
> I tried to implement emplace, but didn't find much value because Qt
> containers requir
On Friday 26 June 2015 16:45:18 Marc Mutz wrote:
> or that they don't have range-ctor or range-insert, or emplace, or
> allocator support.
Range construction and insertion is easy to add. I have the range insert in my
local copy of QVector, but not the constructor -- I never realised it even
ex
On Friday 26 June 2015 16:45:18 Marc Mutz wrote:
> The problem you have is that you want immediate resource release. If you
> want that, swap something with a new object:
>
>QVector().swap(something);
>
> (or call clear(), but that's Qt-specific).
clear() is changing behaviour to keep reser
On Friday 26 June 2015 16:52:16 Gunnar Roth wrote:
> Hi Marc
> Gesendet: Freitag, 26. Juni 2015 um 17:25 Uhr
> Von: "Marc Mutz"
> An: development@qt-project.org
> Betreff: Re: [Development] Move ctors for q_declare_shared types
>
> Marc are you from the future ? Or is just your clock wrong ?
Hausmann Simon , 14.06.2015 17:57:
> Hi,
>
> This is a result of QVariant being a value type. If you make a copy and
> modify it, then the original remains as-is. The call to setContextProperty
> creates a copy. If you want explicitly shared data between the JavaScript
> environment and C++ then I
On Friday 26 June 2015 11:59:11 Olivier Goffart wrote:
> However, it is questionable if even this works. We already rely on the
> standard library ABI in QException. And most users will have to recompile
> everything if they want to change standard library anyway.
std::exception is compatible be
On Friday 26 June 2015 06:12:53 Al-Khanji Louai wrote:
> What they did was to move registration of meta object content to runtime.
> They basically have structs with static variables and they rely on
> initialization of these variables at program start-up. It's a lot of macro
> magic and relies on
Hi Marc
Gesendet: Freitag, 26. Juni 2015 um 17:25 Uhr
Von: "Marc Mutz"
An: development@qt-project.org
Betreff: Re: [Development] Move ctors for q_declare_shared types
Marc are you from the future ? Or is just your clock wrong ?
>> According to the fundamental C++
> > principle "Don't p
On Friday 26. June 2015 16:14:48 Olivier Goffart wrote:
> On Friday 26. June 2015 15:42:31 Daniel Teske wrote:
> > > > For standard containers, this is specified in *container.requirements*
> > > > To quote, with: a being a container and rv a non-const rvalue of the
> > > > same
> > > > type:
> > >
Le vendredi 26 juin 2015 à 16:14 +0200, Olivier Goffart a écrit :
> >
> > - Standard containers guarantee that the old elements get either move
> > assigned or destroyed.
>
> I partially disagree.
> The wording seems to indeed implies that the move assignement operator of
> std::vector should
On Friday 26 June 2015 15:55:04 Daniel Teske wrote:
> On Friday 26 Jun 2015 16:45:18 Marc Mutz wrote:
> > On Friday 26 June 2015 12:34:31 Daniel Teske wrote:
> > > > Most of our implicitly shared types already had a move-assignment
> > > > operator, because it's just
> > > >
> > > >QFoo &opera
On Friday 26. June 2015 15:42:31 Daniel Teske wrote:
> > > For standard containers, this is specified in *container.requirements*
> > > To quote, with: a being a container and rv a non-const rvalue of the
> > > same
> > > type:
> > >
> > > a = rv
> > >
> > > "All existing elements of a are either
On Friday 26 Jun 2015 16:45:18 Marc Mutz wrote:
> On Friday 26 June 2015 12:34:31 Daniel Teske wrote:
> > > Most of our implicitly shared types already had a move-assignment
> > > operator, because it's just
> > >
> > >QFoo &operator=(QForr &&other) { swap(other); return *this; }
> >
> > And
> > For standard containers, this is specified in *container.requirements*
> > To quote, with: a being a container and rv a non-const rvalue of the same
> > type:
> >
> > a = rv
> >
> > "All existing elements of a are either move assigned to or destroyed,"
> >
> > I do not see any reason why
On Friday 26 June 2015 12:34:31 Daniel Teske wrote:
> > Most of our implicitly shared types already had a move-assignment
> > operator, because it's just
> >
> >QFoo &operator=(QForr &&other) { swap(other); return *this; }
>
> And that's indeed how QVector's move assignment is implemented.
>
On 25/06/15 18:30, Thiago Macieira wrote:
> On Thursday 25 June 2015 09:04:43 Thiago Macieira wrote:
>> On Thursday 25 June 2015 09:37:32 Heikkinen Jani wrote:
>>> Hi all,
>>>
>>>
>>> We must freeze the Qt 5.5.0 content now so please don't push any new
>>> changes in '5.5.0' branch anymore; those
Daniel Teske schreef op 26-6-2015 om 12:34:
>> Most of our implicitly shared types already had a move-assignment operator,
>> because it's just
>>
>> QFoo &operator=(QForr &&other) { swap(other); return *this; }
> And that's indeed how QVector's move assignment is implemented.
>
> It's also bro
> Most of our implicitly shared types already had a move-assignment operator,
> because it's just
>
>QFoo &operator=(QForr &&other) { swap(other); return *this; }
And that's indeed how QVector's move assignment is implemented.
It's also broken.
Just because other is a rvalue reference does
On 06/22/2015 12:46 PM, Stromme Christian wrote:
> Hi,
>
> The Qt WebView module has been a tech preview for 5.4 and is still going to
> be a tech preview for 5.5, but
> for 5.6 we would like to propose that it gets upgraded to an official Qt
> add-on. Making the module an add-on,
> and also maki
On Tuesday 23. June 2015 10:17:40 Knoll Lars wrote:
> Qt 5.6:
>
> * We make 5.6 a long term supported release
> * We still support C++98 compilers in this release (for the last time),
> i.e. We keep the 5.5 compiler baseline
> * WEC7 will be still supported
> * QNX 6.5 is not supported anymore
> *
Hi,
I'd like to invite review of
https://codereview.qt-project.org/115213
despite it clearly not being in a mergeable state (mixes unrelated changes).
It introduces a new shared data pointer that's designed to allow users of the
pointer to have an inline move constructor.
Most of our implicit
23 matches
Mail list logo
