[Interest] (no subject)

[Prav]

> Please tell me: which smart pointer is best for each situation?
> QSharedPointer, QScopedPointer, QSharedDataPointer, 
> QExplicitlySharedDataPointer, QPointer, std::unique_ptr.
It is a good point that no good description of this things existin qt-docs.

I would expect to find article in the
http://doc.qt.io/qt-5/topics-core.html
along somewhere near containers ... but I did not found.

Your article
http://blog.qt.io/blog/2009/08/25/count-with-me-how-many-smart-pointer-classes-does-qt-have/
is  worth  adding to mentioned page in documentation.

But this is question to documentation.
It seems that if documentation have table with pointers types and service they provide it would be easy to select depending on requirements people expect from pointer.


> When should you use QStringLiteral, QString::fromLatin1 or QLatin1String?
Same happenes with this selection also. No clear description in the documentation.


I do not see problem with selecting best option as soon as this options are clearly described in documentation.
And where is not so many things which is unclear for selection ... so not a problem to understand thma all. Or I am wrong?


There is only one advantage of using currect foreach ... if it is not clear how container could change because of signal-slots calls
   (but I never saw any example showing that foreach is better than const-ref to container loop when dealing with Qt's signal-slots)


> Because providing subtly different options confuses when it is right to use each one.
And const-ref loop seems to be the best for Qt and std containers.
So recomendation can be to use "forevery" everythere (with Qt containers or std containers ... does no matter) except you have some special cases with signal-slots calls (which I never saw)
I think it is quite a clear choice.


> We will not add another macro for this.
Well ... if this will be decided ... in this case anyone can define the macro for their porject if they like ... but in this case we need to remember that it is fair enough
for people to have their own for loops definition and Qt Creator's code completion should not work just for "foreach".



> On Saturday 27 June 2015 16:45:28 Prav wrote:
>> > Whatever the original reason was: The possibility to change the original
>> > container while iterating over it with foreach might be a bit 'special',
>> > but is not that uncommon. I don't think we can change therefore the
>> > behavior anymore.
>> If you read my question:
>> Although current implementation of iterator-loop have the right to exist but
>> in this case I would expect it to co-exist with another iterator-loop which
>> works in more straightforward for developers way (with just const-ref to
>> container).

> If the copying version works for the Qt containers, we're happy. We're not
> going to add another macro that doesn't copy for the sub-microsecond 
> optimisation in Qt containers, thus making the API uglier and developers more
> confused.

>> As you see I am wondering why only one way of doing loop exists. 

> Because providing subtly different options confuses when it is right to use
> each one.

> Please tell me: which smart pointer is best for each situation? 
> QSharedPointer, QScopedPointer, QSharedDataPointer, 
> QExplicitlySharedDataPointer, QPointer, std::unique_ptr.

> When should you use QStringLiteral, QString::fromLatin1 or QLatin1String?

> We will not add another macro for this.




-- 
С уважением,
 Prav                          mailto:pr12og2 at programist.ru