[Development] Question about QCoreApplicationData::*_libpaths

Bubke Marco Marco.Bubke at theqtcompany.com
Mon Jan 18 20:17:25 CET 2016


On January 18, 2016 19:57:48 Matthew Woehlke <mwoehlke.floss at gmail.com> wrote:

> On 2016-01-18 13:40, Bubke Marco wrote:
>>> On 2016-01-16 07:06, Bubke Marco wrote:
>>>> std::is_trivially_copyable and other type traits are your friends.
>>>
>>> Not really. There is a huge difference between a relocatable type (many,
>>> if not most), and a trivially copyable type (a lot fewer). Operations
>>> such as growing the buffer can be vastly more expensive if the item type
>>> is not relocatable vs. if it is. However, C++ itself currently does not
>>> provide any support for relocation.
>> 
>> So how many people define there objects as relocatable?
>
> Only Qt users. C++ proper doesn't have such a concept (yet) :'(.

I mean how many Qt users using that feature. ;-)

>> Anyway for large vectors I use always reserve which is a quite common optimization.
>
> This of course assumes that a) you know in advance how large your vector
> needs to be, and b) that it will actually be that large, or that the
> cost of possibly unused memory is low.

Unused memory for big chunkd is not that expensive in many cases because of overcommitment. 

> I'll still assert that C++ needs relocatability :-).

I believe that to. It would be nice if there would be a zero move constructor optimization too.  So if your move it sets you memory to zero so whole range would be simply memsetted. So you can simply copy that span and than memset the old area to zero. 

Building a structure which defaults to zero is not that hard in many cases. 

>>>   auto value = container.maybe_at(key);
>>>   if (value)
>>>     do_something(*value);
>>>
>>> (...using std::optional or similar)
>>>
>>> This is easy to read, easy to write, *and* efficient.
>> 
>> I would prefer ranges.
>
> How do ranges solve the problem of doing something with an element iff
> it exists in the container?
>
>> I think the next big step is easy writable parallel algorithms and
>> hand written code like that is in my opinion not that maintainable.
>
> I'm not sure what you mean by "hand written code"? How *else* would you
> write something like the above?

I mean it is more functional. But for that cases you have to know the context. 

> -- 
> Matthew
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Sent from cellphone, sorry for the typos



More information about the Development mailing list