On 5/28/2026 2:18 AM, Janis Papanagnou wrote:[...]On 2026-05-28 01:49, BGB wrote:
Wow! - That's completely different from my experience and practice.I'm a big fan of abstractions. - So many things beyond "C" are fine!I am not saying that abstractions are bad, but I haven't usually found them to be worth the costs IME.
It's what makes usage simple, fast, reliable. Not wasting time for
details, or fixing technical bugs that should be prevented by the
language.
Okay, "when used in a in a naive way". - Let's leave it at that,Both have a similar issue when used in a naive way though:[...]>
>
Similar reason to why one doesn't build complex patterns or do template- like stuff via function macros in the C preprocessor:
One can do this... But again, bloated binaries and terrible build times.
Code patterns that are bulky in "C" can be formulated tersely with
C++/STL (while still preserving an efficient implementation, even with
complexities guaranteed); and the framework is flexible, orthogonally
designed. Easy to reuse high-level concepts as opposed to re-implement
the same code for different types. Or weaken the code by extensive use
of casts. All sorts of C's problems with memory can be addressed. (The
list can be continued; but I wonder why such things aren't recognized.)
Non-careful use of either results in code bloat.
then.
But, not really an "easy" way to avoid bloat, other than to write code specifically for what cases are relevant; while also avoiding needless duplication and copy paste (where, overuse of copy/paste can also lead to bloat; along with turning the code into an ugly mess).Hmm.. - as said, the during very early days there were issues; I
recall on one platform duplication of template code in more that
one source unit. And/or some environmental hacks (of the compiler)
to deposit template code for linking. In the later days I've not
seen such immature things anymore.
But, OTOH, factoring things into too small of pieces can negatively effect performance (and, for non-leaf functions, prolog/epilog costs for too many tiny functions can also be a source of code bloat).We obviously disagree completely in what's "syntactic sugar".
As can be noted, trying to mimic templates via creative use of C preprocessor macros can also easily result in excessive bloat...
Well, for example:>>
So, one is back to the core issue:
The part that is actually usable, mostly still amounts to syntactic sugar over things you can already do in C.
Huh? It may depend on the developer/programmer. But it's certainly a
lot more than "syntactic sugar".
Operator overloading:
Basically glorified function calls made to resemble operators;
Classes:
Can be done with structs, and implementing vtables manually.
Implementing class hierarchies via structs can be done, but gets ugly (GTK's GObject system sorta went this way).
(With that reasoning all ("C" or other languages') features are
"syntactic sugar" because you can do that also with assembly?)
A simple, less-abstracted language can certainly be easier (thusWell, it is a thing that can be done, but is a double-edged sword.>>
There are "niceties", granted, but relatively little "actually new".
Not all concepts are "new", of course; we saw them in other languages
years or (in some cases) decades ago. But C++' and STL features are a
lot more than just niceties; it's beyond me how one may come to such
a valuation. (And now let's compare that formulated demand or wish of
new things with "C"?)
Saves code one might have to write out manually.
But, is very easy to result in things that negatively effect build times.
faster) translated to machine code.
I don't know about your working contexts. In our contexts slightly
larger built-times were no issue. For one, we built using makefiles,
and only full builds (to create QA test images, or public releases)
required much time; they typically ran over night; our systems were
typically very large!
Build times were also influenced by other more significant factors.
Mundane sounding things like ordering of functions in libraries and
some such. (Though nothing that wouldn't have been possible to be
addressed by the build-management group.)
Usual strategy is to try to limit how much code is written, and also to avoid doing things in ways that result in too much code, or too much cruft.We avoided macros if possible.
Best to avoid both copy paste when reasonable, and sticking anything non-trivial in macros.
Okay.Here, "new" in the sense that it can't be mapped directly back to stuff that can already be expressed natively in C.And, one of the rare few "actually new" features C++ offers: exceptions.>
We used them already in the 1990's.
Aha; I thought that this would have been the source of criticism.The relative impact of try/catch is more modest.Also comes with its own drawbacks (code bloat, try/catch+throw is usually slow, use with care else program explodes, ...). [...]>
I cannot confirm your statements, especially in that generality.
>
I recall we had bloat with templates on a specific platform in the
very early pre-standard era, when they were first supported. But we
didn't have any [noteworthy] speed degradation with exceptions (or
templates).
Typically, it results in every function having an unwind-handling stub for, in-case an exception is thrown, it can call any destructors or similar.I've seen and heard of may ways in which exceptions have been used,
ranging from a single "catch all" in the main() function, to each
function instrumented. I will not judge about these extreme cases.
All I say is that you, as a software designer, have the options to
sensibly structure and instrument your code with exceptions.
There's also the characteristic that you may define exception types
(or use just existing ones); build or add to a hierarchy to handle
them flexibly, provide context data with the exception objects, etc.
Handling all that manually and explicitly, without the support of an
exception concept I'd certainly not prefer.
Janis
[...]
Les messages affichés proviennent d'usenet.