2018-11-04 21:13:28 UTC
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.
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
and especially 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