On 2026-05-28 01:49, BGB wrote:I am not saying that abstractions are bad, but I haven't usually found them to be worth the costs IME.I'm a big fan of abstractions. - So many things beyond "C" are fine![...]>
In general I like her videos, and she seems to know what she is talking about...
>
But, I am not personally as much of a fan of C++ as she is...
Yeah.[...]A sensible but imperfect workaround provided for an inferior platform.
>
[ Cygwin ]
It was the main thing I had when I was in high-school.
Well, Cygwin and MinGW.
By college, the "Windows Platform SDK" became freely available, and I mostly ended up jumping over this for native Windows development.
At least the C++ compiler worked, still failed to fully win me over.
Tried writing minor things in C++, mixed results.
Both have a similar issue when used in a naive way though:[...]Code patterns that are bulky in "C" can be formulated tersely with
>
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.
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.
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).
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).
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:>Huh? It may depend on the developer/programmer. But it's certainly a
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.
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).
...
Well, it is a thing that can be done, but is a double-edged sword.>Not all concepts are "new", of course; we saw them in other languages
There are "niceties", granted, but relatively little "actually new".
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.
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.
Best to avoid both copy paste when reasonable, and sticking anything non-trivial in macros.
Here, "new" in the sense that it can't be mapped directly back to stuff that can already be expressed natively in C.>We used them already in the 1990's.
And, one of the rare few "actually new" features C++ offers: exceptions.
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.
This will depend a lot of the target and ABI, but for example, in my compiler, having exceptions enabled ends up costing around an extra 48 bytes for every non-leaf function.
This can easily add up to a fair number of kB over the size of a program binary even if they aren't used.
The per-function cost would be higher for functions which have objects with destructors or catch handlers. One could easily be looking at 100s of additional bytes for each such function.
On Cygwin, in the early 2000s, "g++" tended to often not work at all...>Yes, stupid things are done. Mandating to use RCs and forbid to use
Many people coding styles often forbid it and mandate that people use error-code returns or similar instead (like in C), with exceptions being globally disabled at build time (along with RTTI and similar), which, isn't really a strong selling point...
exceptions is particularly stupid as a general rule.
Probably mentally inconvenient as "new" concept for FORTRAN, BASIC,
or "C" programmers? I can certainly understand that, psychologically.
But not technically. Maybe the support on the commercial platforms
was just better than on Cygwin?
MSVC gave a better experience in that at least the compiler worked.
Now, as for the rules like this in many coding standards, can't speak for all of them.
But, the main thing that stands out to me is how many of the projects that use C++ have absurdly slow build times and huge binaries.
Like, someone is like, "Thing takes 10 minutes to compile and the EXE is 50MB? Seems fine to me..."
Well, or LLVM, which can take upwards of an hour to rebuild from source, and eats huge amounts of RAM and HDD space while doing so.
So, yeah, I don't really use LLVM...
My own C compiler rebuilds from source in around 20 seconds or so.
Well, or 1m38s via GCC...
But, yeah however long is considered a reasonable amount of time to recompile a 370 kLOC C compiler...
MSVC produces an 5.5MB EXE, whereas GCC produces a 12MB ELF.
If I switch "-O3" to "-Os":
Time drops to 0m58s.
ELF goes to 7MB.
Still pretty big...
Granted, my C compiler's codebase is a little bigger than I would prefer, but alas...
Granted, my C compiler isn't itself all that fast at compiling stuff, sadly:
It also takes around 20 seconds to recompile Doom (vs around 5 seconds for MSVC).
And, GCC takes around 16 seconds to recompile Doom.
So, yeah, as for its compiling-stuff speeds, it is typically slower than GCC.
Doom sizes:
MSVC : 776K (x64)
GCC : 500K (x86-64)
GCC : 1.2MB (RV64G, ELF)
BGBCC : 272K (XG3, *)
*: Custom ISA stuff bolted onto RISC-V (with 32/64/96 bit instructions, goes to bigger instructions rather than smaller, and expands register fields to 6-bits using both X and F registers as GPRs, so is the opposite of RV-C in this sense; but manages to compete for code density by reducing overall instruction counts).
For binary sizes, it is pretty close between XG3 and a differently-extended version of RV64GC though. Not yet a clear winner of the code-density crown, but it does more solidly win on speed.
Where, XG3 was more meant for optimizing the design for speed, but to some extent optimizing the design for speed also helps with code density.
Though, for RV64G, GCC seems to produce a lot of bloat in the ELF binaries through the use of excessive amounts of metadata, which is already fairly bulky in the ELF format if contrast with PE/COFF (which is what my compiler generates).
...
Les messages affichés proviennent d'usenet.