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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
