Malcolm: Usability improvements in GCC 9 [LWN.net]

Malcolm: Usability improvements in GCC 9

Posted Mar 8, 2019 21:24 UTC (Fri) by HelloWorld (guest, #56129) [Link]

If C is the solution, then I'd like my problem back.

Malcolm: Usability improvements in GCC 9

Posted Mar 10, 2019 5:02 UTC (Sun) by dvdeug (guest, #10998) [Link] (11 responses)

"Greenspun’s Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp." At the very least, give me a decent set of containers and string library in any language I have to use.

Malcolm: Usability improvements in GCC 9

Posted Mar 11, 2019 4:29 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (10 responses)

Doesn't that argument also apply to C++, except that it's always the same ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp?

Malcolm: Usability improvements in GCC 9

Posted Mar 11, 2019 5:10 UTC (Mon) by dvdeug (guest, #10998) [Link] (8 responses)

I won't say that C++ is a panacea; I prefer Scala, personally. But the C++ standard library is not ad hoc or informally-specified; it's an international standard just like Common Lisp. I'd be surprised if the G++ and Microsoft C++ libraries didn't compare quite well to the major Common Lisp systems on speed and bugginess. There probably are features of Common Lisp that C++ users are forced to reimplement, but it's at least better than C on that front.

Malcolm: Usability improvements in GCC 9

Posted Mar 11, 2019 8:15 UTC (Mon) by tdz (subscriber, #58733) [Link] (7 responses)

While C++'s STL much better than the data structures in C standards, it can lead to excessive object copying. I think C's strong domain is where overhead really matters, so STL might not be appropriate in these environments.

OTOH, I'd wish the ISO C committee would simply standardize the stuff in <sys/queue.h>. This should do the job in nearly all cases. POSIX provides insque() and remque(), which are so laughable that one wonders why they bothered standardizing it at all.

Malcolm: Usability improvements in GCC 9

Posted Mar 11, 2019 8:19 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> While C++'s STL much better than the data structures in C standards, it can lead to excessive object copying.
This might have been true in C++03 (although even there NRVO and RVO optimized away a lot of copies) but C++11 and more recent versions have much more robust move semantics.

Malcolm: Usability improvements in GCC 9

Posted Mar 11, 2019 8:30 UTC (Mon) by tdz (subscriber, #58733) [Link] (3 responses)

True. But move semantics are in some way a workaround for the excessive-copying problem of these earlier versions. And (sane use of) STL also requires C++ exceptions, which are often not available in resource-limited environments.

Malcolm: Usability improvements in GCC 9

Posted Mar 11, 2019 9:11 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

There are STLs that work just fine without exceptions, you actually don't need them for most of the library if you just ignore the epic failure that are the iostreams.

Also, SJLJ exceptions are actually quite reasonable even for small environments (something a bit larger than 16 bit Arduino).

And then there's this nice proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p... - it won't make into the coming revision of the standard, but it's on the table for the next one.

Malcolm: Usability improvements in GCC 9

Posted Mar 11, 2019 11:42 UTC (Mon) by tdz (subscriber, #58733) [Link] (1 responses)

> There are STLs that work just fine without exceptions

There are, but C++ without exceptions is not what I call "sane use of."

Malcolm: Usability improvements in GCC 9

Posted Mar 12, 2019 17:10 UTC (Tue) by k8to (guest, #15413) [Link]

Imo, C++ without exceeptions works for certain use cases, like embedded codebases. But STL without exceptions sounds very bad.

Malcolm: Usability improvements in GCC 9

Posted Mar 11, 2019 18:08 UTC (Mon) by rweikusat2 (subscriber, #117920) [Link] (1 responses)

> While C++'s STL much better than the data structures in C standards,

There are no "data structures" in C standards, there's just a convention for representing strings.

Malcolm: Usability improvements in GCC 9

Posted Mar 12, 2019 9:21 UTC (Tue) by tdz (subscriber, #58733) [Link]

Because it's not a data structure unless it's wrapped in 'struct { }'

Malcolm: Usability improvements in GCC 9

Posted Mar 11, 2019 19:45 UTC (Mon) by xtifr (guest, #143) [Link]

> Doesn't that argument also apply to C++, except that it's always the same ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp?

It's a much *larger* ad-hoc informally specified bug-ridden slow implementation of half of Common Lisp. :) C++11, in particular, adds lambdas to the language, for extra bonus lispiness. :)

(I was actually about ready to give up on C++ until C++11, which returned to the list of languages I don't mind *too* terribly.)

Malcolm: Usability improvements in GCC 9

Posted Mar 12, 2019 23:44 UTC (Tue) by simlo (guest, #10866) [Link]

*laugh*
I am software architect on a product containing Java, C, C++ and a few scripting things around as well. The code with fewest bugs is the C++ - even though we make far the most complicated algorithms in C++.

Some of the previous (lead) developers bought that code close to the hardware has to be C. That code is terrible and impossible to unit test. We recently had to spend a lot of hours patching for a simple memory leak, which simply wouldn't have happened with modern C++ code style (smart pointers).

The Java code is a lot better than the C, but there are way too many treads.

I agree with one huge problem in C++, though: It doesn't scale to large project, since each project around choose their own subset of the language and conventions. When you try merge the projects in one binary it falls apart. Java is much better in that sense.