[Interest] chasing a standard

[r***@logikalsolutions.com]

Hi,

implementations would also be a dramatic break.

Assuming by "wrappers" you mean "implicitly shared wrappers", why would
it be a break?

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. Do the std:: classes offer
implicit sharing along with delayed/shallow/copy-when-needed behavior?
I don't know and because of Qt I have never had to know. I know in the
embedded world, many times we structure our solutions based on some of
these features. On most embedded targets dynamic memory allocation
sucks. Cheaper RAM with a slower bus, all to conserve battery
consumption. So, if QMap, QVector, whatever, becomes a header which
just wraps the std:: container, and if the std:: container __always__
does a deep copy, the API may appear to be the same, but, many
embedded systems will break if compiled with a newer version of Qt.
They will break in the worst way, compiling clean and randomly failing
on the test target or in the field due to unpredictable dynamic memory
allocation speed. (It tends to range from bad to unbelievably horrible.)

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. foreach() makes a
copy of the container while the new(er) range-based for loop does not.
Come on, everybody who first tried learning Qt ended up doing
something like this:

https://stackoverflow.com/questions/17494139/proper-way-to-modify-qt-data-structures-using-foreach-loop

We just don't often admit it. <Grin>

There are times when you need your method/function/task/thread to
operate on a copy as-it-was-at-this-point-in-time because something
else could be changing the container or you need to make non-permanent
changes or whatever reason you wish to come up with. foreach() lets
you do this without having to muddy up the code with the logic to make
and destroy a copy. You can read a bit more about it here.

https://stackoverflow.com/questions/14317503/qts-foreach-expression-requires-a-deep-copy

If the underlying containers become pure STL containers under the
hood, does foreach() remain? Does it still do a deep copy? In the
embedded world I try not to use foreach() because of dynamic memory
allocation generally sucking on the target. Not all of my work is
embedded though and foreach() is really convenient when I can be as
sloppy as Microsoft with memory useage.

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

http://www.cplusplus.com/reference/map/map/

Once again the embedded world will have to climb under the hood to see
how it uses memory.

Just my 0.0002 cents

Sorry for the delayed response. Been heads down on a project so things
requiring a bit more thought have been put on hold. I'm a bit
sensitive to the dynamic memory thing now that it is possible
(depending on how negotiations go over the next two weeks) that I will
be jumping into another medical device project. Starting to get into
that mindset now.

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.

1) non-disclosure agreements
2) Qt licensing

Every Tom, Dick and Harriet blabs profusely about the bug-ridden idiot
phone app they just made available for sale somewhere. People who make
surgical robots, cargo container scanners, facial recongition hand
held devices, x-ray equipment and other medical devices can't say boo
for decades. None of these industries will pay per unit royalties
either. Reasonable one-time developer licenses and possibly token
annual support contracts, but, royalties, no. Worked at one client
site where they gladly spent close to $250K in developer time for us
to tweak the code and make it run on a CPU which had no GPU. That same
CPU with a GPU on it cost 0.25 more.

If it wasn't for the non-disclosure agreements and current Qt
licensing, somewhere on-line there could actually be a list of all the
devices saving and protecting lives built with Qt. Some are still
using Qt 3.x and OS/2.

Back in the day we used to pay upwards of $500 for a C compiler and
close to $300 for an editor, then another $450 for an overlay linker
which would let us create programs which couldn't fit inside of 640K
boundary. Unbelievably, SlickEdit still thinks they can charge that
price.

https://www.slickedit.com/

Quite a different story for Sublime Text https://www.sublimetext.com/buy
Hmmm... I thought it was $20 when I bought it? Still, one-time $80 and
use it on as many machines as you like, it's worth it. KATE doesn't
run on every platform and UltraEdit is worthless at C/C++
https://www.ultraedit.com/ Eclipse has always sucked (and been a
massive pig) and most every other editor I've tried over the years
came up drastically short at a critical time.

At any rate, this pursuit of royalties is a bad business model.
Pursuing Idiot Phone Apps is even dumber than investing in bitcoin.

https://finance.yahoo.com/m/380bf339-ad87-3baf-9ff1-2c7ea9ca4746/bitcoin-breaks-below-%244%2C000.html

Professional developers and legit corporations will gladly pay
somewhere between $500-$800 for a commercial quality package that can
be installed on whatever machine (or VM) they feel like using today
and has no royalties. They would even pay somewhere between
$50-$80/year maintenance/support fee. Focusing on the Idiot Phone App
market is pretty much the same as a retirement plan based on a winning
lottery ticket.

https://duckduckgo.com/?q=e-trade+lottery+commercial&t=ffnt&atb=v143-7ap&ia=videos&iax=videos&iai=L9JP0oy5M2c
--
Roland Hughes, President
Logikal Solutions
[phone]

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