[Development] Question about QCoreApplicationData::*_libpaths

Matthew Woehlke mwoehlke.floss at gmail.com
Mon Jan 18 19:57:23 CET 2016

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) :'(.

> 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.

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

>>   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?


More information about the Development mailing list