[Interest] chasing a standard

roland at logikalsolutions.com roland at logikalsolutions.com
Mon Nov 26 15:21:16 CET 2018


>
> Hi,
>
> Il 05/11/18 16:07, roland at logikalsolutions.com ha scritto:
>> Switching the containers to just be wrappers around std::
>> 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
(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




More information about the Interest mailing list