Hi, On 04/11/2018 00:07, Roland Hughes wrote:
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.
[citation needed], I'm afraid. Every single time I say that "not using C++-latest costs more", I do it bringing technical arguments to the table, usually quoting which exact new feature or idiom I'm talking about (and what would be the advantages in the context of the discussion). I don't spread gossip, and I don't embrace the new standards blindly.
I'm simply convinced that the adding things to Qt that are also already covered in an excellent way by other libraries (_especially_ if it's by the Standard Library) simply doesn't justify its work/benefit ratio. And this connects to the statement of mine you quoted: if C++2a ships ranges, you shouldn't be looking for them into Qt. You should be looking for a new compiler. Of course you're free to stick to your current compiler, which means not using ranges from the Standard Library, which may have a cost for your development.
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.
Luckily we're not in 1991 (?) any more, we can use more than 640K of memory, C++ is very portable, and all major vendors ship compiler updates quickly.
<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>
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
Sorry, but this does not make any sense at all. Trigraphs were added to C because not all encodings, operating systems, editors, or keyboards (notably, yes, IBM's, e.g. the 3270 series) had the full set of symbols to properly write C code. How does using a different encoding suddenly make such keyboards have new physical keys?
Not to mention that trigraphs were added to C before 1989, and the first release of Unicode came in 1991, with UTF-1 and UTF-8 coming then in 1992. Do you have a time machine?
Yes, people "blame" IBM for that. Yes, trigraphs have finally been dropped in C++17, although implementations are free to support them (source encoding mapping is still implementation-defined, after all).
And anyhow, are we discussing about _trigraphs_, which are purely a _backwards-compatibility feature_, in terms of "chasing the latest standard"?
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.
Or employed by one of the countless companies who _are_ chasing the Standard and making quite some money by building successful products. Please stop spreading hearsay!
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.
That is, rephrased, "you can write FORTRAN in any language". Using or not using the latest standards has nothing to do with this. You can write beautiful C++98 code and ugly and complicated C++17. This proves or disproves nothing.
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.
[citation needed] again. Please, bring facts to the table of using or not using some other language feature, not random stories.
Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
