[Interest] chasing a standard

[roland at logikalsolutions.com]

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