Il 26/11/18 15:21, [email protected] ha scritto:
Hi, Il 05/11/18 16:07, [email protected] 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 directlyto 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-forBoth 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 thehood, 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 designto avoid them.
"Most" of us is an unjustified over-generalization.
Well we did until the Qt containers made them rathereasy.
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 licensingEvery Tom,
[snip -- massive, off-topic licensing rant that I won't really comment upon] -- Giuseppe D'Angelo | [email protected] | 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
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
