Il 27/11/18 15:35, [email protected] ha scritto:
Quoting Giuseppe D'Angelo: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.There are __tons__ to fear in that regard. Using the standard container under the hood is illconceived.
And the technical arguments for this are...?
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).so it will break much
I'm now seriously thinking you're trolling this mailing list, and thinking of calling a moderation on you.
"So" means there's an implication of sorts. Where does this implication come from?
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.Foreach still has a place and, more importantly, has an installed base.
The installed base can migrate away to the new tools, or (as already stated SEVERAL times already) copy and paste foreach's definition in their projects and keep using it. "Has an installed base" isn't a compelling argument for API evolution; ballast needs to be dropped from time to time, because development bandwidth is finite.
Unlike God at the creation of the universe, foreach has an installedbase.
See above.
It wasn't unteachable nor was it unlearnable.
I did not say it's UNteachable, I said it's DIFFICULT to teach. Stop altering other people's positions for the sake of your own argument.
While people didstumble a bit trying to delete items using foreach().
Or mutate elements, or understand that it is expensive when used on a "wrong" container, or understand that it's a macro so you will struggle with commas into it, or...
Foreach() has a place. It allows logic which needs a copy to exist and still be clean. Range based for loops can be used on things which cannot be copied or where a copy is not needed for the logic.
Because taking a copy explicitly is nonsense -- never heard of that in C++. It must be impossible to do.
And what's so complicated with "the logic to make and destroy a copy"? auto copy = original; for (whatever : copy) body;Ah yes, the spherical cow argument. https://en.wikipedia.org/wiki/Spherical_cow https://upload.wikimedia.org/wikipedia/commons/thumb/2/24/Spot_the_cow.gif/220px-Spot_the_cow.gif
Ah yes, the "I don't know what to answer technically, so I'll come up with a bunch of random links and make it personal" argument. Works every time.
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.It's highly justified. Someone offering up the spherical cow argument should be well aware of it. Speaking as someone who writes an award winning technical book series. http://theminimumyouneedtoknow.com/ With a title on Dr. Dobb's developer reading list http://www.drdobbs.com/tools/developers-reading-list/232500396?pgno=6 and someone who ends up working with/training the kids my clients hire right out of school where they've been fed a lot of spherical cow but little in the way of real world education, the bulk of developers on this planet suck at iterators.
Find better developers, then. I'm glad to work with colleagues and customers that are perfectly comfortable with iterators.
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.They made it easier, especially for the younger developers. In large part by obfuscating the fact they were using iterators and by providing foreach() which meant the number of situations where they actually had to use them were greatly reduced.
You state "by obfuscating the fact they were using iterators and by providing foreach()", so, apart from foreach, where's the part where Qt obfuscates the fact that you're using iterators, thus making "it" easier?
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 didn't change the topic.
So let me quote the original email again:
Most programmers suck at iterators. Many times they are the correct solution, but, most of us will change our design to avoid them. Well we did until the Qt containers made them rather easy. Yes, STL has made their map() class rather close to QMap, but, it's not the same.
Discussion about foreach and iterators => random jump to discuss std::map vs QMap.
Maybe you spent far too much time with thespherical cow?
Personal insults again? Ok...
We are still on the topic of the horribly misguided and uneducated attempt of replacing Qt containers "under the hood" withstd:: containers.
It's very very important for all of us that you keep saying that and never bring an ounce of technical argument. But by all means, bring more links!
This includes navigation via foreach(), which must remain because it has a rather significant installed base which might one day need tomove forward and because of the tool it is.
See above (2).
It also includes the discussion of iterators which many developers suck at and few are anywhere near as good as they think. So, if QMap were to be replaced "under the hood" by std::map and had one scrolled down to the Member functions seciont of the providedlink, what would they see?
Ok, so, let's follow this down. Hypothesis: QMap gets replaced by std::map under the hood, and I open a community website about std::map. What would I see?
Well, a safe bet would be: std::map's community documentation.What have we learned from this thought experiment? I'm not sure. Probably to stop trying to understand your reasoning.
(Stop inhailing the spherical cow and actually do it.)
Personal insults again.
Well, you probably won't. It would shatter your tiny little universe.
Personal insults again (3).
Here's a snippet.
[snip] For the record: 1) You copy and pasted (some) APIs from a random community website2) Those APIs are just the C++11 ones (because that particular community website is not being updated); the entirety of C++17 and C++2a std::map APIs are missing.
3) std::map in C++ is a formal specification, not (just) an API dump.
Gee, what happens when one looks at the doc for QMap? http://doc.qt.io/qt-5/qmap.html While you see many more methods in QMap, that core API is the same. We don't have the crbegin() and crend() as well as a few other things and we have many more than are listed on that link.
And the conclusion is that it's thus perfectly possible (and sensible) to reimplement QMap on top of std::map, given that the "core API is the same". Did you forget to make your point here?
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!True statements which are neither false nor FUD.
They're false, and they're FUD. Dispute this one again and I'll raise moderation.
1) non-disclosure agreementsCan 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.Have you ___EVER___ worked in the real world on a real project? I'm serious. You sound just as clueless as a career academic.
Personal insults once more, and once more the art of changing topic. You didn't AT ALL address what you originally stated about the Qt Project issuing NDAs, which was the original (completely false) statement.
Basically these threads are becoming a constant: You: <false statement> Someone else: <that statement is false>You: <software engineering, licensing, recipe for mac&cheese, personal insult, 22 links, open source, more software engineering, marginally touching the original topic (without however addressing the very exact statement), personal insults again, discussion about containers work in Java>
Developers working on the facial recognition systems today, using a version of Qt (I was contacted about taking the project, but didn't) WILL NOT BE ABLE TO PUBLICLY DISCUSS IN ANY MEANINFUL WAY WHAT THEY DID WITH QT UNTIL THE ENTIRE PROJECT IS DECLASSIFIED which may not be while you're still alive. The Japanese "death ray" experiments during WWII didn't get declassified until some time in the early 2000's. https://airminded.org/2010/01/24/a-japanese-death-ray/
Pfft, I can say it even *today*! I work on chemtrails dispersion systems on airplanes, for mass population mind control. All the UIs are built using Qt and Linux, and developed using AGILE! It might not be enough to go to the Moon, but boy oh boy isn't it just exquisite for this use case.
It's completely on-topic. This is qt-interest and right now the Qt licensing model is chasing the standard of the late 1980s through early 1990s where people all tried to get royalties. Off the top of my head I don't know of any of those companies which still exists today. Ones which chased a royalty licesning model that is.
Sure, licensing discussions are perfectly on topic with iterators. -- 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
