[Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Julien Blanc]

On 10/02/2015 17:33, Olivier Goffart wrote:
> On Tuesday 10 February 2015 17:08:55 Julien Blanc wrote:
>> On 10/02/2015 16:33, Knoll Lars wrote:
>>> IMO there’s simply too many questions that this one example doesn’t answer
>>> to conclude that what we are doing is bad.
>> Two arguments :
>> - implicit sharing is convenient, and really developer friendly. It is
>> probably a good idea since strings are really present a lot in signals
>> and slots (and afaik, passed by value in these context)
>> - implicit sharing is implicit, you don’t have the choice not to pay for
>> it, which is a bad thing.
>>
>>   From my experience, QStrings are slow. About two times slower than
>> using plain std::string in our use cases, but the culprit for this
>> slowness is, as far as we know, the internal 16 bits encoding, whereas
>> our data sources are all using utf-8. We have no evidence that the
>> implicit sharing cost is significant or not.
> std::string is NOT an equivalent of QString

No, they’re not equivalent. I was not saying that QString is poorly 
optimized or so. I was saying that QString is about twice slower than 
std::string in our use case, which starts to make us think seriously to 
get completely rid of it in some parts of our code (the non gui parts).

> The equivalent of QString would be std::wstring or std::u16string.
> The equivalent of std::string would be QByteArray.
The bad thing being that you can’t seriously replace QString with 
QByteArray, in, nearly everywhere. QtSql uses QString, QtXml uses 
QString, and nearly anything that works with strings in Qt uses QString, 
because that is the default string class. Which means getting rid of 
QString is also getting rid of these components, which starts to be a 
big deal.

> Note that some STL implementation (most notably the GNU one) use implicit
> sharing for std::string
That may have been true in the past, but i’m pretty sure this is no 
longer the case now. The main problem with COW for std::string is that 
operator[] non-const may invalidate iterators, which is really something 
you don’t expect (i can’t find evidence that the standard forbids it 
though i’ve read it somewhere).

> Also, we don't share data structures among threads so much in a 
> typical application. So the arguments given against implicit sharing 
> are not really valid. 

In fact that makes them worse. It means you pay for something you don’t 
use. The question being « is it worth the cost » is probably yes if you 
consider it permits lazy developers to not crash their application 
because QString is thread safe. Problem comes when you know what you’re 
doing and don’t want to pay for features you don’t use.

Regards,

Julien Blanc