Discussion:
Qt API annoyances: where to log/discuss?
(too old to reply)
Jason H
2018-10-30 15:39:22 UTC
Permalink
I was wondering if there is a place to log annoyances/discuss with the Qt5 API for fix in Qt6?


Two I am thinking of right now is:
- QUrl::port() returns an int, but QTcpServer accepts a quint16, so no matter what I do, unless I add a cast, I get a warning.
- Similarly with QImage::pixel there are signed/unsigned issues between pixel and qRgb().

Also, as I go between several languages, I find myself wanting to use lambdas more in a functional programming style. (
I would like a lambda for QImage::pixel ([] (x,y,pixelValue) { } ) (This one is neat because you can use scanline() transparently)
Also for the various containers.
Konstantin Shegunov
2018-10-30 15:44:32 UTC
Permalink
Post by Jason H
I was wondering if there is a place to log annoyances/discuss with the Qt5
API for fix in Qt6?
Probably a good idea is to submit a suggestion to the bugtracker as well.
Post by Jason H
- QUrl::port() returns an int, but QTcpServer accepts a quint16, so no
matter what I do, unless I add a cast, I get a warning.
- Similarly with QImage::pixel there are signed/unsigned issues between
Post by Jason H
pixel and qRgb().
Yep, happens from time to time when the codebase grows, e.g.
https://bugreports.qt.io/browse/QTBUG-69752
Thiago Macieira
2018-10-30 19:23:03 UTC
Permalink
Post by Jason H
I was wondering if there is a place to log annoyances/discuss with the Qt5
API for fix in Qt6?
This list or the development mailing list are fine.
Post by Jason H
- QUrl::port() returns an int, but QTcpServer accepts a quint16, so no
matter what I do, unless I add a cast, I get a warning.
That's because QUrl::port() can return -1, indicating "no port was set in the
URL". QTcpServer needs a valid port number. So the warning is correct and
should be acted on.
Post by Jason H
- Similarly with
QImage::pixel there are signed/unsigned issues between pixel and qRgb().
Sounds like something to be fixed.
Post by Jason H
Also, as I go between several languages, I find myself wanting to use
lambdas more in a functional programming style. ( I would like a lambda for
QImage::pixel ([] (x,y,pixelValue) { } ) (This one is neat because you can
use scanline() transparently) Also for the various containers.
Highly inefficient, so unlikely to happen.

As for the containers, use <algorithm> and C++2a Ranges.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Jason H
2018-10-31 17:35:15 UTC
Permalink
Sent: Tuesday, October 30, 2018 at 3:23 PM
Subject: Re: [Interest] Qt API annoyances: where to log/discuss?
Post by Jason H
I was wondering if there is a place to log annoyances/discuss with the Qt5
API for fix in Qt6?
This list or the development mailing list are fine.
Post by Jason H
- QUrl::port() returns an int, but QTcpServer accepts a quint16, so no
matter what I do, unless I add a cast, I get a warning.
That's because QUrl::port() can return -1, indicating "no port was set in the
URL". QTcpServer needs a valid port number. So the warning is correct and
should be acted on.
I thought QUrl::port() can take a default port if not set. Does it need to be able to return negative?
Post by Jason H
- Similarly with
QImage::pixel there are signed/unsigned issues between pixel and qRgb().
Sounds like something to be fixed.
Post by Jason H
Also, as I go between several languages, I find myself wanting to use
lambdas more in a functional programming style. ( I would like a lambda for
QImage::pixel ([] (x,y,pixelValue) { } ) (This one is neat because you can
use scanline() transparently) Also for the various containers.
Highly inefficient, so unlikely to happen.
In my own testing it was not that inefficient. In fact the lambda using scanLine() was faster than using pixel(), but yes slower than using scanLine with for loops.
As for the containers, use <algorithm> and C++2a Ranges.
I attempted this recently, but failed to figure out how to do the following:
QVector<int> triple = apply(QVector<int> {1,2,3},[](item) { return item*3;});
or
QVector<int> originals {1,2,3};
QVector<int> triples = originals.apply([](item) { return item*3;});

My options are std::for_each, std::transform, but they all have an ugly, over-complicated syntax.

Compare that to:
std::vector<int> originals { 1,2,3};
std::vector<int> triples;
std::transform(originals.begin(), originals.end(), std::back_inserter(triples), [](int item){ return item*3; });

Sure the std way works 100% of the time, but I don't want to read that code, much less write it. I think there's something about how "friendly" and "beautiful" Qt code looks.
Thiago Macieira
2018-10-31 19:42:02 UTC
Permalink
Post by Jason H
Post by Thiago Macieira
That's because QUrl::port() can return -1, indicating "no port was set in
the URL". QTcpServer needs a valid port number. So the warning is correct
and should be acted on.
I thought QUrl::port() can take a default port if not set. Does it need to
be able to return negative?
Since the argument is int, yes.

I can add a quint16 overload, so it returns quint16 too, but I can't remove
the int overload right now. Change subject to whether this would cause
ambiguous overloads.

But if it works, we can deprecate the int overload now and think of removing
it for Qt 6.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Elvis Stansvik
2018-10-31 19:42:13 UTC
Permalink
Post by Jason H
Sent: Tuesday, October 30, 2018 at 3:23 PM
Subject: Re: [Interest] Qt API annoyances: where to log/discuss?
Post by Jason H
I was wondering if there is a place to log annoyances/discuss with the Qt5
API for fix in Qt6?
This list or the development mailing list are fine.
Post by Jason H
- QUrl::port() returns an int, but QTcpServer accepts a quint16, so no
matter what I do, unless I add a cast, I get a warning.
That's because QUrl::port() can return -1, indicating "no port was set in the
URL". QTcpServer needs a valid port number. So the warning is correct and
should be acted on.
I thought QUrl::port() can take a default port if not set. Does it need to be able to return negative?
Post by Jason H
- Similarly with
QImage::pixel there are signed/unsigned issues between pixel and qRgb().
Sounds like something to be fixed.
Post by Jason H
Also, as I go between several languages, I find myself wanting to use
lambdas more in a functional programming style. ( I would like a lambda for
QImage::pixel ([] (x,y,pixelValue) { } ) (This one is neat because you can
use scanline() transparently) Also for the various containers.
Highly inefficient, so unlikely to happen.
In my own testing it was not that inefficient. In fact the lambda using scanLine() was faster than using pixel(), but yes slower than using scanLine with for loops.
As for the containers, use <algorithm> and C++2a Ranges.
QVector<int> triple = apply(QVector<int> {1,2,3},[](item) { return item*3;});
or
QVector<int> originals {1,2,3};
QVector<int> triples = originals.apply([](item) { return item*3;});
My options are std::for_each, std::transform, but they all have an ugly, over-complicated syntax.
std::vector<int> originals { 1,2,3};
std::vector<int> triples;
std::transform(originals.begin(), originals.end(), std::back_inserter(triples), [](int item){ return item*3; });
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.

Elvis
Post by Jason H
Sure the std way works 100% of the time, but I don't want to read that code, much less write it. I think there's something about how "friendly" and "beautiful" Qt code looks.
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Jason H
2018-10-31 20:37:17 UTC
Permalink
Sent: Wednesday, October 31, 2018 at 3:42 PM
Subject: Re: [Interest] Qt API annoyances: where to log/discuss?
Post by Jason H
QVector<int> triple = apply(QVector<int> {1,2,3},[](item) { return item*3;});
or
QVector<int> originals {1,2,3};
QVector<int> triples = originals.apply([](item) { return item*3;});
My options are std::for_each, std::transform, but they all have an ugly, over-complicated syntax.
std::vector<int> originals { 1,2,3};
std::vector<int> triples;
std::transform(originals.begin(), originals.end(), std::back_inserter(triples), [](int item){ return item*3; });
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 think Qt provides many things, one is an easy-to-read, intuitive API. I don't really think "java-esque" is the right term as Python, JavaScript (my main other languages) read about the same. C++ is out in left field.

When I was reading up on how to do the above, I had to look up back_inserter(), and I don't like it because it violates DRY.
std::transform(A.begin(), A.end(), std::back_inserter(B), ...);
I might complain less if I could do:
std::transform(A, B, ...); but then it's not very clearly assigning, we're actually relying on side-effects so we arrive at:
B = std::transform(A, ...); and now we're not repeating ourselves and not relying on side-effects. This is better than std, and no worse than std, the every way that I care about.

I would be fine with a #include <QtAlgorithms> that provided this API, rather than put it in the container.
Jason H
2018-10-31 20:59:19 UTC
Permalink
Sent: Wednesday, October 31, 2018 at 4:30 PM
Subject: Re: [Interest] Qt API annoyances: where to log/discuss?
Post by Jason H
QVector<int> triple = apply(QVector<int> {1,2,3},[](item) { return item*3;});
or
QVector<int> originals {1,2,3};
QVector<int> triples = originals.apply([](item) { return item*3;});
std::vector<int> originals{1, 2, 3};
std::vector<int> triples = originals | ranges::view::transform([](int i) { return i * 3; });
(modulo typos). Possibly even without the <int>, as std containers have
CTAD.
Thanks Giuseppe! That's getting closer :-) however the expression boggles my mind. "originals | ranges::view::transform" there's a lot of compiler voodoo there. I'm trying to keep up on all the C++0xYZ developments, and still trying to wrap my head around SFINAE. I had to look up CTAD, and that looks like a very good enhancement. I think Qt should hide a lot of that compiler iteration from me ;-) It is an unfortunate phenomenon that I am spending more time decrypting compiler Voodoo. I am thinking that C++ is less a language for writing things in, and rather a language for programming a compiler with the secondary goal of creating an application. <soapbox warning> Too much is being spent on telling the compiler how to build it, rather than just building it. I think this is one thing that Qt can (and should) restore the balance on. "Code less, create more." Spend less time figuring out how to tell the compiler to build it, and let Qt apply() (pun intended) it's transforms to m
ake my effort about application programming not compiler programming.
Jérôme Godbout
2018-10-31 21:19:21 UTC
Permalink
All those back_inserter() and C++0xXY template make our life easier in the end, I strongly suggest you do learn them, they can make very generic code with SFINAE that most other language will have hard time to accomplish with the same final level of performance. It's a good balance of quantity of code vs speed. The draw back, is the learning curve and the readability that are hideous.

I agree there is way too much boiler plate for C++ template syntax, but you can design some helper to simplify your SFINAE or other template usage. back_inserter() for example let you make an algo that work with any type of container that will append data, no matter what that container can be, you can even make your own container as long as you provide the push_back() function.

Why use back_inserter over direct push_back? Because some algo like copy operate on iterator and don't need to be rewritten with a push_back version to work, as simple as that. The mor you will stay close to the iterator and the standard, the easier it will be to code with it.

-----Original Message-----
From: Interest <interest-bounces+godboutj=***@qt-project.org> On Behalf Of Jason H
Sent: October 31, 2018 4:59 PM
To: ***@kdab.com
Cc: ***@qt-project.org
Subject: Re: [Interest] Qt API annoyances: where to log/discuss?
Sent: Wednesday, October 31, 2018 at 4:30 PM
Subject: Re: [Interest] Qt API annoyances: where to log/discuss?
Post by Jason H
QVector<int> triple = apply(QVector<int> {1,2,3},[](item) { return
item*3;}); or QVector<int> originals {1,2,3}; QVector<int> triples =
originals.apply([](item) { return item*3;});
std::vector<int> originals{1, 2, 3}; std::vector<int> triples =
originals | ranges::view::transform([](int i) { return i * 3; });
(modulo typos). Possibly even without the <int>, as std containers
have CTAD.
Thanks Giuseppe! That's getting closer :-) however the expression boggles my mind. "originals | ranges::view::transform" there's a lot of compiler voodoo there. I'm trying to keep up on all the C++0xYZ developments, and still trying to wrap my head around SFINAE. I had to look up CTAD, and that looks like a very good enhancement. I think Qt should hide a lot of that compiler iteration from me ;-) It is an unfortunate phenomenon that I am spending more time decrypting compiler Voodoo. I am thinking that C++ is less a language for writing things in, and rather a language for programming a compiler with the secondary goal of creating an application. <soapbox warning> Too much is being spent on telling the compiler how to build it, rather than just building it. I think this is one thing that Qt can (and should) restore the balance on. "Code less, create more." Spend less time figuring out how to tell the compiler to build it, and let Qt apply() (pun intended) it's transforms to m
ake my effort about application programming not compiler programming.
Jason H
2018-10-31 21:30:26 UTC
Permalink
I don't disagree with you, but I have a variety of developers that work with me/read/modify my code, and they are of varying levels of proficiency (none are actual C++ programmers by choice) (Java is their main language). I want to make things as friendly and obvious and for them (and guiltily, myself). The nice thing is that when the C++ std level of detail is needed it is there. But 99% of the time we have no need for it to be the absolute best performant code. I understand API creators have that requirement, but application developers usually do not. Maybe C++ isn't the right language, but there's so much Qt does right over all the other options we have.

I will continue to increase my proficiency in C++, but this is my personal commitment. I cannot demand the same for the others.
Sent: Wednesday, October 31, 2018 at 5:19 PM
Subject: RE: [Interest] Qt API annoyances: where to log/discuss?
All those back_inserter() and C++0xXY template make our life easier in the end, I strongly suggest you do learn them, they can make very generic code with SFINAE that most other language will have hard time to accomplish with the same final level of performance. It's a good balance of quantity of code vs speed. The draw back, is the learning curve and the readability that are hideous.
I agree there is way too much boiler plate for C++ template syntax, but you can design some helper to simplify your SFINAE or other template usage. back_inserter() for example let you make an algo that work with any type of container that will append data, no matter what that container can be, you can even make your own container as long as you provide the push_back() function.
Why use back_inserter over direct push_back? Because some algo like copy operate on iterator and don't need to be rewritten with a push_back version to work, as simple as that. The mor you will stay close to the iterator and the standard, the easier it will be to code with it.
Jason H
2018-11-01 20:14:00 UTC
Permalink
Sent: Thursday, November 01, 2018 at 3:44 PM
Subject: Re: [Interest] Qt API annoyances: where to log/discuss?
Post by Jason H
Thanks Giuseppe! That's getting closer :-) however the expression boggles my mind. "originals | ranges::view::transform" there's a lot of compiler voodoo there. I'm trying to keep up on all the C++0xYZ developments, and still trying to wrap my head around SFINAE. I had to look up CTAD, and that looks like a very good enhancement. I think Qt should hide a lot of that compiler iteration from me ;-)
You can replace Qt with "the libraries I use". They will hide the
complexity of compiler magic from you (where do you _see_ the magic in
the lines I pasted?).
And every time you use C++ you have the Standard Library with you, which
(crossing fingers) will have ranges in C++2a; why should Qt spend any
time at all implementing something like that?
If anything, this means that QImage should be adapted to be usable
through ranges (!).
Post by Jason H
It is an unfortunate phenomenon that I am spending more time decrypting compiler Voodoo.
Sorry, I don't get this. If you're just using the features, why would
you care about they're implemented? What's there to decrypt?
Just rest assured that any feature coming from the Standard Library
comes from the very same people building your compiler, so it will get
implemented in the best way possible.
originals | ranges::view::transform([](int i) { return i * 3; });

The bitwise OR operator, descending multiple namespaces.
It makes my point. That these very common functional programming paradigms (map, reduce, etc) are (needlessly?) obtuse in C++.

Further more, my point is made qgain with this talk about C++2a. It's something that can be done now, but i shouldn't have to wait, Qt can implement these however it can today and move to ranges when available.
Cheers,
--
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
Jason H
2018-11-02 18:28:35 UTC
Permalink
Post by Jason H
The bitwise OR operator, descending multiple namespaces.
It makes my point. That these very common functional programming paradigms (map, reduce, etc) are (needlessly?) obtuse in C++.
Sorry, what is the point? Is it hard to read, write, teach, learn,
understand, extend...? What is the baseline we're comparing it against?
D) All the above. I didn't understand it when I first read it and I would say I "know" C++ beyond the 50th percentile of people claiming to "know" C++. I'm sure others won't either. Can we get a vote on who understood exactly what that statement was the first time they read it? The baseline I'm comparing it against is Python or JavaScript.
Post by Jason H
Further more, my point is made again with this talk about C++2a. It's something that can be done now, but i shouldn't have to wait, Qt can implement these however it can today and move to ranges when available.
A bit too convenient to just ask someone else to do a _lot_ of work for
Post by Jason H
https://github.com/ericniebler/range-v3
And again, why should Qt invest precious development bandwidth
reinventing half-cooked solutions for problems solved in an excellent
way elsewhere? As I said in the other thread, not using C++-latest costs
_you_ more. It shouldn't cost anything for Qt.
The value proposition of Qt is that it simplifies a lot of things. If we're going to fall back on "std all the things" then Qt (pronounced "Cute", which I think has meaning here) loses a lot of value prop and I should just switch to C++-without-Qt or Python. It is my observation that C++ is becoming a language to not write programs in, but to instruct compilers on how to build your program. (Maybe this is role QML is filling?) If I have to dedicate hours per week to maintaining my C++latest skills (which is futile absent a useful case in my own code base) then that negatively impacts my perception of Qt. Which is frankly irrelevant anyway because my code needs to be readable **by other people**. I don't know why C++ enthusiasts are so hostile to newcomers, effectively raising the barrier to entry. This plays out in non-abstract terms. C++ is the fastest declining language at TIOBE ( https://www.tiobe.com/tiobe-index/ ) over the past 10 years. There were no positive spikes aro
und each C++0x release. This stuff is being added and it's not attracting users. Meanwhile Python is fastest increasing (at this time, it's Java, C, C++, Python, VB.NET) (I do think JavaScript is under-reported, as the web is not getting off JS anytime soon)


Let's look at Python's map/filter/reduce ( http://book.pythontips.com/en/latest/map_filter.html )

items = [1, 2, 3, 4, 5]
squared =map(lambda x: x**2, items)
less_than_zero = filter(lambda x: x < 0, items)
product = reduce((lambda x, y: x * y), items)

They are clear and readable. What are the C++0x equivalents? (I'm really asking)

Excellent doesn't mean anything if it isn't accessible. Qt should invest for the benefit of its users because the C++ std methods are obtuse. If you have Qt class, you already know and have a lot lot of control about how the container works.
Dmitriy Purgin
2018-11-22 09:03:49 UTC
Permalink
On Thu, Nov 1, 2018 at 3:44 PM Giuseppe D'Angelo via Interest <
And every time you use C++ you have the Standard Library with you, which
(crossing fingers) will have ranges in C++2a; why should Qt spend any
time at all implementing something like that?
I can't agree with this argument. I can't see why we can't have a Qt-way of
processing containers/ranges in a more "functional" way because the
standard will _maybe_ have it in future.

As you say yourself, we may or we may not have the ranges in C++2a. If we
are lucky and we do, it will be 2020 at earliest that the standard is
published, and another year or two until all the major compilers keep up
and stop consider the C++2a features "experimental", which is, by the way,
still the case for gcc and C++17 [1]. So we're looking at 2-4 years from
now at best until all these features are "stable" and we can safely use
them without risk of having to accidentally debug the standard library or a
compiler bug for days.

The ranges-v3 library is fine and usable, but by using it in a customer
project one has to consider additional dependencies, licenses, portability,
maintainability, correctness of the library and its long-term support. The
authors state themselves that the library is experimental and subject to
change. One of the reasons Qt is so successful is that "it has it all",
it's well documented, it generally can be seen as a single dependency, and
you generally expect good quality and portability between supported
platforms. If I'd see an implementation of ranges-like algorithms in the Qt
framework I wouldn't hesitate to use it because I expect it to be at least
Qt-grade quality. Of course, as you said earlier, I could implement it
myself and propose it to the Qt Framework, but that's not the issue I
wanted to addess.

[1] https://gcc.gnu.org/projects/cxx-status.html

Cheers & regards
Dmitriy Purgin
Jean-Michaël Celerier
2018-11-22 09:52:56 UTC
Permalink
Post by Dmitriy Purgin
The ranges-v3 library is fine and usable, but by using it in a
customer project one has to consider additional dependencies,
licenses, portability, maintainability, correctness of the library and
its long-term support. The authors state themselves that the library
is experimental and subject to change. One of the reasons Qt is so
successful is that "it has it all", it's well documented, it generally
can be seen as a single dependency, and you generally expect good
quality and portability between supported platforms.
As much as I like Qt, I would trust the code quality of ranges-v3 much
more than Qt's. Never had "project-threathening" bugs with ranges-v3,
unlike Qt.

Roland Hughes
2018-11-03 23:07:09 UTC
Permalink
Giuseppe,

I missed the beginning of this thread and don't have enough time for one
of my usual missives. I did want to take issue with the comment about
using C++ latest.

It's _never_ a good idea to chase a standard.

Please allow a few words of caution from a grizzled old code warrior.

I started programming before we had PCs or a C compiler for them. If you
want a loose interpretation of the time which shortly followed rent
"Halt and Catch Fire" https://www.imdb.com/title/tt2543312/ and follow
it up with "Pirates of Silicon Valley" https://www.imdb.com/title/tt0168122/

Back there and back then we had to chase the standard. The C language
itself didn't provide enough functionality to develop the applications
users wanted and we were mixing memory models trying to make them fit
under the infamous 640K barrier. By the time C++ compilers were
commercially available most compilers were so far afield from any
"standard" that you couldn't write something in Borland C++ with any
hope of it compiling under Microsoft or Watcom and yes, you could switch
the order with the statement still being true.

I used to skim the edge, but I had to because we were writing programs
for IBM "compatible as long as you didn't try to run Flight Simulator"
machines. I even subscribed to Rex Jaeschke's standards tracking blue
magazine back in the day. While I wouldn't say we were friends, we did
exchange emails before we had an Internet and email standard. We did
also exchange emails earlier this year. You can look him up here 
http://rexjaeschke.com/  but might be best to dig through old Dr. Dobbs
issues. The dude really worked hard and wrote well. We all worked hard
back then.

Standards bodies have a tendency to jump the shark a bit too often for
my comfort. I came to this realization with the introduction of trigraphs.

https://en.wikipedia.org/wiki/Digraphs_and_trigraphs

P.J. Pluager (we DON'T exchange emails) was hailing their salvation of
mankind in "The C/C++ Users Journal" while many of us grunt coders in
the field were decrying them even being thought about. This was the
result of a select few individuals trying to solve a language problem
with an addition to a programming language. They wanted to make the C
language family "the one" to replace all others. It was the wrong
solution before the idea was even hatched. IBM and a select few others
could not wait for the correct solution, so they slammed through an
ill-formed solution and went merrily on making money. (To this day I
don't know of a single widely available programming editor which will
show you the translation of a trigraph or digraph on your screen.
Somewhere one or two might exist, but they certainly didn't exist when
this egg was laid.)

What was the correct solution you ask? UTF

There were other attempts to be sure. Various language sets which could
be loaded on demand, but, the programmers who coded close to the metal
needed to step back. We were well past the days of being able to rely on
the characters contained in either a BIOS/firmware code page or the one
loaded by DOS. (Windows was nothing but DOS all the way until NT.)

Being long in the tooth and somewhat greying of hair and having spent
roughly 3 decades as a hired gun in the software programming world, I
will share with you a bit of advice which will find deaf ears which will
fall on the deaf ears of the young guns who stay up nights reading
communications of the standards body.

The person hired to maintain your code will have one overriding
qualification. They will be "priced right." As a software mercenary, if
you write code which skims the edge of the current standard, word will
get around and you will find yourself stocking shelves at Walmart.

I've known quite a few consultants over the years who tried to make
themselves indispensable by writing code nobody else could maintain. One
used to write "hand tuned assembler" for portions of every system he
wrote and we are talking less than a decade ago. He wasn't writing PC
software, but working on a big midrange system and pretty much
everything he did in assembler could have been done in BASIC or COBOL on
the same platform. In fact that company has someone rewriting it all in
a high level language now. Yeah, he's not there anymore.

During my 3 decade career I've only encountered one client site which
did not prefer a full page of easy to read code to that one incredibly
ingenious line which could replace it all. That one place has a teem of
young guns who basically sleep with the standards documents who like to
write incredibly complex and impossible to debug templates for various
things. As of last year their product was still in trouble. It wasn't
even that complex of a product conceptually. There was certainly no
reason for the code to get that way. Oh yeah, I forgot about the macros
which use other macros that use other macros. When you compile a listing
the macro set on one line expands to, in some cases, an entire page or
more of code.

Long life Qt shops. Those building products which must be field
maintained for a decade or more like medical devices, cargo x-ray, etc.
Need a code base which can be maintained by their most junior developer.
They need a college intern to become functional within 2 days and able
to maintain the system within a month.

Young guns like skimming the edge of a standard to prove their chops.
They, however, create systems which either never see the light of day or
only survive for a couple of years in the field.
As I said in the other thread, not using C++-latest costs
_you_ more. It shouldn't cost anything for Qt.
--
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
Uwe Rathmann
2018-11-05 14:13:01 UTC
Permalink
<hearsay> Didn't you hear from Microsoft? They went from being the
slowest adopter to the fastest -- to this date, MSVC 2017.7 is the
_only_ C++ compiler that supports the entirety of C++17! That indeed
shows their commitment! </hearsay>
Hm, it's only a couple of days ago that I had this one:
https://github.com/uwerat/qskinny/issues/65
#define QSK_STATES( ... ) static const QskAspect::State VA_ARGS;
from QskAspects.h.
When building as a shared library, the static member variables defined
by the macro on exported classes are not all exported, only the first
one. The bug has been known for over 17 (!) years and is present in all
modern MSVC compilers (see https://jeffpar.github.io/kbarchive/kb/127/
Q127900/)

So what are my options: waiting 17 more years or writing this totally
stupid workaround you find at the end of: https://github.com/uwerat/
qskinny/blob/master/src/common/QskAspect.h ?

My other project ( http://qwt.sourceforge.net/ ) supports all versions of
Qt >= 4.4 from the same code base - for tons of build and runtime
environments.

Of course I have to pay with limiting myself in what features of C++ or
Qt I'm using - but this is what needs to be done if you take the LTS idea
seriously.

Uwe
Continue reading on narkive:
Loading...