[Interest] chasing a standard

[Giuseppe D'Angelo]

Il 26/11/18 15:21, roland at logikalsolutions.com ha scritto:
>>
>> Hi,
>>
>> Il 05/11/18 16:07, roland at logikalsolutions.com ha scritto:
>>> Switching the containers to just be wrappers around std::
>>> implementations would also be a dramatic break.
>>
>> Assuming by "wrappers" you mean "implicitly shared wrappers", why would
>> it be a break?
>>
> 
> No, by wrappers I mean something like QMap becoming nothing more than
> a header file with all of the existing methods either mapping directly
> to their std:: counterparts or stubbed out. 

The idea is that 99% of the methods will map directly to the std:: 
counterparts (acting on the std container under the hood), so indeed 
they'll be very easy stubs, but implicit sharing will be kept. So 
nothing to fear in that regard.


> Do the std:: classes offer
> implicit sharing along with delayed/shallow/copy-when-needed behavior?

Since C++11 the Standard disallows copy on write for the implementations 
of its containers (including strings).


> I don't know and because of Qt I have never had to know. I know in the
> embedded world, many times we structure our solutions based on some of
> these features. On most embedded targets dynamic memory allocation
> sucks. Cheaper RAM with a slower bus, all to conserve battery
> consumption. So, if QMap, QVector, whatever, becomes a header which
> just wraps the std:: container, and if the std:: container __always__
> does a deep copy, the API may appear to be the same, but, many
> embedded systems will break if compiled with a newer version of Qt.

And that's why I said that it would be a massive, unacceptable break if 
we dropped implicit sharing.


> Let's spend a few moments and chat about foreach() while we are at it.
> The C++11 counterpart is range-based for loops.
> 
> https://en.cppreference.com/w/cpp/language/range-for
> 
> Both have their place and both operate differently. 

No; foreach today does not have a place any longer.


> There are times when you need your method/function/task/thread to
> operate on a copy as-it-was-at-this-point-in-time because something
> else could be changing the container or you need to make non-permanent
> changes or whatever reason you wish to come up with. foreach() lets
> you do this without having to muddy up the code with the logic to make
> and destroy a copy. You can read a bit more about it here.

Experience actually shows that this is a terrible misfeature of foreach. 
Apart from the obvious performance argument, apart from the teachability 
problem I have already stated, the implicit copy makes it very very hard 
to reason about loop invariants.

For instance, the copy makes it impossible in the general to simply 
replace foreach with a range-based for -- the loop could be coded in a 
way that relies on the copy to take place, thus it is safe to modify the 
original container from within the body. Given that the actual 
modification could be hidden behind several levels of function calls, 
one is going to have a very hard time tracking down what is going on in 
a given foreach, and if it's safe at all to replace it with a for.

This isn't hearsay; such loops were actually found when getting rid of 
foreach usages from within Qt.


And what's so complicated with "the logic to make and destroy a copy"?

auto copy = original;
for (whatever : copy) body;


> https://stackoverflow.com/questions/14317503/qts-foreach-expression-requires-a-deep-copy
> 
> If the underlying containers become pure STL containers under the
> hood, does foreach() remain? 

The discussion of the future of foreach is independent from the future 
of iterators. For me, IMO, foreach should go away in Qt 6 no matter what 
happens with the containers.


> Let's be honest here. Most programmers suck at iterators. Many times
> they are the correct solution, but, most of us will change our design
> to avoid them. 

"Most" of us is an unjustified over-generalization.


> Well we did until the Qt containers made them rather
> easy. 

How did Qt containers make iterators easy exactly? To my book, Qt 
containers made iterators _harder_, for instance all the dangers related 
to mixing const and non-const iterators.


> Yes, STL has made their map() class rather close to QMap, but,
> it's not the same.
> 
> http://www.cplusplus.com/reference/map/map/

1) What has std::map to do with *ANY* of this? Why do you keep changing 
topic randomly in the body of the same email?

2) The only touching point between std::map and QMap in history is 
C++2a's std::map::contains. Saying that someone "made map close to QMap" 
is an historical false.


> I realize the focus for the Qt project in general is worthless QML and
> Web Web Web, but, the stuff which makes all our lives better doesn't
> use any of that. There are two horrible things driving that focus.

And once more, a nice combo of false statements and free-style FUD!


> 1) non-disclosure agreements

Can you please re-read yourself and realize how complete and utter 
nonsense this sounds?

"Non-disclosure agreements are driving the focus for the Qt Project 
[towards QML and web]"

Besides the fact that it's a *lie*, of course. The Qt Project doesn't 
have mandate any NDA whatsoever.


> 2) Qt licensing
> 
> Every Tom, 

[snip -- massive, off-topic licensing rant that I won't really comment upon]


-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20181127/31bae77a/attachment.bin>