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.
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
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.
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.
Unlike God at the creation of the universe, foreach has an installed
base. It wasn't unteachable nor was it unlearnable. While people did
stumble a bit trying to delete items using foreach(). 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.
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
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.
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.
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. Maybe you spent far too much time with the
spherical cow? We are still on the topic of the horribly misguided and
uneducated attempt of replacing Qt containers "under the hood" with
std:: containers. As part of that discussion one must take into
account how memory is utilized and how the containers are navigated.
This includes navigation via foreach(), which must remain because it
has a rather significant installed base which might one day need to
move forward and because of the tool it is. 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 provided
link, what would they see? (Stop inhailing the spherical cow and
actually do it.)
Well, you probably won't. It would shatter your tiny little universe.
Here's a snippet.
=====
Iterators:
begin
Return iterator to beginning (public member function )
end
Return iterator to end (public member function )
rbegin
Return reverse iterator to reverse beginning (public member function )
rend
Return reverse iterator to reverse end (public member function )
cbegin
Return const_iterator to beginning (public member function )
cend
Return const_iterator to end (public member function )
crbegin
Return const_reverse_iterator to reverse beginning (public member
function )
crend
Return const_reverse_iterator to reverse end (public member function )
Capacity:
empty
Test whether container is empty (public member function )
size
Return container size (public member function )
max_size
Return maximum size (public member function )
Element access:
operator[]
Access element (public member function )
at
Access element (public member function )
Modifiers:
insert
Insert elements (public member function )
erase
Erase elements (public member function )
swap
Swap content (public member function )
clear
Clear content (public member function )
=====
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.
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.
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.
Have you ___EVER___ worked in the real world on a real project? I'm
serious. You sound just as clueless as a career academic.
A surgical robot will have a clinical trial period of up to 7 years.
There will be 1-3 years of software development in front of that. The
entire codebase may well be built with an OpenSource version of Qt but
the NDA will be for 15 years.
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/
These (sans the Japanese death ray) are real systems which use real
software engineering, not one of the 32767 flavors of AGILE hacking on
the fly which are out there. They have the ability to save and take
lives. When they use an OpenSource version of Qt for development (many
still using 4.x and some 3.x) the powers which be at Qt cannot and do
not hear it. The NDA prevents this knowledge from leaking out and
sadly, Qt doesn't get steered in the correct direction because of
them. All the powers that be get to hear about are the worthless idiot
phone apps who are all trying to hit the app store lottery. Because of
this reality massive resources were wasted on bringing QML to life and
the bulk of the development focus shifted to idiot phones and Web.
2) Qt licensing
Every Tom,
[snip -- massive, off-topic licensing rant that I won't really comment upon]
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.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
_______________________________________________
Interest mailing list
[email protected]
https://lists.qt-project.org/listinfo/interest
