[Interest] Chasing a standard

[Roland Hughes]

Quoting Elvis Stansvik:

====
Sorry to say it, but welcome to C++

No, mostly kidding. I think what you suggest sort of makes sense. If
Qt are to keep its containers, with a goal of offering an alternative
more convenient/Java-esque API, then a helper member function like you
suggest seems to fit that goal. Whether Qt still has this as a goal in
another matter. Maybe not to the extent that they once had?

For the pattern above, I guess one could make a generic helper in a
header of the application. I know e.g. Qt Creator has a bunch of such
helpers in its headers.
====

I would like to weigh in a vote for Qt keeping its containers. The 
reason behind that vote is the ever present installed base. We already 
lose droves of Qt developers every year when Qt keeps moving on but 
medical devices, border security systems like cargo x-ray, train control 
systems, etc. have to fork their own version of Qt because Qt keeps 
moving on without a 5-8 year LTS.

At this point their are hundreds, thousands, perhaps millions of Qt 
example programs scattered around the Internet, many of which don't 
bother to name the Qt version they were written with, not to mention 
"official" texts which will now mostly not work.

https://www.barnesandnoble.com/w/c-gui-programming-with-qt-4-2nd-edition-jasmin-blanchette/1101413840?ean=9780132354165 


Granted that one actually names Qt 4 but programming languages as wells 
as their libraries have a time honored tradition of just adding, not 
dropping major components.

Okay, BASIC dropped IRREGARDLESS and C++ has _finally_ dropped 
trigraphs, but neither were major components.

Yes, I have heard various young guns in here chanting the mantra "why 
spend resources maintaining something std now does?" Well, the installed 
base is the reason. Under the hood feel free to change them 
dramatically, but, maintain the API. It doesn't matter if std:: is 
adopting many Qt-esque things, we have always had levels of 
compatability with std:: I mean QString has had it since I started with 
Qt, seriously, back at 4.0. My 3.x time was just dabbling.

The second argument I will make in favor of keeping the containers is 
the mantra which drew so many to Qt so many years ago.

All objects derived from QObject are cleaned up on exit.

Yes, that is very Java like. When we start mixing and matching QObject 
containers with std:: we run the risk of going straight back to the dark 
ages writing programs for feeble PC based operating systems which cannot 
clean up behind a process. (Before anyone challenges that they need to 
read up on OpenVMS, MVS, and Z/OS.)

I will cede the point that foreach will probably die a much deserved 
death in the near future, even if it remains in the package. Range-based 
for loops
https://en.cppreference.com/w/cpp/language/range-for
and especially for_each
https://en.cppreference.com/w/cpp/algorithm/for_each

The dark side of Qt's foreach was making a copy to operate on. Yes, 
there were reasons for it, but, it was a stumbling block for more than 
one developer new to Qt and in the embedded systems world, that copy 
could be massively expensive.

-- 
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