[Development] Question about QCoreApplicationData::*_libpaths

Matthew Woehlke mwoehlke.floss at gmail.com
Fri Jan 22 18:34:26 CET 2016


On 2016-01-22 13:13, Marc Mutz wrote:
> On Friday 22 January 2016 17:44:40 Thiago Macieira wrote:
>> On Friday 22 January 2016 11:14:47 Marc Mutz wrote:
>>> On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote:
>>>> What
>>>> i'm missing?
>>>
>>> You haven't done the exercise with the int first.
>>
>> Here's the exercise with int. This is thread-safe:
>>
>> int f()
>> {
>> 	return 1;
>> }
>>
>> 	auto x = f();
>> 	++x;
>>
>> No matter how many threads call f(), all of them will get a value from f,
>> can assign it to a variable and modify without caring what other threads
>> do.
>>
>> Replace int with QMap or QString and you have the same behaviour.
> 
> This part of the discussion was about copying a container. You return a new 
> instance instead. Returning a new instance does not copy, nor move, due to 
> NRVO.

The same assertions would hold if Thiago had written:

  int f()
  {
    static int result = 1;
    return result;
  }

...or anything else for the body of f().

And in fact, you're again attacking a straw man. The implementation of
getMap() was not shown; for all you know, it too might have returned a
new instance every time. (Probably not, but doesn't matter.)

What matters is that the result is returned *by value*. It is thread
safe because it is not a reference, it is a copy. Qt containers are
likewise thread safe because they behave (in a thread-safe manner) *as
if* an actual copy was made (even though the actual copy might not
happen until some time later, if ever).

-- 
Matthew




More information about the Development mailing list