On quarta-feira, 29 de março de 2017 08:44:35 PDT Thiago Macieira wrote:
> Without destructive moves:
> 1) allocate new block
> 2) move each element (constructor is noexcept, good)
> -> could be a memcpy + memset, but isn't...
> 3) destroy each element (refcount is checked every time!)
> 4) d
On Mittwoch, 29. März 2017 11:53:16 CEST Ville Voutilainen wrote:
> On 29 March 2017 at 12:49, Marc Mutz wrote:
> > This is probably one of the most important things. Ville asked on std-
> > proposals to show hard numbers. You don't need hard numbers. You just need
> > to superficially look at QVe
On quarta-feira, 29 de março de 2017 08:44:35 PDT Thiago Macieira wrote:
> Ok, so I guess we can easily benchmark this by making the Qt containers
> forget about the movable property, then benchmark the load time of a large
> application like Qt Creator. Unfortunately, this means recompiling
> ever
On quarta-feira, 29 de março de 2017 02:53:16 PDT Ville Voutilainen wrote:
> The hard number we still need is this:
> 1) how much of a performance difference does a destructive move make
QVector is all you need to see that.
Without destructive moves:
1) allocate new block
2) move each element (
On 29 March 2017 at 12:49, Marc Mutz wrote:
> This is probably one of the most important things. Ville asked on std-
> proposals to show hard numbers. You don't need hard numbers. You just need to
> superficially look at QVector. The compiler generally cannot proove
> that the call to QArrayData::
On Monday 20 March 2017 22:19:11 Thiago Macieira wrote:
> Em sábado, 18 de março de 2017, às 14:20:49 PDT, Thiago Macieira escreveu:
> > == Containers ==
> >
> > And then there's what to do with the containers. Here's where Marc's
> > opinion and mine differ considerably. Aside from the need to ma
Em sábado, 18 de março de 2017, às 14:20:49 PDT, Thiago Macieira escreveu:
> == Containers ==
>
> And then there's what to do with the containers. Here's where Marc's opinion
> and mine differ considerably. Aside from the need to maintain source
> compatibility, I feel like we should keep our cont
On 3/20/17, 7:02 AM, "Development on behalf of Olivier Goffart"
wrote:
>
>It's true that you cannot serialize a type if you don't have some
> persistent
>identifier such as the name.
This has probably been covered, but it may be worth mentioning. The examples
Konrad used were in-proc
On Montag, 20. März 2017 11:27:44 CET Konrad Rosenbaum wrote:
> Hi,
>
> On Mon, March 20, 2017 08:20, Olivier Goffart wrote:
> > On Sonntag, 19. März 2017 19:51:47 CET Thiago Macieira wrote:
> >> The name is necessary for compatiblity iwth other languages.
> >
> > Can you elaborate?
> > In QtScri
Hi,
On Mon, March 20, 2017 08:20, Olivier Goffart wrote:
> On Sonntag, 19. März 2017 19:51:47 CET Thiago Macieira wrote:
>> The name is necessary for compatiblity iwth other languages.
>
> Can you elaborate?
> In QtScript or QtQml, the name is only used for error message, or for
> compatibility be
On Sonntag, 19. März 2017 19:51:47 CET Thiago Macieira wrote:
> On domingo, 19 de março de 2017 02:24:56 PDT Olivier Goffart wrote:
> > But because QMetaType was historically made for QueuedConnection, it needs
> > the name, and so needs to be declared or registered with
> > Q_DECLARE_METATYPE/ qRe
On domingo, 19 de março de 2017 02:24:56 PDT Olivier Goffart wrote:
> But because QMetaType was historically made for QueuedConnection, it needs
> the name, and so needs to be declared or registered with
> Q_DECLARE_METATYPE/ qRegisterMetaType. But the truth is that we could get
> rid of both alre
On Samstag, 18. März 2017 22:20:49 CET Thiago Macieira wrote:
> Ville asked what would be nice to have, so I put together a list:
>
> == SD-6 feature macros ==
> We made a decision not to add Q_COMPILER_xxx macros in Qt past C++11, and
> only depend on the ones from the standard. But there are sev
Ville asked what would be nice to have, so I put together a list:
== SD-6 feature macros ==
We made a decision not to add Q_COMPILER_xxx macros in Qt past C++11, and only
depend on the ones from the standard. But there are several problems there:
* some compilers don't have them at all (MSVC). O
14 matches
Mail list logo
