https://www.youtube.com/watch?v=I7fEsbksKRE

as far as i understood..(becouse if someona talks english fast my mind
tend to skip more than half of the message)

overally this is quite curious...


she probably read this articles etc for lisp ponys who say lisp is
beautifull and c is not so much... but still this is much of
incompetence call c ugly...


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

fir pisze:

https://www.youtube.com/watch?v=I7fEsbksKRE

as far as i understood..(becouse if someona talks english fast my mind
tend to skip more than half of the message)

overally this is quite curious...

she probably read this articles etc for lisp ponys who say lisp is beautifull and c is not so much... but still this is much of
incompetence call c ugly...

well i see she named bjorne stroustrup smart (well i wouldnt be so bold
here) - and said he took UGLY c and combined it with OO so this make a
c++ 'succesfull' language which
takes much hate

so i understand c is ugly and to blame c++ is hated... instead of coding
in lisp... now thats where comedy possibly gets too strong :3

(now im quite convinced my comment on this is also not too strong in bad
way of its sense but i was kinda really stunned/surprised ehen someona
talks such things on video ) -,-

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/27/2026 1:15 PM, fir wrote:

fir pisze:

https://www.youtube.com/watch?v=I7fEsbksKRE

as far as i understood..(becouse if someona talks english fast my mind
tend to skip more than half of the message)

overally this is quite curious...


she probably read this articles etc for lisp ponys who say lisp is
beautifull and c is not so much... but still this is much of
incompetence call c ugly...

well i see she named bjorne stroustrup smart (well i wouldnt be so bold here)ÿ - and said he took UGLY c and combined it with OO so this make a
c++ 'succesfull'ÿ language which
takes much hate

so i understand c is ugly and to blame c++ is hated... instead of coding
in lisp... now thats where comedy possibly gets too strong :3

(now im quite convinced my comment on this is also not too strong in bad
way of its sense but i was kinda really stunned/surprised ehen someona
talks such things on video ) -,-

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...


Like, say:
Early days (once when I was still young):
Main compiler I used was Cygwin, but "g++" tended not to work.
Like, at the time, had the ever-present GCC 2.95.2, ...
Any attempt to compile C++ resulted in a mess of error messages.
Later:
I experimented with it, but:
It didn't do that much that wasn't syntactic sugar over C.
I was using customized tools that worked OK with C,
but C++ made many headaches with inter-op with custom tools.
If you have C++, but can't really use any features without issues,
it kinda defeats the point vs just using C.
Later still:
My custom compiler can't use more than a 90s era subset;
So, to really make use of any newer/fancier features,
I would greatly limit where I could use the code.

People can be like:
"But, Templates, and STL containers..."
And I can be like:
"But then your binaries are huge and build times suck..."


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.


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.


There are "niceties", granted, but relatively little "actually new".


And, one of the rare few "actually new" features C++ offers: exceptions.
Also comes with its own drawbacks (code bloat, try/catch+throw is
usually slow, use with care else program explodes, ...). Unlike many
other features, C++ exceptions are also ones that add a (small but often non-zero) code-bloat and performance penalty to pretty much *every*
function, regardless of whether or not they actually use exceptions
(because, they could potentially call something, somewhere, that uses exceptions, and so the compiler needs to provide for the possibility
that an exception could come through this section of code).

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...


And, many examples we have of non-trivial projects using C++, such as LLVM/Clang, also tend to own pretty much any computer that one dares use
to try to compile it...

Or, Doom3, which isn't *that* much bigger than Quake 3 code wise, and
still uses a mostly C like subset of C++, but for whatever unexplained
reason, seems to take an order of magnitude longer to recompile from
source (... over 10 minutes ...).

...



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 27 May 2026 18:49:38 -0500, BGB wrote:

But, I am not personally as much of a fan of C++ as she is...

C++ syntax is so complex, the language spec has to add rules that say,
in case of ambiguity, that this interpretation is meant and not that.

Someone described this as ?the principle of most surprise?.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-28 01:49, BGB wrote:

[...]

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...

I'm a big fan of abstractions. - So many things beyond "C" are fine!

[...]

[ Cygwin ]

A sensible but imperfect workaround provided for an inferior platform.

[...]

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.)

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".

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"?)

And, one of the rare few "actually new" features C++ offers: exceptions.

We used them already in the 1990's.

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).

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...

Yes, stupid things are done. Mandating to use RCs and forbid to use
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?

Janis

[...]

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/27/2026 11:53 PM, Lawrence D?Oliveiro wrote:

On Wed, 27 May 2026 18:49:38 -0500, BGB wrote:

But, I am not personally as much of a fan of C++ as she is...

C++ syntax is so complex, the language spec has to add rules that say,
in case of ambiguity, that this interpretation is meant and not that.

Someone described this as ?the principle of most surprise?.

Someone could almost come up with a language that is "like C++ but less horrible".


Core language:
Like a C / C# hybrid;
Base language could superficially resemble C++;
In any case, avoid needlessly changing basic syntax.
Designed to be easier to write a compiler;
Designed so that compiler isn't dead slow;
Goal should be that compiled code performance remain similar to C;
Shouldn't do things that would exclude it from C like use cases.
Type-system and memory model is mostly similar to C.

Could impose that declaration types work more like in C#;
SI + Interfaces rather than full MI;
Generic Types rather than Templates;
...

Parsing would follow a "can it reasonably be parsed as X" approach:
If something can syntactically be parsed as a cast/etc, assume it is so;
If this assumption turns out to be wrong, compiler error.

In this case, assume that types/etc may only appear in certain contexts,
and can apply on "<type_expr> <identifier>" pattern recognition to
detect declarations. Trying to put a declaration (or generic invocation) somewhere where it doesn't normally go, being a syntax error.

Say:
if(int i=0)
{ ... }
Would be regarded as illegal (but could be allowed as a special case in "for()" loops due to popularity).


Core type-system is C like:
Type consists of a base-type and any modifiers;
Base type names:
char, byte, short, int, long, float, double, ...
Type Modifiers:
signed, unsigned, const, volatile, ...
Where, const and volatile behave like in C.
Base type sizes (bits):
char 8 //ASCII / UTF-8
wchar 16 //UCS-2 / UTF-16
lchar 32 //UCS-4 / UTF-32
byte 8
sbyte 8
ubyte 8
short 16
int 32
long 64
float 32
double 64

Issue:
Would want to disallow compound type names, like "long long" or "long
double".
As soon as the syntax allows this, an ambiguity is created that
adversely effects parser speed.

One other option could be to provide a set of explicit sized types:
int8, int16, int32, int64, int128
uint8, uint16, uint32, uint64, uint128
float16, float32, float64, float128
...


In terms of representation, byte and char would be equivalent, except
that it might make sense to treat 'char' as not normally an arithmetic
type, so in order to perform arithmetic on char it would be cast to
'int' or similar.

Could assume that a "string" type exists, but primarily exists as an
opaque "const char *" pointer.

Nominally, string literals could be stored prefixed with a length stored
as a transposed UTF-8 codepoint (along with also having a NUL
terminator). But, unlike "const char *", "string" would not allow
pointer arithmetic, and so would always point to the start of the string literal, or to an explicitly interned string (doing otherwise would be erroneous).


While it is "trendy" in some languages to treat "string" as some sort of object type, actually doing string as an object is needlessly wasteful.

Likewise, storing a length as a prefix still allows "string.length" or
similar to be O(1). Could assume default string format is UTF-8, but
mostly treated as a blob of bytes.

While some languages (Java and C#) went over to UTF-16, this is
needlessly wasteful of memory and breaks with C tradition.



Likely memory management:
Generic heap, new/delete;
No GC, as IMO no one thus far has made GC work sufficiently well.
Zones / arenas;
Initially resembles heap allocs,
but all objects in a zone can be bulk freed;
Some objects could be set to track their self-pointer;
Self-pointer is NULL'ed if object is freed.
Essentially, similar to Doom's Z_Malloc.
Automatic:
Freed by default as soon as parent frame exits.

OO:
Likely treat 'class' and 'struct' as distinct.
Objects are reference type by default (like in C#/Java);
However, will typically still have automatic lifetime if local.
Could likely still have RAII, but may manifest differently.
Structs would behave like C structs or C++ by_value classes.
Will explicitly forbid inheritance or virtual methods.
Could maybe have copy-constructors and destructors.
More likely to be used for C++ style RAII patterns.

The more restrictive object model would avoid a "big chunk of evil" that exists if trying to write a C++ compiler. Elimination of full MI
eliminates a lot of complexity; as does eliminating inheritance on
by-value types.


Declaration imports:
Would likely make sense to replace the reliance on "#include" with
something more resembling the "import" mechanism from Java;
Though would differ in that the imports identify source files rather
than classes;

Would likely treat package/import scope, name namespace scope, as two different entities. The package/import would resemble the mechanism in
Java, but would instead merely import things at toplevel scope, and
within an imported module.

Namespace would be used in a way more like that of C++ or C# namespaces:
namespace whatever { using whatever_else; ... }


It is likely that compiler would first generate a "declaration manifest"
which would be used for these purposes.

Compiling Foo:
import bar;
Checks if bar has a manifest;
If yes:
Import manifest for bar;
Add 'bar' to object dependency graph;
Also import any of bar's dependencies.
If no:
Trigger frontend only compilation for 'bar';
If success:
Import manifest for bar;
Add 'bar' to object dependency graph;
Else:
Compiler error.

Compiler would likely deal with dependency compilation as a sort of
stack machine, where imports are dealt with before compiling the main
body of each module. This being to avoid excessive recursion and memory
usage during dependency importing.

Would likely make sense to keep a C style preprocessor, but using it for headers could be discouraged (this being a great source of compile-time inefficiency in both C and C++).

...


Well, wont amount to much, just idle thoughts...




--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Am 28.05.2026 um 06:53 schrieb Lawrence D?Oliveiro:

C++ syntax is so complex, the language spec has to add rules that say,
in case of ambiguity, that this interpretation is meant and not that.

There only a few amiguities, mainly the most vexing parse.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

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...

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.

[...]

[ Cygwin ]

A sensible but imperfect workaround provided for an inferior platform.

Yeah.

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.

[...]

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.)

Both have a similar issue when used in a naive way though:
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...

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".

Well, for example:
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).

...

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"?)

Well, it is a thing that can be done, but is a double-edged sword.
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.

And, one of the rare few "actually new" features C++ offers: exceptions.

We used them already in the 1990's.

Here, "new" in the sense that it can't be mapped directly back to stuff
that can already be expressed natively in C.

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).

The relative impact of try/catch is more modest.

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.

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...

Yes, stupid things are done. Mandating to use RCs and forbid to use 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?

On Cygwin, in the early 2000s, "g++" tended to often not work at all...
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).


...



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

BGB pisze:

On 5/27/2026 1:15 PM, fir wrote:

fir pisze:

https://www.youtube.com/watch?v=I7fEsbksKRE

as far as i understood..(becouse if someona talks english fast my
mind tend to skip more than half of the message)

overally this is quite curious...


she probably read this articles etc for lisp ponys who say lisp is
beautifull and c is not so much... but still this is much of
incompetence call c ugly...

well i see she named bjorne stroustrup smart (well i wouldnt be so
bold here)ÿ - and said he took UGLY c and combined it with OO so this
make a c++ 'succesfull'ÿ language which
takes much hate

so i understand c is ugly and to blame c++ is hated... instead of
coding in lisp... now thats where comedy possibly gets too strong :3

(now im quite convinced my comment on this is also not too strong in
bad way of its sense but i was kinda really stunned/surprised ehen
someona talks such things on video ) -,-

In general I like her videos, and she seems to know what she is talking about...

good to watch for sure, but those statements are still preposterous

for me its kinda funny becouse i didnt think people who say c is ugly
are real

though my opinion on c++ from -10/10 or about rised recently maybe to
-9/10 becouse of this so called 'references' who after thinking shoved
to have some sense (thou in c++ they probably dont even know it have
sense thay just add sh*t (and by chance 1 on 100 has some sense)

But, I am not personally as much of a fan of C++ as she is...

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/28/2026 10:12 AM, fir wrote:

BGB pisze:

On 5/27/2026 1:15 PM, fir wrote:

fir pisze:

https://www.youtube.com/watch?v=I7fEsbksKRE

as far as i understood..(becouse if someona talks english fast my
mind tend to skip more than half of the message)

overally this is quite curious...


she probably read this articles etc for lisp ponys who say lisp is
beautifull and c is not so much... but still this is much of
incompetence call c ugly...

well i see she named bjorne stroustrup smart (well i wouldnt be so
bold here)ÿ - and said he took UGLY c and combined it with OO so this
make a c++ 'succesfull'ÿ language which
takes much hate

so i understand c is ugly and to blame c++ is hated... instead of
coding in lisp... now thats where comedy possibly gets too strong :3

(now im quite convinced my comment on this is also not too strong in
bad way of its sense but i was kinda really stunned/surprised ehen
someona talks such things on video ) -,-

In general I like her videos, and she seems to know what she is
talking about...

good to watch for sure, but those statements are still preposterous

for me its kinda funny becouse i didnt think people who say c is ugly
are real

though my opinion on c++ from -10/10 or about rised recently maybe to
-9/10 becouse of this so called 'references' who after thinking shoved
to have some sense (thou in c++ they probably dont even know it have
sense thay just add sh*t (and by chance 1 on 100 has some sense)

I can't answer for her, but there are differences in aesthetic preferences.


Some like LISP syntax, others can't stand the excessive parenthesis.
There have been attempts to eliminate parenthesis, but then you can end
up with an indentation sensitive syntax (like Python):
defun foo (x y)
if ( > x y )
- ( * 2 x ) y
- ( * 2 y ) x

But, then you have all the hassles of white-space sensitive syntax...

Infix notation and precedence rules are pros/cons.

Many people much preferred Pascal style.

Smalltalk was once popular, and while arguably some aspects of its
syntax are "aesthetic", I personally found trying to read anything in
the language to be almost incomprehensible (so, negative points if I
can't make any sense of what is going on).

Trying to awkwardly bolt Smalltalk syntax onto C (as in Objective-C)
being horribly ugly IMO.


Early on, I had liked JS and ActionScript, as (compared with LISP and
Scheme) they scaled a lot easier to "real programming work".

But, then one faces a tension:
Light duty scripting: Favors keeping the language dynamic and minimizing structural concerns;
Implementation work: Favors strongly going in a direction more like the
C-like languages.

So, my first major language ended up going from being a small JS clone
to something more like ActionScript3 (with a large and complex VM).

Then I rebooted it into something more Java-like (a language I called
BS2), but then:
It was no longer good at light scripting tasks;
It failed to really compete well with C in C's home turf.


BGBCC has BS2 support, but I rarely use-it, as it was often more useful
to write in C and then invoke BS2 features as C extensions when relevant.

Well, even if the syntax is ugly, and people can question why BS2
features and not C++ features.


Both C++ and BS2 had exceptions, but in both cases, enabling them has
non-zero overhead.

This mostly takes the form of:
Metadata tables to map code-locations to unwind and exception-handler
entry points;
Additional stub handlers to be generated in the code mostly to be like
"all good here, continue on your way."
Though, maybe could add a flag or something to the EH-unwind metadata to
flag that no handlers are present, so it should just skip past that step
and continue on directly. In this case, the idea is that it borrows a
trick from the Windows X64 ABI of using the function epilog to encode information for the exception unwind via machine instructions (the EH
unwinder would effectively implement a sort of very naive machine-code interpreter).

So, the metadata here is mostly a table of packed members to encode the
start and end RVA (within .text), where to find the epilog, and where to
find the entry-point for the unwind/catch handlers. I forget the exact
layout ATM, but do remember it originally came from the PE/COFF spec.



Did experiment with using the BS2 features in BGBCC to support an EC++
like subset, but this fell well short of being able to claim actual C++ support.

Or, Like EC++ but with interfaces and namespaces.

Didn't add the actual interface keyword though, more like:
abstract class IFoo {
public:
void method1();
void method2(int x, int y);
};
And, it understands it as an interface.

Did experiment with adding support for templates, but this is mostly
where I gave up.

Even getting to C++98 levels would be a strong uphill battle.

And, then I lose incentive as I don't really use C++, and (unlike C
land) the C++ people tend to chase after the newest features, rather
than stick to an older and more conservative subset.


But, yeah, some priorities I would have for such a language (as another attempt at a C++ alternative):
Scope remains within what is reasonable for a person to implement in a
custom compiler;
Language should ideally be able to compete head on with C in C-like
use-cases (say, for example, including bare-metal programming and ROMs); Language should ideally be able to have build times similar or better
than C for similar code complexity.

So, say, compiler should be ideally able to chew through at least 10
kLOC per second or so.

...


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/28/2026 12:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

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...

I'm a big fan of abstractions. - So many things beyond "C" are fine!

[...]

[ Cygwin ]

A sensible but imperfect workaround provided for an inferior platform.

[...]

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.)

C's problems with memory? Don't you mean the programmers that make bugs?

[...]

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 28 May 2026 02:35:37 -0500, BGB wrote:

Someone could almost come up with a language that is "like C++ but less horrible".

Like this? <https://en.wikipedia.org/wiki/Carbon_(programming_language)>

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 28 May 2026 04:57:18 -0500, BGB wrote:

It was the main thing I had when I was in high-school. Well, Cygwin
and MinGW.

Did you ever discover the platform that they were trying to emulate?

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 28 May 2026 14:07:45 -0500, BGB wrote:

Some like LISP syntax, others can't stand the excessive parenthesis.

Worth mentioning that the whole point about Lisp syntax is to get as
close to no syntax as possible -- essentially, all the ?syntax? is
down to the meaning of the first word after each opening parenthesis
(function call, macro call or ?special form?). This is to achieve homoiconicity, which is a core feature of the language.

Anybody remember PostScript? That, too, was homoiconic. And achieved
it in a similar way, with an absolutely minimalist compile-time
syntax.

Other, newer languages have found a way to implement AST-level macros
without going to that sort of extreme -- Julia and Rust, I think, can
manage it. I even did it in Python, with a little bit of fudging.

There have been attempts to eliminate parenthesis ...

The problem for me is the ?parenthesis pileup? layout that seems to be traditional among Lisp programmers. I prefer to put parentheses that
have the interpretation of delimiting statement blocks on lines by
themselves (and sometimes other constructs as well, if they get too
long), e.g.

(defun set_auto_indent (&optional on)
"lets user change auto-indent setting."
(interactive)
(when (eq on nil)
(setq on
(y-or-n-p
(format
"Auto-indent [%s]? "
(if
(eq
(lookup-key (current-global-map) "\015")
'auto_indent
)
"y"
"n"
) ; if
)
)
) ; setq
) ; when
(cond
(on
(global-set-key "\015" 'auto_indent)
(global-set-key [?\C-\M-m] 'newline)
(message "Auto-indent on")
)
(t
(global-set-key "\015" 'newline)
(global-set-key [?\C-\M-m] 'auto_indent)
(message "Auto-indent off")
)
) ; cond
) ; set_auto_indent

Infix notation and precedence rules are pros/cons.

Python took over most of the C operator precedence rules, with one
interesting wrinkle: they moved up the precedence of the bitwise
operators so that what has to be written like this in C:

(®val¯ & ®mask¯) == ®expected¯

can have the parentheses omitted in Python:

®val¯ & ®mask¯ == ®expected¯

Smalltalk was once popular, and while arguably some aspects of its
syntax are "aesthetic", I personally found trying to read anything
in the language to be almost incomprehensible (so, negative points
if I can't make any sense of what is going on).

I did have a look at it at one point. Not too hard to manage. The
hardest part was trying to find some actual explicit definition of the
whole syntax.

All in all, though, I think its approach to object-orientation is a
bit ancient, compared to, say, Python.

Early on, I had liked JS and ActionScript, as (compared with LISP
and Scheme) they scaled a lot easier to "real programming work".

But, then one faces a tension:
Light duty scripting: Favors keeping the language dynamic and
minimizing structural concerns;
Implementation work: Favors strongly going in a direction more like
the C-like languages.

Lua sounds like it was designed for what you had in mind.

But these days, it?s just easier to use Python.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/28/2026 6:32 PM, Lawrence D?Oliveiro wrote:

On Thu, 28 May 2026 02:35:37 -0500, BGB wrote:

Someone could almost come up with a language that is "like C++ but less
horrible".

Like this? <https://en.wikipedia.org/wiki/Carbon_(programming_language)>

Well, except that the language I am imagining would probably still look
more C-like (where, say, C-like core but borrowing some things from C#
and Java rather than aiming to to be like C++; but in terms of
implementation and ABI would be sorta like C++).


Possibly something like:
import C.stdio;

int main(int argc, const char **argv)
{
printf("hello world, called as %s\n", argv[0]);
return(0);
}

Where, say, new language inherits the C standard library, just using
import rather than #include .


Then, say, if we wanted a 2D vector type, say:
namespace foo {
struct Vector2D {
double x;
double y;
Vector2D(double ax, double ay)
{ x=ax; y=ay; }
}

Vector2D operator+(Vector2D a, Vector2D b)
{
return (Vector2D) { .x=a.x+b.x, .y=a.y+b.y };
}
double operator^(Vector2D a, Vector2D b)
{
return a.x*b.x + a*y+b.y;
}
}

Then, say:
using foo; //can skip 'namespace' keyword, as redundant here.

Vector2D test1()
{
Vector2D v0(1.0, 2.0);
Vector2D v1(3.0, 4.0);
Vector2D v2 = v0 + v1;
return v2;
}

Or, for a class type:
public class Foo {
double x, y;
Foo(double ax, double ay)
{ x=ax; y=ay; }
}
public interface IBaz {
//public and virtual by default
double get_x();
double get_y();
void set_x(double val);
void set_y(double val);
}
public class Bar:Foo,IBaz {
//public virtual via IBaz
double get_x() { return x; }
double get_y() { return y; }
void set_x(double val) { x=val; }
void set_y(double val) { y=val; }
}

...
{
IBaz obj1 = new Bar(1.0, 2.0);
}


And, if generics exist, say:
struct GenericVec2D<T> {
T x;
T y;
...
}

GenericVec2D<float> v2f0;
This instantiates a new type, say:
GenericVec2D$float
Where all instances of type 'T' become 'float'.


So, more in the vain of C mixed with C# and Java, not like some language
that diverges more drastically from C family conventions...

Where, like C# (and unlike C++), classes are always by-reference, and
structs always by value, and structs will forbid inheritance, ...


Could maybe also define that any functions declared at the global
top-level have C like binding, with name-mangling and overloading only applying within namespaces or within struct/class methods.



Note that SI+interfaces would effectively eliminate things like diamond inheritance and virtual inheritance (in effect, class layout will be append-only).

In-memory layout for classes could be sort of like:
vtable_pointer (shared across all classes)
data for parent class
interface vtable pointer(s) for parent class
-- end of parent class --
data for child class
interface vtable pointer(s) for child class
only for newly-implemented interfaces.
-- end of child class --


Each interface VTable could have a layout like, say:
Index 0: ClassInfo / RTTI
Index 1: Offset from Interface Vtable pointer to Base-Class.
Index 2: First Method
Index 3: Second Method
...

For base classes, it is nearly identical, except that offset is always 0.

...



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Am 28.05.2026 um 21:07 schrieb BGB:

Both C++ and BS2 had exceptions, but in both cases, enabling them has non-zero overhead.

Table-driven exception handling isn't very old but currently it applies
for every 64 bit platform; under Windows / x86 concatenated stackframes
are used. With table-driven EH the additional overhead is zero. And with
the older concatenated stackframes the overhad is very low.

And, then I lose incentive as I don't really use C++, and (unlike C
land) the C++ people tend to chase after the newest features, rather
than stick to an older and more conservative subset.

There's no language where the users are so detail focussed and open
to new features. But this new features raise the productivity a lot
and it was far beyond C even with C++98. With C you've to flip every
bit ourself over and over and C++ does replace that with standard
components.
This has been emphasized through a lot of C++-channels on YouTube;
I personally prefer the CppCon vids or the vids of Jason Turner.
And there are a lot of good books like these of Rainer Grimm and
Nicolai Josuttis.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-28 11:57, BGB wrote:

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

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.

Wow! - That's completely different from my experience and practice.

It's what makes usage simple, fast, reliable. Not wasting time for
details, or fixing technical bugs that should be prevented by the
language.

[...]

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.)

Both have a similar issue when used in a naive way though:
ÿ Non-careful use of either results in code bloat.

Okay, "when used in a in a naive way". - Let's leave it at that,
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).

As can be noted, trying to mimic templates via creative use of C preprocessor macros can also easily result in excessive bloat...

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".

Well, for example:
ÿ 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).

We obviously disagree completely in what's "syntactic sugar".

(With that reasoning all ("C" or other languages') features are
"syntactic sugar" because you can do that also with assembly?)

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"?)

Well, it is a thing that can be done, but is a double-edged sword.
Saves code one might have to write out manually.
But, is very easy to result in things that negatively effect build times.

A simple, less-abstracted language can certainly be easier (thus
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.

Best to avoid both copy paste when reasonable, and sticking anything non-trivial in macros.

We avoided macros if possible.

And, one of the rare few "actually new" features C++ offers: exceptions.

We used them already in the 1990's.

Here, "new" in the sense that it can't be mapped directly back to stuff
that can already be expressed natively in C.

Okay.

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).

The relative impact of try/catch is more modest.

Aha; I thought that this would have been the source of criticism.

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

[...]

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-28 21:47, Chris M. Thomasson wrote:

On 5/28/2026 12:18 AM, Janis Papanagnou wrote:

[...]

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.)

C's problems with memory? Don't you mean the programmers that make bugs?

I'm not sure you're serious here or just joking. - To clarify...

Yes, the programmers "implement the bugs", and the language makes it
just easy and obligingly support the programmers to make such bugs.

Janis


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 01:54, Lawrence D?Oliveiro wrote:

On Thu, 28 May 2026 14:07:45 -0500, BGB wrote:

Infix notation and precedence rules are pros/cons.

Python took over most of the C operator precedence rules, with one interesting wrinkle: they moved up the precedence of the bitwise
operators so that what has to be written like this in C:

(®val¯ & ®mask¯) == ®expected¯

can have the parentheses omitted in Python:

®val¯ & ®mask¯ == ®expected¯

Unsurprisingly; since exactly *that* was the obvious (and single)
issue with C's precedence definitions.

Janis


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/29/2026 1:09 AM, Bonita Montero wrote:

Am 28.05.2026 um 21:07 schrieb BGB:

Both C++ and BS2 had exceptions, but in both cases, enabling them has
non-zero overhead.

Table-driven exception handling isn't very old but currently it applies
for every 64 bit platform; under Windows / x86 concatenated stackframes
are used. With table-driven EH the additional overhead is zero. And with
the older concatenated stackframes the overhad is very low.

IME, it is not quite zero, but it is the least-overhead option I am
aware of.

Arguably it is less overhead than doing state-capture and adding exception-frames to a linked list, but, ...

It is also less bloated than needing to drag around DWARF debug-info.




Looks it up in my specs for the PE/COFF variant I am using for my own
target, the entry is 64 bits per entry:
32 bits: Func Base RVA
32 bits: Packed Lengths
( 7: 0): Length of prolog in instruction words;
(29: 8): Length of function in instruction words.
( 30): Selector for instruction word size (*1).
( 31): Set to indicated whether a catch handler exists.

These go into ".pdata" which is basically an array of these entries.


*1: Relevant for ISA's that can have 16 or 32 bit instruction words, but
a given function might only use 32-bit words despite 16 being available.
Say, for example, RV64GC but only using RV64G for a given function.
Set to indicate only 32-bit instructions were used.
Currently unused.



Looking at it again, I had forgot the mechanism:
The basic handler does some trickery with the saved link register and
then branches to the epilog, which then does any cleanup and returns
control back to the unwind code (the original LR is put into an area the unwind logic can use for the next step).

If catch handlers exists, they will check the unwinding RVA against the
RVA ranges for the try blocks, and if there is a hit, it can check if
the exception object matches the class. This part is handled by code
generated by the compiler. If no hit, it goes through the epilog which
then hands it back to the unwinder.

So, minimum-case cost is:
8 bytes of ".pdata" + 4 instruction words
Or around 24 bytes.



Say, for example, one has a program with 1200 functions, and an
average-length function of 276 bytes.

This adds 19K vs 331K to ".text", expanding the overall size of ".text"
by around 6% (plus ~ 10 of ".pdata").

Granted, this is vs, say:
23K used for string literals;
144K for the initial contents of ".data";
...


It is possible some special case could be defined that changes the size layout, say, top bits as tag:
Tag=00: Same as present
Tag=01
( 7: 0): Size of stack frame in QWORDs;
(21: 8): Length of function in instruction words.
(29:22): Length of Epilog in instruction words
(31:30): Tag (01)
Tag=10: Reserved
Tag=11
( 7: 0): Length of prolog in instruction words;
(29: 8): Length of function in instruction words.
(31:30): Tag (11)

with the 01 case able to trim off a few instructions.




Note that a lot of this stuff uses RVAs, where locations within the
larger VAS are expressed as 32-bit offsets relative to the base address
of the PE/COFF image. Some metadata structures effectively hold
Self-RVA's as a trick to allow finding the image base address for other
RVAs (rather than using full 64-bit pointers; also RVAs don't need base-relocs).


Well, contrast ELF64 which uses 64-bit values for everything and
needlessly so bloats the metadata.

Can't really go much smaller than RVAs though.
Well, except base relocs, which typically use a 16-bit format.
(11: 0): Base offset of relocated field within current 4K page
(15:12): Type of Base-Reloc to apply

Traditional PE/COFF base relocs had 8B per page:
Page RVA, Count

I was able to get rid of this cost though, and instead switched to
mostly using an all-16-bit format; Where Reloc Type 0 is used to encode
a page-advance and similar. This could also save a bit of space for
".reloc" by blobbing all of the relocs together per-section rather than per-page.

And, then I lose incentive as I don't really use C++, and (unlike C
land) the C++ people tend to chase after the newest features, rather
than stick to an older and more conservative subset.

There's no language where the users are so detail focussed and open
to new features. But this new features raise the productivity a lot
and it was far beyond C even with C++98. With C you've to flip every
bit ourself over and over and C++ does replace that with standard
components.
This has been emphasized through a lot of C++-channels on YouTube;
I personally prefer the CppCon vids or the vids of Jason Turner.
And there are a lot of good books like these of Rainer Grimm and
Nicolai Josuttis.

The issue is not whether they save effort, but rather the how they can
effect build times and binary sizes.

Like, if one doesn't care that the compiler takes a long time to run and
the EXE is needlessly large, maybe OK, not great if one does care...

Having to spend minutes or more waiting for the compiler would seriously
hurt momentum for many tasks.

Well, and I have not seen much evidence that moderate-sized C++
codebases (using modern features) can have sub-minute build times.



In some cases, one might be looking at things to try to trim to keep
sizes modest.

Say, for example, if the Boot ROM requires keeping everything under 32K.
Or they ideally don't want the OS kernel going over 500K.


Like, code footprint doesn't always matter, but is not always free.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

On 2026-05-28 11:57, BGB wrote:

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

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.

Wow! - That's completely different from my experience and practice.

It's what makes usage simple, fast, reliable. Not wasting time for
details, or fixing technical bugs that should be prevented by the
language.

Possibly.

But, it is also possible I approach programming in a different way.

[...]

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.)

Both have a similar issue when used in a naive way though:
ÿÿ Non-careful use of either results in code bloat.

Okay, "when used in a in a naive way". - Let's leave it at that,
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.

Possibly, a lot could depend on how one is counting things as well.


In a lot of cases when using GCC, I end up using:
-ffunction-sections -fdata-sections -Wl,-gc-sections

Because otherwise it likes wasting code space by retaining unreachable functions.

Using "static inline" functions also carries a risk because the can end
up duplicated across multiple translation units, or in multiple places
within the same translation unit, so is best used sparingly.

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...

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".

Well, for example:
ÿÿ 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).

We obviously disagree completely in what's "syntactic sugar".

(With that reasoning all ("C" or other languages') features are
"syntactic sugar" because you can do that also with assembly?)

To be excluded from being syntactic sugar, it needs to be something that
is not generally possible to express within the base language.

So, for example:
Things like operator overloading or classes are syntactic sugar IMO, as
what they do can be expressed in C, even if a lot less pretty (or far
from an idiomatic style).


I would not consider exceptions or RTTI as syntactic sugar, because
these involve things that do not map to native C.

Using longjmp, pointer-tagging, etc, could be considered as analogous,
but not functionally equivalent, to what C++ is doing in these cases.


As for assembler:
Main reasons not to use assembler for everything:
Needlessly verbose;
Non-portable.

However, often one can still end up writing C code that looks like
assembler sometimes, as this is often an effective way to optimize things.

Say, for example:
v0=cs[0];
v2=cs[2];
v1=cs[1];
v3=vs[3];
ct[0]=v0;
ct[2]=v2;
ct[1]=v1;
ct[3]=v3;
Vs:
ct[0]=cs[0];
ct[1]=cs[1];
ct[2]=cs[2];
ct[3]=cs[3];

Because the extra variables can avoid help sidestep latency from the
load instructions and staggering stores can avoid penalties of two
adjacent stores to the same cache-line in some cache architectures.
Where, in the latter case, the compiler may fail to as effectively avoid
the load-latency or realize the need to stagger the stores for best performance, ...

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"?)

Well, it is a thing that can be done, but is a double-edged sword.
Saves code one might have to write out manually.
But, is very easy to result in things that negatively effect build times.

A simple, less-abstracted language can certainly be easier (thus
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.)

I mostly do stuff myself. But, long build times can kill momentum.

In some cases, it is unavoidable, for example, Vivado takes 40 minutes
to synthesize an FPGA design, and Verilator may take multiple hours of
running to know whether or not something worked.

This sucks, but little I can do about this.
I do most of my software level testing in an emulator though, which does
at least have a fast turn-around...


Can't run my C compiler on my custom target though, as sadly, it is too
big and slow (would use too much RAM and take too long to run).

As noted, my compiler is around 370 kLOC.
Overall project size is a few MLOC.

Granted, my compiler has grown a few things related to resource/asset packaging as well, so it also among other things works as an image
format converter, audio format converter, data packaging tool, and has
some wacky appendages like a SCAD interpreter and CSG geometry stuff
glued on (even if, yeah, interpreting SCAD and processing CSG models has little to do with compiling stuff).


Sometimes one would prefer the code to be smaller, but sometimes it is not.


Some of my older code has vestiges of a lot of rampant copy/paste
though. Not ideal. And in my case my compiler, at its core, has its
basis in code I wrote in high-school (back when my coding skills left something to be desired). Compiler is many layers of rampant hackery though.

It is more a case of "too bad it isn't less of a mess", but then efforts
to replace it had mostly fizzled; and the core design of the compiler
does seem to work effectively.

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.

We avoided macros if possible.

They are de-facto for constants and similar, but for longer stuff is
better avoided.

#define FOO(arg) \
if(1) { \
... big blob of crap ... \
}

Being one of those, "yeah, don't do this" things.


Like, if a person finds themselves tempted to do this, maybe step back
and try to figure out how one ended up in this situation and if there is
a way out. If people start doing this too much, the code turns to crap.


I once implemented a VM backend where I did this a lot, it did not end
well. Managed to get a VM interpreter that, while fast, took a painfully
long time to compile due to all the excessive code generated via macros.

Now stuff mostly just sucks due to other reasons.

And, one of the rare few "actually new" features C++ offers:
exceptions.

We used them already in the 1990's.

Here, "new" in the sense that it can't be mapped directly back to
stuff that can already be expressed natively in C.

Okay.

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).

The relative impact of try/catch is more modest.

Aha; I thought that this would have been the source of criticism.

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.

Well, even when exceptions are not used by a program, one may still see
a size delta of a few percent by enabling or disabling them...


But, ironically, I am not totally opposed to exceptions, as they can
serve a purpose...

Well, even if sometimes they just amount to a missed uncaught exception
nuking the program...


But, things can be considered in relative terms:
Like, C++ may carry various penalties vs C.

But, like, it is still going to run circles around something like Python
or Node.js ...



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 09:02, Janis Papanagnou wrote:

On 2026-05-29 01:54, Lawrence D?Oliveiro wrote:

On Thu, 28 May 2026 14:07:45 -0500, BGB wrote:

Infix notation and precedence rules are pros/cons.

Python took over most of the C operator precedence rules, with one
interesting wrinkle: they moved up the precedence of the bitwise
operators so that what has to be written like this in C:

ÿÿÿÿ (®val¯ & ®mask¯) == ®expected¯

can have the parentheses omitted in Python:

ÿÿÿÿ ®val¯ & ®mask¯ == ®expected¯

Unsurprisingly; since exactly *that* was the obvious (and single)
issue with C's precedence definitions.

The only one?

How about:

* What is the order here: a ^ b | c

* Why do bitwise & | ^ need their own level anyway

* What is most intuitive precedence here: a << 3 + b, and what
is it in C

* Why do << >> have their own level anyway

* Why do == != have a difference precendence from < <= >= >

Further, here: 'a * b + c' the multplication is done first, but here:

a *= b += c

It is done second.

The issue I have is whether augmented assignments should return a value
at all. It's just generally too confusing especially with mixed types.
It's confusing enough with assignments returning a value:

a = b = x;

Here, assuming x has no side-effects, you might expect this to mean the
same as:

b = x;
a = x;

In fact it's more like: 'b = x; a = b;'. Example:

double a;
float b;

a = b = 3.14159265358979323846;

Here, 'a' will be assigned the less precise 32-bit version of the RHS.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

On 2026-05-28 11:57, BGB wrote:

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

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.

Possibly, a lot could depend on how one is counting things as well.

In a lot of cases when using GCC, I end up using:
ÿ -ffunction-sections -fdata-sections -Wl,-gc-sections

On many targets, "-fdata-sections" can lead to noticeably larger and
slower code because it effectively eliminates section anchor
optimisations. It does not negatively affect x86 AFAICS, because x86
does not use section anchors.

<https://godbolt.org/z/zeoq41Y7d>

With -fsection-anchors (enabled with optimisation on targets that
support it - generally RISCy load/store architectures), program-lifetime variables are kept together in a lump (as though they were in a struct)
and often addressed by a pointer to that pretend struct. Thus if a
function accesses two variables "a" and "b", instead of having to load
the addresses of each of "a" and "b" into separate registers, it loads
an "anchor" into one register and accesses the variables with reg+offset addressing.

I've seen "-fdata-sections" used regularly in embedded systems - it is
almost always a bad idea.

("-ffunction-sections" is often very helpful to reduce code image size,
so keep that one.)

Because otherwise it likes wasting code space by retaining unreachable functions.

Using "static inline" functions also carries a risk because the can end
up duplicated across multiple translation units, or in multiple places within the same translation unit, so is best used sparingly.

Usually you would only use static inline functions for small functions
in headers, where they are a better choice than function-like macros.
In a C file, there is rarely much point in declaring a function "inline"
- optimising compilers will inline or not as they see fit, without
regard for "inline". "static" on its own is, of course, always a good
idea for functions or data that is not "exported" by the current
translation unit, and will often make generated code smaller.

How much or how little duplication of code there will be within one translation unit will depend on compiler settings and the rest of the
code, and not on whether or not you use "inline".

As for assembler:
Main reasons not to use assembler for everything:
ÿ Needlessly verbose;
ÿ Non-portable.

However, often one can still end up writing C code that looks like
assembler sometimes, as this is often an effective way to optimize things.

Say, for example:
ÿ v0=cs[0];
ÿ v2=cs[2];
ÿ v1=cs[1];
ÿ v3=vs[3];
ÿ ct[0]=v0;
ÿ ct[2]=v2;
ÿ ct[1]=v1;
ÿ ct[3]=v3;
Vs:
ÿ ct[0]=cs[0];
ÿ ct[1]=cs[1];
ÿ ct[2]=cs[2];
ÿ ct[3]=cs[3];

Because the extra variables can avoid help sidestep latency from the
load instructions and staggering stores can avoid penalties of two
adjacent stores to the same cache-line in some cache architectures.
Where, in the latter case, the compiler may fail to as effectively avoid
the load-latency or realize the need to stagger the stores for best performance, ...

That might be the case for a very simplistic compiler. With an
optimising compiler, these extra variables will quickly be eliminated.
If the compiler has a good scheduling model of the device, it do
whatever instruction scheduling works best for that processor. If the
model is not good enough, it will be suboptimal. I would not, however,
expect any different in the generated code for the two code snippets.

Sometimes this kind of "manual optimisation" is helpful when you have to
try to get efficient results from a weak compiler, however.

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.

We avoided macros if possible.

They are de-facto for constants and similar, but for longer stuff is
better avoided.

Macros are rarely the best way to define constants. They are needed if
you are using the constants for pre-processor stuff like conditional compilation. But generally you get clearer code, better typing, and potentially several other benefits from using alternative choices like
"enum" (even for stand-alone integer constants), "static const"
variables, and in C23, "constexpr" variables. There's no doubt that a
lot of code /does/ use macros for constants, but I view it as a relic of
the past rather than good coding practice.

But, things can be considered in relative terms:
Like, C++ may carry various penalties vs C.

I don't find C++ carries noticeably penalties compared to C, for my
embedded work. But I do disable exceptions and RTTI - exceptions may
have very little run-time time overhead, but the unwind tables can be significant when code size is important in small systems.




--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 13:19, Bart wrote:

On 29/05/2026 09:02, Janis Papanagnou wrote:

On 2026-05-29 01:54, Lawrence D?Oliveiro wrote:

On Thu, 28 May 2026 14:07:45 -0500, BGB wrote:

Infix notation and precedence rules are pros/cons.

Python took over most of the C operator precedence rules, with one
interesting wrinkle: they moved up the precedence of the bitwise
operators so that what has to be written like this in C:

ÿÿÿÿ (®val¯ & ®mask¯) == ®expected¯

can have the parentheses omitted in Python:

ÿÿÿÿ ®val¯ & ®mask¯ == ®expected¯

Unsurprisingly; since exactly *that* was the obvious (and single)
issue with C's precedence definitions.

The only one?

Yes. - That group of operators was what I noticed immediately when
I've learned "C" back then reading K&R. Much later I've seen some
folks also mentioning that specific disorder. Still later I've got
information about a paper of some of the "C" authors admitting that
mistake. (I think I've also seen comments from some regulars here
that also noted that.) That all together is certainly a solid base
for a sensible valuation.

How about:
[...]

Your well known very specific views have never been a landmark for reconsidering my personal judgement. (And I'm positive that won't
ever change; never mind!)

The "confusions" you listed - not worth quoting - are your personal
problem. The precedence of assignments and related operations and
their evaluation order are clear, reasonable, and they can be found
that way in many existing languages. (Some of your listed "problems"
have been answered here already in the past - I wonder whether it's
worth replying to you if you don't learn from the answers. You seem
to have fun wasting everyone's time.)

You can continue to assume that all those people, language designers
and programmers, are wrong, and I accept your astonishment that for
those folks it's not "confusing" as it is for you.

Janis


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Am 29.05.2026 um 11:15 schrieb BGB:

Like, if one doesn't care that the compiler takes a long time to run
and the EXE is needlessly large, maybe OK, not great if one does care...

Binary size doesn't matter with Windows.

Having to spend minutes or more waiting for the compiler would seriously hurt momentum for many tasks.

Use C++20 modules and parallel builds.

Say, for example, if the Boot ROM requires keeping everything under 32K.

C++ was designed for large scale program development.
With 32K-systems you can stick with C.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 13:46, Janis Papanagnou wrote:

On 2026-05-29 13:19, Bart wrote:

On 29/05/2026 09:02, Janis Papanagnou wrote:

On 2026-05-29 01:54, Lawrence D?Oliveiro wrote:

On Thu, 28 May 2026 14:07:45 -0500, BGB wrote:

Infix notation and precedence rules are pros/cons.

Python took over most of the C operator precedence rules, with one
interesting wrinkle: they moved up the precedence of the bitwise
operators so that what has to be written like this in C:

ÿÿÿÿ (®val¯ & ®mask¯) == ®expected¯

can have the parentheses omitted in Python:

ÿÿÿÿ ®val¯ & ®mask¯ == ®expected¯

Unsurprisingly; since exactly *that* was the obvious (and single)
issue with C's precedence definitions.

The only one?

Yes. - That group of operators was what I noticed immediately when
I've learned "C" back then reading K&R. Much later I've seen some
folks also mentioning that specific disorder. Still later I've got information about a paper of some of the "C" authors admitting that
mistake. (I think I've also seen comments from some regulars here
that also noted that.) That all together is certainly a solid base
for a sensible valuation.

How about:
[...]

Your well known very specific views have never been a landmark for reconsidering my personal judgement. (And I'm positive that won't
ever change; never mind!)

The "confusions" you listed - not worth quoting - are your personal
problem. The precedence of assignments and related operations and
their evaluation order are clear, reasonable, and they can be found
that way in many existing languages. (Some of your listed "problems"
have been answered here already in the past - I wonder whether it's
worth replying to you if you don't learn from the answers. You seem
to have fun wasting everyone's time.)

You can continue to assume that all those people, language designers
and programmers, are wrong,

I noticed that you didn't answer my questions.

Precedence is 100% for the benefit of human programmers, therefore if
you have lots of obscure or unintuitive levels, they have to provide
some extra value.

Having too many levels, having them unintuitive, and having them differ
across languages, suggests that the value either doesn't exist or is not worthwhile.

So, yes, language designers can be wrong. Having lots of obscure
precedence levels SOUNDS a good idea and it is VERY EASY to implement,
hence it is commonly found. And newer languages are often obliged to perpetuate those decisions.

You can agree or disagree with the above, but if the latter, I'd quite
like to hear your arguments, and some examples that show the advantages
of having ^ one level above &, or one level below, or whatever the hell
it is.

and I accept your astonishment that for
those folks it's not "confusing" as it is for you.

It was presumably confusing for Google when they decided to have a much reduced set for their Go language.

Something you might do when you have time (as I'm busy), is to analyse
the expressions in some C codebases, and isolate those where removal of parentheses that group terms, would result in exactly the same shape of expressions, and are therefore redundant.

(You would have to exclude ones using macros.)

It would be interesting to see if the use of those unnecessary
parentheses correlated more closely with the less well known precedence levels.

If so, then having those custom levels was unnecessary.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

On 2026-05-28 11:57, BGB wrote:

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

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.

Wow! - That's completely different from my experience and practice.

It's what makes usage simple, fast, reliable. Not wasting time for
details, or fixing technical bugs that should be prevented by the
language.

Possibly.

But, it is also possible I approach programming in a different way.

If you're doing your own personal stuff that doesn't surprise me.

[...]

Possibly, a lot could depend on how one is counting things as well.

In a lot of cases when using GCC, I end up using:
ÿ -ffunction-sections -fdata-sections -Wl,-gc-sections

Well, you mentioned gcc now repeatedly. Myself I had been using gcc
mainly in private context only. Professionally we (mostly) used the
tools that came with the vendors on commercial (often Unix) systems.

I really cannot tell about Windows environments, Cygwin, or using
(maybe older?) gcc versions for large scale software development.
For newer systems and versions I'd certainly not expect problems
as you seem to have encountered.

[...]

[...]

To be excluded from being syntactic sugar, it needs to be something that
is not generally possible to express within the base language.

So, for example:
Things like operator overloading or classes are syntactic sugar IMO, as
what they do can be expressed in C, even if a lot less pretty (or far
from an idiomatic style).

I would not consider exceptions or RTTI as syntactic sugar, because
these involve things that do not map to native C.

Using longjmp, pointer-tagging, etc, could be considered as analogous,
but not functionally equivalent, to what C++ is doing in these cases.

Thanks for explaining your view on "syntactic sugar".

[...]

We avoided macros if possible.

They are de-facto for constants and similar, but for longer stuff is
better avoided.

We've been talking about C++; for constants I regularly use constants.

In "C", frankly, it appears to me less important; I used to use Cpp
names for constant items or expressions, mainly because that's "how
it is done in C". - OTOH, if I can give an item a type, why should
I use a primitive mechanism. Because it's faster? No memory wasted?

In our C++ projects we used Cpp features certainly not for constant
literals. We used them for tags (prevent double inclusion of h-files), conditionals, and some such. Rarely for more tricky things involving
tasks to circumvent limitations of the "C" language in cases where we
wrote code that should work with both of these languages.

Janis

[...]

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 15:22, Bart wrote:

On 29/05/2026 13:46, Janis Papanagnou wrote:

On 2026-05-29 13:19, Bart wrote:

On 29/05/2026 09:02, Janis Papanagnou wrote:

On 2026-05-29 01:54, Lawrence D?Oliveiro wrote:

On Thu, 28 May 2026 14:07:45 -0500, BGB wrote:

[...]

[...]

The "confusions" you listed - not worth quoting - are your personal
problem. The precedence of assignments and related operations and
their evaluation order are clear, reasonable, and they can be found
that way in many existing languages. (Some of your listed "problems"
have been answered here already in the past - I wonder whether it's
worth replying to you if you don't learn from the answers. You seem
to have fun wasting everyone's time.)

[...]

I noticed that you didn't answer my questions.

Yes, because, as experience shows, it's obviously a waste of time!

Okay, I'll bite. - I'll go waste my time again and comment on your
other post where you said you are confused about these cases...

Janis

[...]

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-05-29 15:22, Bart wrote:

On 29/05/2026 13:46, Janis Papanagnou wrote:

On 2026-05-29 13:19, Bart wrote:

On 29/05/2026 09:02, Janis Papanagnou wrote:

On 2026-05-29 01:54, Lawrence D?Oliveiro wrote:

On Thu, 28 May 2026 14:07:45 -0500, BGB wrote:

[...]

[...]

The "confusions" you listed - not worth quoting - are your personal
problem. The precedence of assignments and related operations and
their evaluation order are clear, reasonable, and they can be found
that way in many existing languages. (Some of your listed "problems"
have been answered here already in the past - I wonder whether it's
worth replying to you if you don't learn from the answers. You seem
to have fun wasting everyone's time.)

[...]

I noticed that you didn't answer my questions.

Yes, because, as experience shows, it's obviously a waste of time!

Okay, I'll bite. - I'll go waste my time again and comment on your
other post where you said you are confused about these cases...

Why bother? C isn't ever going to change operator precedence
just to make Bart happy.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 16:15, Janis Papanagnou wrote:

On 2026-05-29 15:22, Bart wrote:

On 29/05/2026 13:46, Janis Papanagnou wrote:

On 2026-05-29 13:19, Bart wrote:

On 29/05/2026 09:02, Janis Papanagnou wrote:

On 2026-05-29 01:54, Lawrence D?Oliveiro wrote:

On Thu, 28 May 2026 14:07:45 -0500, BGB wrote:

[...]

[...]

The "confusions" you listed - not worth quoting - are your personal
problem. The precedence of assignments and related operations and
their evaluation order are clear, reasonable, and they can be found
that way in many existing languages. (Some of your listed "problems"
have been answered here already in the past - I wonder whether it's
worth replying to you if you don't learn from the answers. You seem
to have fun wasting everyone's time.)

[...]

I noticed that you didn't answer my questions.

Yes, because, as experience shows, it's obviously a waste of time!

It can go both ways.

You always exasperatingly insist that there is only one thing wrong with
C's precedence rules, and I think you said once that they are are
otherwise perfect. And yet there endless examples on forums of people
saying they are confusing.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 13:19, Bart wrote:

How about:

Generally; if in doubt you can always inspect the precedence
table that you find in K&R and elsewhere. Below some hints to
hopefully reduce your confusion...

* What is the order here: a ^ b | c

Personally I don't think that there's a prevalent definition
how these should be ordered. - But note the history of these
operators, which was BTW why they are in "C" at the positions
that they are; their (potential) use as boolean sets.

To memorize the bit-value operations you can associate them
with the glyphs for the boolean operations; per convention
AND (&&) comes before OR (||), and insert the bitwise xor in
between. - As said; there's a rationale for the choice, and
a historic explanation (that makes sense), but you can in
case of doubt or to make things clearer also use parentheses.

* Why do bitwise & | ^ need their own level anyway

For historic reasons of potential use. (As said above.)

* What is most intuitive precedence here: a << 3 + b, and what
ÿ is it in C

What it is in "C" you should look up in the precedence table.

What it is intuitively depends on what the programmer wanted to
express. As it is written a shift by a calculated expression
seems have been the intention, and that's also how "C" handles
that.

Why would one who intends to say: make space for three bits in
'a' to put there the bit-pattern stored in 'b'? If I'd wanted to
express that I'd use a binary '|', and because or the well known
precedence I'd have no parenthesis around, as in a << 3 | b .

Of course there's also the potential semantics that you have a
'b' that exceeds three bit and you want to have that added to the
shifted value of 'a'. But then I'd not use bit-value operations
to express that but the clear and more appropriate a * 8 + b .

Both semantics bit-op and int-arithmetic don't need parenthesis
in "C" because of its clear and sensible precedence.

You are mixing bit-ops and arithmetic unnecessarily, but you are
also too lazy to write parenthesis to clear up your dirty code?

* Why do << >> have their own level anyway

As you have been told so many times; to not require parentheses
unnecessarily, to be able to omit them and not pollute the code
with parentheses in a language that is already full of all sorts
of { } [ ] ( ) and other punctuation characters.

* Why do == != have a difference precendence from < <= >= >

I've explained that already twice in the past.

Further, here: 'a * b + c' the multplication is done first, but here:

ÿÿ aÿ *= b += c

It is done second.

You understand that '=', '*=', and '*' are three different things,
don't you?

I hope you understand that '=' should have low precedence. And that
it makes sense to evaluate that from right to left. Do you follow?

"C" obviously decided to have them all, =, +=, *=, etc. in a single
group, and thus evaluated from right to left. - Easy rule, easy to
memorize. - And that is actually what you are demanding from many
other operators, to put them in a single group. - But here you are
complaining about it!

Of course the rules for those combined (sort of two-address) operators
could have been defined differently, in an own group with other rules.
(Algol 68 had done that, actually; the semantics are like "apply these operations from left to right, indicating an incremental modification
of the underlying value.)

If "C" would have separated these operators from the assignment and
created another own group with different evaluation rules you'd also
have complained.

The issue I have is whether augmented assignments should return a value
at all. It's just generally too confusing especially with mixed types.

If you're confused about something either try to understand the rule,
or just learn it without understanding it, or look it up, a or write
your programs in a way that you understand; use parentheses, separate
complex expressions to simpler ones, etc.

It's confusing enough with assignments returning a value:

ÿÿ a = b = x;

If it hurts/confuses you then don't use that feature.

Here, assuming x has no side-effects, you might expect this to mean the
same as:

ÿÿ b = x;
ÿÿ a = x;

I cannot tell what your brain makes you expect one semantic or another.
The semantics are clearly defined. Your interpretation here is wrong.

All I can suggest is what I've written above already; and to spare you
a search, it was:

If you're confused about something either try to understand the rule,
or just learn it without understanding it, or look it up, a or write
your programs in a way that you understand; use parentheses, separate
complex expressions to simpler ones, etc.

In fact it's more like: 'b = x; a = b;'. Example:

ÿÿÿ double a;
ÿÿÿ float b;

ÿÿÿ aÿ = b = 3.14159265358979323846;

Here, 'a' will be assigned the less precise 32-bit version of the RHS.

And why are you composing such stupid examples (if not only for sake
of an argument)? - An experienced programmer wouldn't write such an
expression with mixed types if he intends clear and non-dubious code.

Janis


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 16:59, Scott Lurndal wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-05-29 15:22, Bart wrote:

On 29/05/2026 13:46, Janis Papanagnou wrote:

On 2026-05-29 13:19, Bart wrote:

On 29/05/2026 09:02, Janis Papanagnou wrote:

On 2026-05-29 01:54, Lawrence D?Oliveiro wrote:

On Thu, 28 May 2026 14:07:45 -0500, BGB wrote:

[...]

[...]

The "confusions" you listed - not worth quoting - are your personal
problem. The precedence of assignments and related operations and
their evaluation order are clear, reasonable, and they can be found
that way in many existing languages. (Some of your listed "problems"
have been answered here already in the past - I wonder whether it's
worth replying to you if you don't learn from the answers. You seem
to have fun wasting everyone's time.)

[...]

I noticed that you didn't answer my questions.

Yes, because, as experience shows, it's obviously a waste of time!

Okay, I'll bite. - I'll go waste my time again and comment on your
other post where you said you are confused about these cases...

Why bother? C isn't ever going to change operator precedence
just to make Bart happy.

It would make me happy just for someone to admit there are problems. JP
always says they are perfect but for one little thing.

What a C compiler /can/ do is to warn when an expression relies on
knowing the precedence of the more obscure operators.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 18:05, Bart wrote:

On 29/05/2026 16:15, Janis Papanagnou wrote:

On 2026-05-29 15:22, Bart wrote:

On 29/05/2026 13:46, Janis Papanagnou wrote:

On 2026-05-29 13:19, Bart wrote:

On 29/05/2026 09:02, Janis Papanagnou wrote:

On 2026-05-29 01:54, Lawrence D?Oliveiro wrote:

On Thu, 28 May 2026 14:07:45 -0500, BGB wrote:

[...]

[...]

The "confusions" you listed - not worth quoting - are your personal
problem. The precedence of assignments and related operations and
their evaluation order are clear, reasonable, and they can be found
that way in many existing languages. (Some of your listed "problems"
have been answered here already in the past - I wonder whether it's
worth replying to you if you don't learn from the answers. You seem
to have fun wasting everyone's time.)

[...]

I noticed that you didn't answer my questions.

Yes, because, as experience shows, it's obviously a waste of time!

(My reply on your previous examples just posted.)

It can go both ways.

You always exasperatingly insist that there is only one thing wrong with
C's precedence rules, and I think you said once that they are are
otherwise perfect.

It is true and acknowledged even by the designers of the C-language
that there's a misplaced group in the table; the three bit-ops.

I don't think that "perfect" is a fitting word, but it's otherwise
(modulo bit-ops) surely an *appropriate* sensible choice they made.

The less important options might be defined in one way or another;
and various language designers have taken different ways how many
groups they define, or how boolean and numeric operators relate in
precedence, for example.

And yet there endless examples on forums of people
saying they are confusing.

Your endless complaint-tirades may have made me miss these dubious
"endless examples on forums of people saying they are confusing".
If you are active on these forums I'd at least not be astonished
if you'd contributed to anyone's confusion given how you behave
here even on simple and clear facts about "C".

Janis


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 18:12, Bart wrote:

On 29/05/2026 16:59, Scott Lurndal wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-05-29 15:22, Bart wrote:

I noticed that you didn't answer my questions.

Yes, because, as experience shows, it's obviously a waste of time!

Okay, I'll bite. - I'll go waste my time again and comment on your
other post where you said you are confused about these cases...

Why bother?ÿ C isn't ever going to change operator precedence
just to make Bart happy.

I think it's the "someone is wrong on the internet" syndrome.[*]
My apologies. :-)

It would make me happy just for someone to admit there are problems. JP always says they are perfect but for one little thing.

You said in your previous post that I would have said that they
are perfect. And now you are even saying that I'd always say that.

Please stop that!

Just for the record...

What I would say is that operator precedences are in "C"
"sensibly and appropriately defined, modulo the bit-ops".

If you want to cite me in future please quote this statement
and not anything else.

Janis

[*] https://xkcd.com/386/


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/29/26 15:22, Bart wrote:

Something you might do when you have time (as I'm busy), is to analyse
the expressions in some C codebases, and isolate those where removal of parentheses that group terms, would result in exactly the same shape of expressions, and are therefore redundant.

This is a strange exercice. When I write complex expression,
I sometime use redondant parenthesis for the clarity of
my intentions about this computation. I'm thinking that
those extra (()) are a sort of in-line comments.

--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 18:29, tTh wrote:

On 5/29/26 15:22, Bart wrote:

Something you might do when you have time (as I'm busy), is to analyse
the expressions in some C codebases, and isolate those where removal
of parentheses that group terms, would result in exactly the same
shape of expressions, and are therefore redundant.

ÿÿ This is a strange exercice. When I write complex expression,
ÿÿ I sometime use redondant parenthesis for the clarity of
ÿÿ my intentions about this computation. I'm thinking that
ÿÿ those extra (()) are a sort of in-line comments.

Sure, but some here like to say that such expressions, if they still
work without parentheses, are unambiguous anyway.

They forget that people aren't compilers.

And then the point becomes, if you always add the parentheses, what was
the point of having that particular precedence level?

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/29/2026 12:56 AM, Janis Papanagnou wrote:

On 2026-05-28 21:47, Chris M. Thomasson wrote:

On 5/28/2026 12:18 AM, Janis Papanagnou wrote:

[...]

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.)

C's problems with memory? Don't you mean the programmers that make bugs?

I'm not sure you're serious here or just joking. - To clarify...

Yes, the programmers "implement the bugs", and the language makes it
just easy and obligingly support the programmers to make such bugs.

Well... Actually, its not C's fault at all. We have some tools to help a programmer, but ultimately its up to them...?

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 17:48, Janis Papanagnou wrote:

On 2026-05-29 18:12, Bart wrote:

On 29/05/2026 16:59, Scott Lurndal wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-05-29 15:22, Bart wrote:

I noticed that you didn't answer my questions.

Yes, because, as experience shows, it's obviously a waste of time!

Okay, I'll bite. - I'll go waste my time again and comment on your
other post where you said you are confused about these cases...

Why bother?ÿ C isn't ever going to change operator precedence
just to make Bart happy.

I think it's the "someone is wrong on the internet" syndrome.[*]
My apologies. :-)

It would make me happy just for someone to admit there are problems.
JP always says they are perfect but for one little thing.

You said in your previous post that I would have said that they
are perfect. And now you are even saying that I'd always say that.

Please stop that!

Just for the record...

What I would say is that operator precedences are in "C"
"sensibly and appropriately defined, modulo the bit-ops".

You actually said this:

(The point is that - with the exception of & ^ | - the ranking
makes perfectly sense and should be easily usable without doubt
by a concept-knowing programmer."

(14-May-2026 0159 BST.)

And today:

Unsurprisingly; since exactly *that* was the obvious (and single)
issue with C's precedence definitions.

So you do seem to have a consistent view that there is only one thing
wrong with C operator precedence.


However, in that same 14-May post was this exchange:

Dan Cross:

Programmers _should_ absolutely learn the rules. But in C,
there are many of them, and some of them are deceptively subtle.

JP:

We agreed.

So, a hint of something else that is amiss? You just seem reluctant to
say it yourself, but will disagree with me when I suggest it, while at
the same time agree when somebody else does so.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 17:10, Janis Papanagnou wrote:

On 2026-05-29 13:19, Bart wrote:

Further, here: 'a * b + c' the multplication is done first, but here:

ÿÿÿ aÿ *= b += c

It is done second.

You understand that '=', '*=', and '*' are three different things,
don't you?

I hope you understand that '=' should have low precedence. And that
it makes sense to evaluate that from right to left. Do you follow?

"C" obviously decided to have them all, =, +=, *=, etc. in a single
group, and thus evaluated from right to left. - Easy rule, easy to
memorize. - And that is actually what you are demanding from many
other operators, to put them in a single group. - But here you are complaining about it!

Of course the rules for those combined (sort of two-address) operators
could have been defined differently, in an own group with other rules.
(Algol 68 had done that, actually; the semantics are like "apply these operations from left to right, indicating an incremental modification
of the underlying value.)

For those who don't know, the behaviour of this C code:

a += b += c += d

is very different from the equivalent Algol68:

a +:= b +:= c +:= d

This only modifies 'a'.

In fact it's more like: 'b = x; a = b;'. Example:

ÿÿÿÿ double a;
ÿÿÿÿ float b;

ÿÿÿÿ aÿ = b = 3.14159265358979323846;

Here, 'a' will be assigned the less precise 32-bit version of the RHS.

And why are you composing such stupid examples (if not only for sake
of an argument)? - An experienced programmer wouldn't write such an expression with mixed types if he intends clear and non-dubious code.

Maybe the code started off as:

a = x;
b = x;

and somebody decided to refactor it. Or it was 'a = b = x' all along but
a, b started off as the same type but then one was changed.

These things happen. When discussing language design we have to consider
what thousands or millions of programmers might think or assume.

You seem to like making it 100% about me. How about stopping making it
always so personal.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bart <bc@freeuk.com> writes:

On 29/05/2026 16:59, Scott Lurndal wrote:

[...]

Why bother? C isn't ever going to change operator precedence
just to make Bart happy.

It would make me happy just for someone to admit there are
problems.

There are problems.

Are you happy now?

I didn't think so.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bart <bc@freeuk.com> writes:

On 29/05/2026 18:29, tTh wrote:

On 5/29/26 15:22, Bart wrote:

Something you might do when you have time (as I'm busy), is to
analyse the expressions in some C codebases, and isolate those
where removal of parentheses that group terms, would result in
exactly the same shape of expressions, and are therefore redundant.

ÿÿ This is a strange exercice. When I write complex expression,
ÿÿ I sometime use redondant parenthesis for the clarity of
ÿÿ my intentions about this computation. I'm thinking that
ÿÿ those extra (()) are a sort of in-line comments.

Sure, but some here like to say that such expressions, if they still
work without parentheses, are unambiguous anyway.

They forget that people aren't compilers.

To state the obvious, complicated expressions that rely on C's more
obscure precedence can be confusing to some human readers, but are
unambiguous to compilers. Most of us will add parentheses that
are not strictly necessary to the compiler, but that are helpful to
human readers. There is no universal agreement on which parentheses
are helpful or necessary and which are not, and there never will be.

And then the point becomes, if you always add the parentheses, what
was the point of having that particular precedence level?

You're asking why C is designed the way it is. We could waste a
great deal of time and effort answering that for you. There are
numerous documents about the design and history of C, and of
its ancestor languages. I could provide you with links.

What if I did the research and presented you with an explanation for
all of C's precedence levels? What if I could tell you exactly what
Ken Thompson had in mind when he specified the expression syntax
for B, and exactly what Dennis Ritchie had in mind when he based C
on Thompson's work? What if you clearly and completely understood
why C's expression syntax is the way it is, including parts of the
syntax that Ritchie himself regretted, including parts that you
obviously could have done better?

What then? Would an answer to your question help you? Would it
satisfy you? Would you even thank me for the effort if I did that?
Or would you just keep complaining about something that cannot be
changed without breaking existing code? Would you talk about C's
expression syntax in a way intended to help others understand it,
or would you continue to post contrived examples that make it appear
as confusing as possible?

Bart, what do you want?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 20:28, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

or would you continue to post contrived examples that make it appear
as confusing as possible?

Examples are examples. Do you want me to post one that didn't illustrate
an issue? It necessaily has to be contrived.

Bart, what do you want?

Today I was just replying to this post today that I found annoying:

JP:

Unsurprisingly; since exactly *that* was the obvious (and single)
issue with C's precedence definitions.

That is, the suggestion, made several times by JP, that there is only
one thing wrong.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 12:10, Janis Papanagnou wrote:

On 2026-05-29 13:19, Bart wrote:

...

* What is the order here: a ^ b | c

(a^b)|c

Personally I don't think that there's a prevalent definition
how these should be ordered.

I'm not sure what you mean by "prevalent definition". Ordinarily, I'd
expect the C standard to qualify - it definitely defines the order, and
the very purpose of a language standard is to prevail over non-standard alternatives. However, I'm sure you're aware of the C standard, and made
that comment anyway, so I presume you mean something different by it.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 20:09, Bart wrote:

You actually said this:

You continue your trollish stance to cherry-pick words without
understanding or trying to understand what's been expressed.

The insight appears to me that you're taking communication in a
similar way as you "design" your languages; focusing on personal
*syntax* preferences instead of the more important *semantics*.

Despite we're talking in your native language (and not mine) you
obvious completely miss or deliberately ignore that there's a
difference between "it makes perfectly sense" and "it's perfect".
(I said the former, you put the latter in my mouth. And to not
get identified as a liar you're squirming with such moves. Gee!)

Or are again just confused about the difference, and despite you
have already been advised to quote what I think can neither be
misrepresented nor misinterpreted (since it doesn't contain common
word patterns that obviously confuse you)
>> What I would say is that operator precedences are in "C"
>> "sensibly and appropriately defined, modulo the bit-ops".
you're still playing your stupid game; you ignored that. I suggest
to try to map this statement to either of the above two statements,
the one I said and the one you (wrongly) attributed, and see which
one fits. (Hint: the former.)

[...]

Dan Cross:

Programmers _should_ absolutely learn the rules.ÿ But in C,
there are many of them, and some of them are deceptively subtle.

JP:

We agreed.

Bart, you are incapable of understanding semantics and associating
context.

Janis


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 21:49, Bart wrote:

On 29/05/2026 20:28, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

or would you continue to post contrived examples that make it appear
as confusing as possible?

Examples are examples. Do you want me to post one that didn't illustrate
an issue? It necessaily has to be contrived.

Bart, what do you want?

Today I was just replying to this post today that I found annoying:

JP:

Unsurprisingly; since exactly *that* was the obvious (and single)
issue with C's precedence definitions.

That is, the suggestion, made several times by JP, that there is only
one thing wrong.

The C-precedence rules have one issue. The rest is a sensible choice.

(The C-language has more issue, but that was not the topic here.)

Janis


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/29/2026 6:22 AM, David Brown wrote:

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

On 2026-05-28 11:57, BGB wrote:

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

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.

Possibly, a lot could depend on how one is counting things as well.


In a lot of cases when using GCC, I end up using:
ÿÿ -ffunction-sections -fdata-sections -Wl,-gc-sections

On many targets, "-fdata-sections" can lead to noticeably larger and
slower code because it effectively eliminates section anchor
optimisations.ÿ It does not negatively affect x86 AFAICS, because x86
does not use section anchors.

<https://godbolt.org/z/zeoq41Y7d>

With -fsection-anchors (enabled with optimisation on targets that
support it - generally RISCy load/store architectures), program-lifetime variables are kept together in a lump (as though they were in a struct)
and often addressed by a pointer to that pretend struct.ÿ Thus if a
function accesses two variables "a" and "b", instead of having to load
the addresses of each of "a" and "b" into separate registers, it loads
an "anchor" into one register and accesses the variables with reg+offset addressing.

I've seen "-fdata-sections" used regularly in embedded systems - it is almost always a bad idea.

("-ffunction-sections" is often very helpful to reduce code image size,
so keep that one.)

Both seem to help on x86, x86-64, and also on RISC-V, at making GCC's
output at least sorta space-comparable to my own compilers.

The merit of "-fdata-sections" is mostly that it eliminates unused
global variables; whereas "-ffunction-sections" eliminates unreachable functions.

Neither is needed with my own compiler, which compiles things in a way
such that it eliminates anything that is unreachable.


Both posed an issue initially when porting ROTT, because in some cases
it relied on the ability to go out-of-bounds for one array to access
data in another array. I ended up reworking some of these cases though
to use a single larger array.



Have noted though that GCC targeting RISC-V still tends to produce
fairly large binaries even with "-Os". Its code for the basic subset
(RV64G) does tend to be a little faster than what BGBCC generates, but
also a fair bit more bulky. Though, the final ELF file ends up bigger
still, as a significant chunk of the file ends up needing to hold ELF
related metadata (comparably, PE/COFF can end up much leaner here).


Though, on the other side, with modern MSVC, despite the relative
leanness of the PE/COFF format, MSVC tends to produce binaries with much larger ".text" sections.

This issue was a lot less with VS2008 though, which tended to generate less-bloated binaries (with code-size more competitive with GCC).


Also in modern MSVC, there is little distinction between "/O1" and
"/Os", both being more space-efficient than "/O2" (though, "/O2" is
usually faster, but also more prone to misguided attempts at auto-vectorization).

Because otherwise it likes wasting code space by retaining unreachable
functions.

Using "static inline" functions also carries a risk because the can
end up duplicated across multiple translation units, or in multiple
places within the same translation unit, so is best used sparingly.

Usually you would only use static inline functions for small functions
in headers, where they are a better choice than function-like macros. In
a C file, there is rarely much point in declaring a function "inline" - optimising compilers will inline or not as they see fit, without regard
for "inline".ÿ "static" on its own is, of course, always a good idea for functions or data that is not "exported" by the current translation
unit, and will often make generated code smaller.

How much or how little duplication of code there will be within one translation unit will depend on compiler settings and the rest of the
code, and not on whether or not you use "inline".

OK.

But, yeah, small functions are usually better than macros in at least
that the compiler can avoid duplicating them (or maybe merge them
between translation units when it notices that the contents are identical).

As for assembler:
Main reasons not to use assembler for everything:
ÿÿ Needlessly verbose;
ÿÿ Non-portable.

However, often one can still end up writing C code that looks like
assembler sometimes, as this is often an effective way to optimize
things.

Say, for example:
ÿÿ v0=cs[0];
ÿÿ v2=cs[2];
ÿÿ v1=cs[1];
ÿÿ v3=vs[3];
ÿÿ ct[0]=v0;
ÿÿ ct[2]=v2;
ÿÿ ct[1]=v1;
ÿÿ ct[3]=v3;
Vs:
ÿÿ ct[0]=cs[0];
ÿÿ ct[1]=cs[1];
ÿÿ ct[2]=cs[2];
ÿÿ ct[3]=cs[3];

Because the extra variables can avoid help sidestep latency from the
load instructions and staggering stores can avoid penalties of two
adjacent stores to the same cache-line in some cache architectures.
Where, in the latter case, the compiler may fail to as effectively
avoid the load-latency or realize the need to stagger the stores for
best performance, ...

That might be the case for a very simplistic compiler.ÿ With an
optimising compiler, these extra variables will quickly be eliminated.
If the compiler has a good scheduling model of the device, it do
whatever instruction scheduling works best for that processor.ÿ If the
model is not good enough, it will be suboptimal.ÿ I would not, however, expect any different in the generated code for the two code snippets.

Sometimes this kind of "manual optimisation" is helpful when you have to
try to get efficient results from a weak compiler, however.

Possibly, but this sort of thing can help with both BGBCC and with MSVC IME.


While BGBCC does use a shuffle-to-reorder instructions things, it may
fail to do so in some cases:
If the instructions end up mapped to the same CPU register;
If its heuristics can't prove non-alias.

Though, in the simple example given, it could (probably) turn the latter
into the former, but "better" to write code such that things are in
closer to the optimal order by default.

Note that using different variables with overlapping scopes reduces the likelihood of the compiler assigning both to the same register, which is
a much more real risk if relying on implicit temporaries (whose lifetime
only exists within a single expression).

But, in my case, a lot of this comes down to trying to tweak the
compilers' internal register allocation heuristics for best results (and
the tight balance between how many registers to save/restore for the
function, vs avoiding assigning short-lived temporaries to the same
register too quickly and hindering the instruction-scheduling).

Arguably, could make sense to instead do the reordering at the 3AC
level, rather than reordering at the level of ISA instructions, but this
is just sorta how I ended up doing things (and one can know the
effective timing latency of a CPU instruction a lot more easily than a
3AC op).

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.

We avoided macros if possible.

They are de-facto for constants and similar, but for longer stuff is
better avoided.

Macros are rarely the best way to define constants.ÿ They are needed if
you are using the constants for pre-processor stuff like conditional compilation.ÿ But generally you get clearer code, better typing, and potentially several other benefits from using alternative choices like "enum" (even for stand-alone integer constants), "static const"
variables, and in C23, "constexpr" variables.ÿ There's no doubt that a
lot of code /does/ use macros for constants, but I view it as a relic of
the past rather than good coding practice.

They are traditional...

Like:
static const double M_PI = 3.14159265358979;

Could also make sense, but people don't do usually this, they usually
use macros...

In BGBCC, both can be handled as constants, just they end up being
handled at different stages:
#define: Constant ends up inlined in the preprocessor/parse stage;
const: Constant shows up in the "reducer" (which evaluates constant expressions).

Where, as noted, BGBCC's pipeline looks kinda like:
Toplevel:
Ingest each named source file;

Then, in the C case, per translation unit:
Preprocess;
Parse;
Frontend Compile + Reduce;
This does an AST walk, but at each stage,
invokes the reducer to see if it can perform AST level rewrites;
Reducer can also implement some edge-case features.
So, is mostly necessary, vs an optional optimization thing.
Emits output as a Stack IL.
May be output to a file, or used as input to next stage.
The stack IL partly resembles a mix of JVM and .NET bytecode.
The IL ops themselves operate more like in .NET bytecode.
This serves the role of static libraries and object files.
For a static library, all the stack IL gets blobbed together.
So, every translation unit ends up effectively appended on.

Middle Stage (processes IL Blobs):
Processes Stack IL, translates to 3AC (loosely SSA form);
Builds a big table of all global declarations, etc.

Backend:
Walks call-graph to determine dependencies;
Unreachable functions/globals/etc are marked as culled.
Ranks all the functions and variables by priority;
Sorts them into roughly priority order;
Then does shuffling to try to density-optimize globals;
Swaps globals when doing so would allow more memory density.
May also apply random shuffling and clustering heuristics.
Then, compiles each function:
Figure out stack-frame layout,
how many registers to reserve,
etc.
Emit machine code for 3AC ops;
Try to shuffle instructions to improve instruction scheduling;
Or, if a variable:
Figure out whether it goes in ".data" or ".bss"
If initialized, deal with initialization stuff;
...
Or, an ASM Blob:
Assemble it.
Or, Ingests contents that go into ".rsrc" section;
May involve image and audio converters, etc;
BGBCC uses different resource sections from Windows though.
...
Output:
Gets is input as a set of sections, symbols, and relocs;
Figures out layout within the output image (eg, PE/COFF);
Figures out how much space it needs for base relocs, etc.
Builds up a table of "initial base-relocs"
Splats the sections into the image buffer;
Applies relevant relocs;
Sorts base relocs by RVA;
Generates actual ".reloc" section contents.
Fill in PE/COFF headers and similar;
If applicable, LZ4 compress the image.
I tend to store EXE's in LZ4 compressed form,
the image is decompressed during load.
This format leaves the initial PE/COFF headers uncompressed.
Need the headers to figure out where to load the image.
Else would need a temporary buffer to decompress into.


Typical loader process:
Look at headers;
Figure out where to load to, etc;
Read in (or decompress) image contents;
Apply base relocs;
Pull in any DLLs, etc;
Go.

The LZ4 compression is mostly because:
Loader is often IO bound;
May save memory in some cases;
LZ4 decompression is faster than more IO;
It also seems to be effective against program binaries (*).

*: I have my RP2 format, which generally does better for general purpose
data compression, but slightly worse for compressing program binaries,
so LZ4 has mostly won here. Also generally don't want a "stronger"
compressor, like Deflate, both because an Inflater is a much bigger
chunk of code, and also much slower than LZ4.



Can note that BGBCC also mostly takes over the role of the "resource
compiler" as well, so can process resources. These are generally listed
as a text file of entries to import, giving an internal "lumpname",
external filename, and a tag to specify which file conversions to apply.

I am using a vert different resource section type than Windows though,
in that I just sorta replaced it with a modified version of the Quake
WAD2 format (not to be confused with PAK, where PAK serves a different
role). Note that the WAD2 directory in this case uses RVA's and not
WAD-file offsets (so, effectively, it is integrated into the PE/COFF
image, not just a WAD file that was shoved in).

Generally, one can access lumps from C land with declarations like:
extern unsigned char __rsrc_lumpname[];


Typically, formats used internally are things like BMP and WAV. Though,
when using BMP, it is typically 16 color or 256 color to avoid wasting
space. Sometimes monochrome or 4 color. One downside of BMP is that for
a full 256-color palette it needs 1K of memory just for the palette,
tempting to consider a non-standard variant that uses RGB555 for the
palette (thus reducing it to 512 bytes). For small images it is often
smaller to store them as 16-bit hi-color to avoid the space penalty of
the color palette.

There are already non-standard BMP variants though, like BMP with LZ compression. A lot depends on what is needed for a particular use-case.


For WAV typical formats are 2 or 4 bit ADPCM at 8/11/16 kHz.
2 bit ADPCM: 16/22/32 kbps.
4 bit ADPCM: 32/44/64 kbps.

Have found encoder-side tricks to make ADPCM more compressible with LZ4. Basically, it tries to do a reverse LZ search when encoding and encodes
audio following patterns when the pattern would be a "close enough" match.

had also experimented before with using some trickery involving FIR
filters and lookup tables to improve perceptual quality of 8kHz/2b ADPCM
to try to make it sound "less like total crap". But, this requires
additional metadata and a more complex process to decode (and to get
best results with this will result in worse audio quality if the audio
is just naively decoded as 8kHz/2b ADPCM without the filters).

But, yeah, with these tricks can reduce the effective bitrate (when LZ4 compressed) down to around 8-12 kbps. Note that while entropy coding
could help more, it is modest, and the most effective strategy (range
coding) being mostly too slow to be worthwhile.

Also, of the things I have tested, ADPCM was still the front runner for "actually passable" audio quality in this domain (to me, some of the
modern cellphone codecs sound like unintelligible broken garbage, and
require much more complex decoders, not worth the bother).


only thing I have found that gets much lower bitrate is, say:
One divides the audio up into chunks of 64 samples (1/125 second for 8kHz); Pick the top 4 square-waves from between 1 and 4 kHz;
Encode the phase and intensity of each square wave.

Typically, the strategy was to break it into 4 half-octaves and pick the highest peak in each half-octave; and then totally ignore everything
below 1kHz. If the frequency and amplitude are encoded in around 16 bits
each, this achieves an effective bitrate of 8 kbps.

Though, another strategy was 8 quarter octaves and pick the top 4 loudest.

But, audio quality is worse than 2b ADPCM.

Can push it to 4kbps by only encoding the top 2 waveforms.
But, then speech sounds robotic and borderline unintelligible.
Note that dropping to 62.5 Hz sampling also makes speech unintelligible.

While traditionally, this used sine-waves (sinewave synthesis) I had
better results with square waves (simpler/cheaper, also better results audio-wise). Computational cost for decoding is fairly modest (mostly
some "for()" loops and fixed-point arithmetic).

Though, effective bitrate may be lower, because it seems that speech
encoded this way is often LZ compressible as well (and can be helped
along with pattern matching tricks).

...


But, yeah, generally want images and audio to be fairly compact when
shoving them inside an EXE or DLL, for more general asset data,
generally better to use an external file.

I had often used a custom "WAD4" format here, which is kinda like "WAD2
but with longer names and a directory tree". It then exists as a lower
cost option to the ZIP format (while semi-popular, ZIP is a
high-overhead format to be used this way).

Also can use WAD4 as a sort of VFS packaging.

But, things can be considered in relative terms:
Like, C++ may carry various penalties vs C.

I don't find C++ carries noticeably penalties compared to C, for my
embedded work.ÿ But I do disable exceptions and RTTI - exceptions may
have very little run-time time overhead, but the unwind tables can be significant when code size is important in small systems.

Yes, that is the main thing.
They carry zero performance penalty in practice;
But, have a non-zero penalty for image size.

Not enough to be a deal-breaker towards using them if they are used, but enough that one wants them disabled if not used...



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 20:18, Bart wrote:

On 29/05/2026 17:10, Janis Papanagnou wrote:

On 2026-05-29 13:19, Bart wrote:

Further, here: 'a * b + c' the multplication is done first, but here:

ÿÿÿ aÿ *= b += c

It is done second.

You understand that '=', '*=', and '*' are three different things,
don't you?

I hope you understand that '=' should have low precedence. And that
it makes sense to evaluate that from right to left. Do you follow?

"C" obviously decided to have them all, =, +=, *=, etc. in a single
group, and thus evaluated from right to left. - Easy rule, easy to
memorize. - And that is actually what you are demanding from many
other operators, to put them in a single group. - But here you are
complaining about it!

Of course the rules for those combined (sort of two-address) operators
could have been defined differently, in an own group with other rules.
(Algol 68 had done that, actually; the semantics are like "apply these
operations from left to right, indicating an incremental modification
of the underlying value.)

For those who don't know, the behaviour of this C code:

Those you have read my post already know that, since that was
what I explained as a possible alternative rule for these sorts
of operators. (It's still quoted above.) Folks here are capable
of understanding that without your echoing post.

ÿÿ a += b += c += d

is very different from the equivalent Algol68:

ÿÿ a +:= b +:= c +:= d

This only modifies 'a'.

I explained already in my post that there's a difference. (Are you
so proud of having understood that that you want to repeat it? -
"Look Ma, no hands!")

(And neither is "perfect"; both are sensible choices. - Not sure
you understand that.)

[...]

You seem to like making it 100% about me. How about stopping making it always so personal.

What you expose here (about your personality) is nothing new, and
it's about your personality; you obviously aren't really interested
to know or understand or learn the facts.

You had asked, even insisted for answers to your samples because
you obviously weren't intellectually capable of understanding the
topic, and all you posted is this reply! - Pathetic!

Janis


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 21:57, James Kuyper wrote:

On 2026-05-29 12:10, Janis Papanagnou wrote:

On 2026-05-29 13:19, Bart wrote:

...

* What is the order here: a ^ b | c

(a^b)|c

Personally I don't think that there's a prevalent definition
how these should be ordered.

I'm not sure what you mean by "prevalent definition". Ordinarily, I'd
expect the C standard to qualify - it definitely defines the order, and
the very purpose of a language standard is to prevail over non-standard alternatives. However, I'm sure you're aware of the C standard, and made
that comment anyway, so I presume you mean something different by it.

It was about Bart's confusion; he seems to be looking for something
"naturally" understandable, like the common * and / have precedence
over + and - , which is known by most non-IT people from basic math.

There is no such commonly know ("prevalent") definition for the bit
operations. So we need to look that up in appropriate documents to
get to know their evaluation order. - That was what I intended to
express.

Sorry if that was unclear, and thanks for asking to clarify that.

How "C" defines their precedence can of course be read in any book
about "C", there's not even a "C Standard" document necessary.

In addition I gave an explanation why they decided to have these
operators in three separated precedence groups, and hinted on what
was the rationale for the same order as the boolean && and || .

Janis


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 21:17, Janis Papanagnou wrote:

On 2026-05-29 20:18, Bart wrote:

(Are you
so proud of having understood that that you want to repeat it? -
"Look Ma, no hands!")

What you expose here (about your personality) is nothing new, and
it's about your personality; you obviously aren't really interested
to know or understand or learn the facts.

you obviously weren't intellectually capable of understanding the
topic, and all you posted is this reply!

- Pathetic!

It doesn't look like a civil discussion is possible here, so long as you
keep up the personal insults.

I thank you for those replies but there doesn't seem any point in taking
this further.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bart <bc@freeuk.com> writes:

On 29/05/2026 20:28, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:
or would you continue to post contrived examples that make it appear
as confusing as possible?

Examples are examples. Do you want me to post one that didn't
illustrate an issue? It necessaily has to be contrived.

Bart, what do you want?

Today I was just replying to this post today that I found annoying:

JP:

Unsurprisingly; since exactly *that* was the obvious (and single)
issue with C's precedence definitions.

That is, the suggestion, made several times by JP, that there is only
one thing wrong.

I note your refusal to address most of what I wrote.

Upthread, you asked a question:

And then the point becomes, if you always add the parentheses, what
was the point of having that particular precedence level?

You've made it clear that you were never interested in an answer.

Please do not waste everyone's time by asking questions when you're
not interested in the answers. Please do not assume that anyone
can tell whether one of your questions is sincere, figurative,
or rhetorical.

Bart, what do you want?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 21:00, Janis Papanagnou wrote:

On 2026-05-29 20:09, Bart wrote:

You actually said this:

You continue your trollish stance to cherry-pick words without
understanding or trying to understand what's been expressed.

The insight appears to me that you're taking communication in a
similar way as you "design" your languages; focusing on personal
*syntax* preferences instead of the more important *semantics*.

Despite we're talking in your native language

English is my second language, technically.

(and not mine) you
obvious completely miss or deliberately ignore that there's a
difference between "it makes perfectly sense" and "it's perfect".
(I said the former, you put the latter in my mouth.

It's paraphrasing. Here is your quote again:

(The point is that - with the exception of & ^ | - the ranking
makes perfect[ly] sense and should be easily usable without doubt
by a concept-knowing programmer."

I've isolated the 'ly' as that is incorrect grammar and have ignored it.

I don't know what impression someone can take from this other than you
think it's all dandy apart from that one exception.

So, what am I missing? Did you mean the rest is all fine, considering
this is C, but it is not perfect?

In that case, what /would/ be perfect in your view? Assume a fantasy
language where anything is possible.

ÿ >> What I would say is that operator precedences are in "C"
ÿ >> "sensibly and appropriately defined, modulo the bit-ops".
you're still playing your stupid game; you ignored that. I suggest
to try to map this statement to either of the above two statements,
the one I said and the one you (wrongly) attributed, and see which
one fits. (Hint: the former.)

OK, so why don't you list all the things you think are amiss with C
operator precedences. Apart from that exception.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 21:56, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

On 29/05/2026 20:28, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:
or would you continue to post contrived examples that make it appear
as confusing as possible?

Examples are examples. Do you want me to post one that didn't
illustrate an issue? It necessaily has to be contrived.

Bart, what do you want?

Today I was just replying to this post today that I found annoying:

JP:

Unsurprisingly; since exactly *that* was the obvious (and single)
issue with C's precedence definitions.

That is, the suggestion, made several times by JP, that there is only
one thing wrong.

I note your refusal to address most of what I wrote.

Upthread, you asked a question:

And then the point becomes, if you always add the parentheses, what
was the point of having that particular precedence level?

You've made it clear that you were never interested in an answer.

You said this:

"You're asking why C is designed the way it is. We could waste a
great deal of time and effort answering that for you. There are
numerous documents about the design and history of C, and of
its ancestor languages. I could provide you with links."

Actually I'm not asking why C is like that. We're already there.

I'm saying that there is no value in those extra levels, some people
think is, and I'm arging about that. I was replying to tTh.

As for my question, what /is/ the point? I'm still waiting!

Of course, I want the answer to be that there isn't any point if
parentheses will be used anyway.

Bart, what do you want?

What answer do you want from me? As I said it was a reply to JP. You
didn't need to step it.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bart <bc@freeuk.com> writes:

On 29/05/2026 21:56, Keith Thompson wrote:

[...]

I note your refusal to address most of what I wrote.

Upthread, you asked a question:

And then the point becomes, if you always add the
parentheses, what was the point of having that particular
precedence level?

You've made it clear that you were never interested in an answer.

You said this:

"You're asking why C is designed the way it is. We could waste a
great deal of time and effort answering that for you. There are
numerous documents about the design and history of C, and of
its ancestor languages. I could provide you with links."

Actually I'm not asking why C is like that. We're already there.

Then your question was unclear. The only reasonable interpretation
I could see for your question, quoted above, is that you wanted
to know why Dennis Ritchie chose the specific precedence rules
that he chose when he was designing the C language in the 1970s.
(The precedence rules have been stable since then.)

What did you mean to ask? Was your question meant to be rhetorical?
Did you just mean to let us know that you don't like C's precedence
rules? I think we all knew that.

[...]

As for my question, what /is/ the point? I'm still waiting!

I see that (what *is* the point) as a different question from what
you wrote earlier (what *was* the point).

The rules are what they are.

I honestly don't have any strong opinions about what the rules
*should* be.

Of course, I want the answer to be that there isn't any point if
parentheses will be used anyway.

Parentheses are not always used. Some programmers know the
precedence rules well enough, and expect their readers to know them
well enough, that they don't need to add parentheses. I don't bother
with parentheses in `a = b + c` or `a + b * c`. Others might not
bother with parentheses in more obscure cases where I would use them.

C compilers must implement the rules as specified in the standard.
Future editions of the standard are unlikely to reorder the
precedence rules, since that would quietly break existing code.

C programmers may or may not choose to remember and/or take advantage
of all the precedence rules. I haven't memorized all of them myself.

[snip]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 29 May 2026 12:19:04 +0100, Bart wrote:

* Why do bitwise & | ^ need their own level anyway

So that you can do shifting and masking with minimal parentheses.

* Why do << >> have their own level anyway

So that shift expressions can use common arithmetic operators with
minimal parentheses.

Further, here: 'a * b + c' the multplication is done first, but
here:

a *= b += c

It is done second.

That kind of thing is disallowed in Python, for some reason.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 29 May 2026 08:09:53 +0200, Bonita Montero wrote:

There's no language where the users are so detail focussed and open
to new features [than C++].

But they still don?t have ?try-finally?.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 30/05/2026 00:18, Lawrence D?Oliveiro wrote:

On Fri, 29 May 2026 12:19:04 +0100, Bart wrote:

* Why do bitwise & | ^ need their own level anyway

So that you can do shifting and masking with minimal parentheses.

Can you give examples?

Because you can do 'a << b & c' without << >> needing their own private
level; it only needs to be lower than bitwise ops.

For example they could have the same level as * and / as they
essentially do the same thing.

* Why do << >> have their own level anyway

So that shift expressions can use common arithmetic operators with
minimal parentheses.

Again, examples?

Further, here: 'a * b + c' the multplication is done first, but
here:

a *= b += c

It is done second.

That kind of thing is disallowed in Python, for some reason.

I disallow it too (in my stuff). It's too confusing, no matter that is
100% unambiguous according to some arcane language rules.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-29 18:52, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

...

Of course, I want the answer to be that there isn't any point if
parentheses will be used anyway.

The answer, of course, is that the condition of your "if" clause is not
true. In the overwhelming majority of the cases, people do not use
parentheses to clarify the order of evaluation that is guaranteed by C's grammar rules. They only use them in the cases where they feel that
there's a significant chance of confusion. Of course, that depends upon
your audience. If I was required to write code in such a way that you
would have trouble misunderstanding it, I'd write

a = m*x + b;

as

a = ((m*x)+b);

I internalized C's grammar rules a long time ago (which causes problems
on the rare occasions when they've changed them). The main exception are
the bit-wise operators which are well known as having the wrong
precedence - but I've seldom needed to use those operators.
As a result, I seldom have any confusion as to the order of evaluation,
which makes it very hard for me to realize that it might be a good idea
to put in some redundant parentheses to clarify that order for other
people. That means that some of my code is probably more cryptic than it
should be.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 30/05/2026 01:31, James Kuyper wrote:

On 2026-05-29 18:52, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

...

Of course, I want the answer to be that there isn't any point if
parentheses will be used anyway.

The answer, of course, is that the condition of your "if" clause is not
true. In the overwhelming majority of the cases, people do not use parentheses to clarify the order of evaluation that is guaranteed by C's grammar rules. They only use them in the cases where they feel that
there's a significant chance of confusion.

Those are the cases we're talking about! That is:

<< >> & | ^

Maybe add == != and < <= >= > is someone wants to take advantage of
their different levels, but I guess 99% wouldn't even know about what.

Most of the rest, there tends to be agreement across languages:

school arithmetic group - comparisons - logical and/or

I haven't included ?: as that's too weird.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bart <bc@freeuk.com> writes:

On 30/05/2026 01:31, James Kuyper wrote:

On 2026-05-29 18:52, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

...

Of course, I want the answer to be that there isn't any point if
parentheses will be used anyway.

The answer, of course, is that the condition of your "if" clause is
not true. In the overwhelming majority of the cases, people do not
use parentheses to clarify the order of evaluation that is guaranteed
by C's grammar rules. They only use them in the cases where they feel
that there's a significant chance of confusion.

Those are the cases we're talking about! That is:

<< >> & | ^

Maybe add == != and < <= >= > is someone wants to take advantage of
their different levels, but I guess 99% wouldn't even know about what.

Most of the rest, there tends to be agreement across languages:

school arithmetic group - comparisons - logical and/or

I haven't included ?: as that's too weird.

So what is your question? I had thought that you meant to ask why
Ritchie defined the precedences that way, but apparently that's
not what you meant.

Do you even have a question? Is there anything anyone could tell
you that you don't think you already know?

If you have a question, can you restate it in unambiguous terms?
If not, what are we talking about?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 29 May 2026 05:20:20 -0500, BGB wrote:

To be excluded from being syntactic sugar, it needs to be something
that is not generally possible to express within the base language.

So, for example: Things like operator overloading or classes are
syntactic sugar IMO, as what they do can be expressed in C, even if
a lot less pretty (or far from an idiomatic style).

I would not consider exceptions or RTTI as syntactic sugar, because
these involve things that do not map to native C.

But surely *anything* that ?is not generally possible to express
within the base language? woud ?not map to native C?.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 30 May 2026 01:26:47 +0100, Bart wrote:

On 30/05/2026 00:18, Lawrence D?Oliveiro wrote:

On Fri, 29 May 2026 12:19:04 +0100, Bart wrote:

* Why do bitwise & | ^ need their own level anyway

So that you can do shifting and masking with minimal parentheses.

Can you give examples?

You haven?t done much bit manipulation, have you?

Extracting RGB components from a pixel:

const unsigned int
r = pixel >> 16 & 255,
g = pixel >> 8 & 255,
b = pixel & 255;

Combining RGBA components into a pixel:

colors[i] =
channel[0] << 24
|
channel[1] << 16
|
channel[2] << 8
|
channel[3];

* Why do << >> have their own level anyway

So that shift expressions can use common arithmetic operators with
minimal parentheses.

Again, examples?

From the same code module, putting together a subpicture image
consisting of 2 bits per pixel:

pixbuf[bufpixels / 4] |= histogram[histindex].index << bufpixels % 4 * 2;

<https://bitbucket.org/ldo17/dvd_menu_animator/src/master/spuhelper.c>

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/29/2026 7:58 AM, Bonita Montero wrote:

Am 29.05.2026 um 11:15 schrieb BGB:

Like, if one doesn't care that the compiler takes a long time to run
and the EXE is needlessly large, maybe OK, not great if one does care...

Binary size doesn't matter with Windows.

On a typical modern desktop PC...

Does still get annoying if it is needlessly large for no good reason.

Even if, yeah, modern PC will not care much about loading a 50 or 100MB
EXE file...

Having to spend minutes or more waiting for the compiler would
seriously hurt momentum for many tasks.

Use C++20 modules and parallel builds.

Possibly, I have my reasons, and not all of my current development is
limited to PC class systems.

Say, for example, if the Boot ROM requires keeping everything under 32K.

C++ was designed for large scale program development.
With 32K-systems you can stick with C.

There are intermediate options, where ones' RAM is measured in MB.


Or, basically, say imagine writing software on something where CPU
speeds and RAM sizes are basically similar to what things were like in
the 1990s.

Comparably, a desktop PC is much faster, and with almost limitless RAM.


Well, and one thing I am often messing with:
Well, I am using a PE/COFF variant...
But, the OS is not on Windows, and the ISA is not x86 based, ...
Still has EXE's and DLL's though.

Can't use C++ there, because no (native) C++ compiler exists.
Well, except if using GCC to generate RV64G; can run RV64G on it;
But, RV64G's performance is lacking, and the ELF files are bloated.
Kinda sucks when a significant part of the binary is just metadata.


Then again, the PE variant is non-standard:
No MZ stub;
LZ4 compression;
Mostly using 64-byte section alignment;
And a FileOffset==RVA constraint, ...
Various structures have been tweaked;
...


Well, and the format is itself an offshoot of a WinCE variant of the
format rather than from mainline Windows. Well, imagine an OS that sort
of took design inspiration both from WinCE and the Unix family OS's.

And ended up with a CLI experience kinda similar to Cygwin. And a very
crap attempt at making a GUI (that mostly just launches with a terminal
window that can be used to start other programs).


Well, a basic view of my crappy GUI can be seen here: https://www.youtube.com/watch?v=HAyMDRzxYzY

Though, the point of this video was more Doom but with the musical notes replaced with DTMF-like tones (but still having octaves and similar so
it at least sorta sounds like music). As sort of a bit of hackery with
the MIDI playback code (tweaking out the FM synthesis to to play DTMF
tones rather than the normal FM instruments).

Well, that and another recent-ish video of Doom modified to sorta
resemble the monochrome style of "Return of the Obra Dinn" (well, and
also this Doom port also has a 3D glasses mod, and 3D+Obra which
actually works pretty OK, ...).

...



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Am 30.05.2026 um 01:20 schrieb Lawrence D?Oliveiro:

But they still don?t have ?try-finally?.

There's RAII:

#pragma once
#include <utility>
#include <concepts>
#include "nui.hpp"

template<std::invocable Fn>
struct defer final
{
defer( Fn &&fn, bool enabled = true ) :
m_fn( std::forward<Fn>( fn ) ),
m_enabled( enabled )
{
}
defer( defer const & ) = delete;
void operator =( defer const & ) = delete;
~defer() noexcept( std::is_nothrow_invocable_v<Fn> )
{
if( m_enabled ) [[likely]]
m_fn();
}
template<typename ... Fns>
bool operator ()( defer<Fns> &... additional ) noexcept( std::is_nothrow_invocable_v<Fn> && (std::is_nothrow_invocable_v<Fns> &&
...) )
{
if( !m_enabled ) [[unlikely]]
return false;
m_enabled = false;
m_fn();
return (additional() && ...);
}
template<typename ... Fns>
void disable( defer<Fns> &... additional ) noexcept
{
m_enabled = false;
(additional.disable(), ...);
}
template<typename ... Fns>
void enable( defer<Fns> &... additional ) noexcept
{
m_enabled = true;
(additional.enable(), ...);
}
private:
NO_UNIQUE_ADDRESS Fn m_fn;
bool m_enabled;
};

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 30/05/2026 05:25, Lawrence D?Oliveiro wrote:

On Sat, 30 May 2026 01:26:47 +0100, Bart wrote:

On 30/05/2026 00:18, Lawrence D?Oliveiro wrote:

On Fri, 29 May 2026 12:19:04 +0100, Bart wrote:

* Why do bitwise & | ^ need their own level anyway

So that you can do shifting and masking with minimal parentheses.

Can you give examples?

You haven?t done much bit manipulation, have you?

Extracting RGB components from a pixel:

const unsigned int
r = pixel >> 16 & 255,
g = pixel >> 8 & 255,
b = pixel & 255;

This merely requires <<'s precendence to be lower than &.

It doesn't need & | ^ to be distinct (only one is used here anyway).

It doesn't beed << >> to be in a distinct group from multiply or add groups.

Combining RGBA components into a pixel:

colors[i] =
channel[0] << 24
|
channel[1] << 16
|
channel[2] << 8
|
channel[3];

Exactly the same applies here. But if one of those | was & or ^, then
you might start needing parentheses.

* Why do << >> have their own level anyway

So that shift expressions can use common arithmetic operators with
minimal parentheses.

Again, examples?

From the same code module, putting together a subpicture image
consisting of 2 bits per pixel:

pixbuf[bufpixels / 4] |= histogram[histindex].index << bufpixels
% 4 * 2;

This is a better example, as is this from your link:

pixbuf[nr_buf_pixels] = colors[srcpix >> src_pix_index * 2 & 3];

This can indeed be written with fewer parentheses given the priority of
<< relative to * and &.

But it is also not clear because the part after >> is sprawling. You'd
want it like this:

pixbuf[nr_buf_pixels] = colors[srcpix >> (src_pix_index * 2) & 3];

Now there is less analysis to do to establish the span of the shift-count.

These are examples from MZLIB:

crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b >> 4)];

C's precedence rules say that many of those parentheses are not strictly needed, which means the following are exactly equivalent:

crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF];
crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b >> 4];

So why were they added? Could it be that they make things clearer?

Remove ambiguity in the mind of the reader? Leader to fewer surprises
when a new term needs to be added?

With the original, NOBODY NEEDS TO CARE what the hell the precedences of

^ & with respect to each other. Port the fragment to a language with slightly different rules and it it would still work.

Post that fragment somewhere, and people will know what it means
*without needing to know which exact language it is*.

This is why I think it is pointless to devote 4 dedicated levels to <<

& | ^, and poor to rely on them for the meaning of your code.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 30/05/2026 03:02, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

On 30/05/2026 01:31, James Kuyper wrote:

On 2026-05-29 18:52, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

...

Of course, I want the answer to be that there isn't any point if
parentheses will be used anyway.

The answer, of course, is that the condition of your "if" clause is
not true. In the overwhelming majority of the cases, people do not
use parentheses to clarify the order of evaluation that is guaranteed
by C's grammar rules. They only use them in the cases where they feel
that there's a significant chance of confusion.

Those are the cases we're talking about! That is:

<< >> & | ^

Maybe add == != and < <= >= > is someone wants to take advantage of
their different levels, but I guess 99% wouldn't even know about what.

Most of the rest, there tends to be agreement across languages:

school arithmetic group - comparisons - logical and/or

I haven't included ?: as that's too weird.

So what is your question? I had thought that you meant to ask why
Ritchie defined the precedences that way, but apparently that's
not what you meant.

You seem to have a problem with context. I was replying to JK who was
replying to a quote of mine from within one of your posts (maybe he's killfiled me so couldn't respond directly).

There was no question posted. He suggested that most of the time,
parentheses are not used and gave examples using * and +.

My original remarks were about the widespread use of parentheses to
clarify the grouping of operators with the more obscure priorities, and
my reply addressed that.

See also the examples I posted a few minutes ago involving >> & and ^.

That is, if you are interested in my point, which I doubt. You seem more intent on some personal campaign.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 22:16, BGB wrote:

On 5/29/2026 6:22 AM, David Brown wrote:

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

On 2026-05-28 11:57, BGB wrote:

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

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.

Possibly, a lot could depend on how one is counting things as well.


In a lot of cases when using GCC, I end up using:
ÿÿ -ffunction-sections -fdata-sections -Wl,-gc-sections

On many targets, "-fdata-sections" can lead to noticeably larger and
slower code because it effectively eliminates section anchor
optimisations.ÿ It does not negatively affect x86 AFAICS, because x86
does not use section anchors.

<https://godbolt.org/z/zeoq41Y7d>

With -fsection-anchors (enabled with optimisation on targets that
support it - generally RISCy load/store architectures), program-
lifetime variables are kept together in a lump (as though they were in
a struct) and often addressed by a pointer to that pretend struct.
Thus if a function accesses two variables "a" and "b", instead of
having to load the addresses of each of "a" and "b" into separate
registers, it loads an "anchor" into one register and accesses the
variables with reg+offset addressing.

I've seen "-fdata-sections" used regularly in embedded systems - it is
almost always a bad idea.

("-ffunction-sections" is often very helpful to reduce code image
size, so keep that one.)

Both seem to help on x86, x86-64, and also on RISC-V, at making GCC's
output at least sorta space-comparable to my own compilers.

The merit of "-fdata-sections" is mostly that it eliminates unused
global variables; whereas "-ffunction-sections" eliminates unreachable functions.

That is the point of them, yes. "-ffunction-sections" can be useful at removing unused code from more general code. For microcontrollers,
SDK's and manufacturers' driver code will normally contain a large
number of functions that can be eliminated in this way, saving a lot of
code space.

However, in practice, "-fdata-sections" rarely eliminates a significant
amount - most programs do not have large amounts of statically-allocated
data that is not used. Gcc, and I think most other compilers, put the
static lifetime data for each translation unit in its own section, so if
no data from a translation unit is used it will be eliminated at link
time even with -fno-data-sections. And of course it makes no difference
for heap data or stack data.

In my testing, "-ffunction-sections" is absolutely worth using (on
targets where code space is relevant - there's no need for PC software).
On some targets, it may mean a few lost opportunities for shorter
jump/call instructions between functions in the same translation unit,
but the cost is rarely anything more than a slightly longer link time.
But "-fdata-sections" typically gives almost no ram space savings, and
makes code bigger and slower.

As I noted, gcc on x86 does not support section anchors, so there is not likely to be much code cost for -ffdata-sections.

Where section anchors shine - and where -fdata-sections therefore has
cost - is when a function needs to access more than one piece of static lifetime data defined in the same translation unit (or another
translation unit if you are using LTO). That happens a lot in embedded
ARM programming at least. I don't know about RISC-V. If the target
normally uses a "small data section" for ram (I know this is common on PowerPC), then there is, in effect, a program-wide section anchor
already. So it is possible that it relatively few targets have section anchors - but the 32-bit ARM on gcc is a vastly popular choice in the
embedded world, so it is important to understand the cost of this
compiler flag for that target at least.

Neither is needed with my own compiler, which compiles things in a way
such that it eliminates anything that is unreachable.

[...]

That might be the case for a very simplistic compiler.ÿ With an
optimising compiler, these extra variables will quickly be eliminated.
If the compiler has a good scheduling model of the device, it do
whatever instruction scheduling works best for that processor.ÿ If the
model is not good enough, it will be suboptimal.ÿ I would not,
however, expect any different in the generated code for the two code
snippets.

Sometimes this kind of "manual optimisation" is helpful when you have
to try to get efficient results from a weak compiler, however.

Possibly, but this sort of thing can help with both BGBCC and with MSVC
IME

I don't tend to think of MSVC as a highly optimising compiler - but it
is not a tool I have much use for, as it does not handle the targets I
need. When I have sometimes looked at the generated code on godbolt, it
has not impressed me at all. So it could well fall into the "helpful
when using a weaker compiler" category.

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.

We avoided macros if possible.

They are de-facto for constants and similar, but for longer stuff is
better avoided.

Macros are rarely the best way to define constants.ÿ They are needed
if you are using the constants for pre-processor stuff like
conditional compilation.ÿ But generally you get clearer code, better
typing, and potentially several other benefits from using alternative
choices like "enum" (even for stand-alone integer constants), "static
const" variables, and in C23, "constexpr" variables.ÿ There's no doubt
that a lot of code /does/ use macros for constants, but I view it as a
relic of the past rather than good coding practice.

They are traditional...

Like:
ÿ static const double M_PI = 3.14159265358979;

Could also make sense, but people don't do usually this, they usually
use macros...

They should not do so (IMHO, of course). Yes, macros are traditional -
but there are no plus sides to using them for this kind of thing.
(There are no plus sides to using all-caps either, but people do that too.)

(I'm snipping all the details of your own C compiler, because there is
very little I can comment on.)

But, things can be considered in relative terms:
Like, C++ may carry various penalties vs C.

I don't find C++ carries noticeably penalties compared to C, for my
embedded work.ÿ But I do disable exceptions and RTTI - exceptions may
have very little run-time time overhead, but the unwind tables can be
significant when code size is important in small systems.

Yes, that is the main thing.
ÿ They carry zero performance penalty in practice;
ÿ But, have a non-zero penalty for image size.

Not enough to be a deal-breaker towards using them if they are used, but enough that one wants them disabled if not used...

Agreed.

(I could also note that I make heavy use of templates in C++ code - it
often leads to smaller and faster results.)





--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 29/05/2026 19:53, Bart wrote:

On 29/05/2026 18:29, tTh wrote:

On 5/29/26 15:22, Bart wrote:

Something you might do when you have time (as I'm busy), is to
analyse the expressions in some C codebases, and isolate those where
removal of parentheses that group terms, would result in exactly the
same shape of expressions, and are therefore redundant.

ÿÿÿ This is a strange exercice. When I write complex expression,
ÿÿÿ I sometime use redondant parenthesis for the clarity of
ÿÿÿ my intentions about this computation. I'm thinking that
ÿÿÿ those extra (()) are a sort of in-line comments.

Sure, but some here like to say that such expressions, if they still
work without parentheses, are unambiguous anyway.

They are obviously unambiguous to compilers, and they are unambiguous to people who either know the precedence rules, or are able to look them up
to be sure of them at the time. For those that don't know the rules and
would rather guess randomly, they might misinterpret the expressions but
the expressions themselves are still unambiguous. So yes, complex
expressions without parentheses /are/ unambiguous.

However, being unambiguous does not mean people will not make mistakes
when reading or writing them, or that they can read and write them
correctly without effort. As you say, people are not compilers.

Parentheses can certainly reduce the cognitive effort for people reading
or writing complex expressions, and can significantly reduce the risk of errors. Extra local variables for sub-expressions can do this too
(especially when the language has good scoping rules and allows
variables to be declared when you need them).

So it is wrong to suggest that expressions written in C without extra parentheses are somehow "ambiguous" - but it is correct to say that
adding extra parentheses (within reason) can often help the readability
of code.

And this applies equally in all languages, no matter what precedence the operators have, or how many levels there are. I can certainly agree
with you that C would have been slightly nicer if the bitwise operators
and equality operators were at different precedences. There are a
number of changes I would have preferred - some of which you would agree
with, some not. But even if C were to have those changes overnight, it
would not change anything about what I wrote above. Regardless of the operator precedence, expressions are not ambiguous, but parentheses or splitting into sub-expressions can make code clearer.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <10vd1tu$ekvl$1@dont-email.me>, Bart <bc@freeuk.com> wrote:

On 29/05/2026 21:56, Keith Thompson wrote:

[snip]
Upthread, you asked a question:

And then the point becomes, if you always add the parentheses, what
was the point of having that particular precedence level?

You've made it clear that you were never interested in an answer.

You said this:

"You're asking why C is designed the way it is. We could waste a
great deal of time and effort answering that for you. There are
numerous documents about the design and history of C, and of
its ancestor languages. I could provide you with links."

Actually I'm not asking why C is like that. We're already there.

I'm saying that there is no value in those extra levels, some people
think is, and I'm arging about that. I was replying to tTh.

As for my question, what /is/ the point? I'm still waiting!

To clarify: the question is, what is the point of those levels?

How is that different from asking "why C is like that"?

Of course, I want the answer to be that there isn't any point if
parentheses will be used anyway.

There is a point, but it is history. That is, the "point" is of
those precedence levels is the history and evolution of the
language.

In PL/1 and early C, `|` and `&` were logical operators. The
short-circuiting `||` and `&&` came later, but the usage low
precedence for `|` and `&` was already baked in.

That's the point: the precedence reflects the original use as
boolean operators, not how things evolved for use almost purely
as bitwise operators.

- Dan C.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-30 13:52, David Brown wrote:

On 29/05/2026 22:16, BGB wrote:

On 5/29/2026 6:22 AM, David Brown wrote:

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

We avoided macros if possible.

They are de-facto for constants and similar, but for longer stuff is
better avoided.

Macros are rarely the best way to define constants.ÿ They are needed
if you are using the constants for pre-processor stuff like
conditional compilation.ÿ But generally you get clearer code, better
typing, and potentially several other benefits from using alternative
choices like "enum" (even for stand-alone integer constants), "static
const" variables, and in C23, "constexpr" variables.ÿ There's no
doubt that a lot of code /does/ use macros for constants, but I view
it as a relic of the past rather than good coding practice.

They are traditional...

Like:
ÿÿ static const double M_PI = 3.14159265358979;

Could also make sense, but people don't do usually this, they usually
use macros...

They should not do so (IMHO, of course).ÿ Yes, macros are traditional -
but there are no plus sides to using them for this kind of thing. (There
are no plus sides to using all-caps either, but people do that too.)

Because in early days Cpp constants have been used and Cpp-stuff often capitalized[*]. Our C++ coding rules back then had mandated lowercase
also for constants, but strangely some folks were so used to uppercase
Cpp literals that they disliked to write constants (as other objects)
in lowercase, and stated opinions were sometimes heated like religious
topics.

I wonder what lexical convention regular "C" (or C++) programmers here
use for constants nowadays.

Curiously I inspected my latest C-source to see what convention I've
actually followed recently. But I noticed that I had no hard constants
used at all; all parameters came from a configuration file and through
the command line interface. (That makes sense, I guess.)

Janis

[*] Strangely there were C-function-macros that were written lowercase,
though.

[...]

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 30/05/2026 13:29, Dan Cross wrote:

In article <10vd1tu$ekvl$1@dont-email.me>, Bart <bc@freeuk.com> wrote:

On 29/05/2026 21:56, Keith Thompson wrote:

[snip]
Upthread, you asked a question:

And then the point becomes, if you always add the parentheses, what >>> was the point of having that particular precedence level?

You've made it clear that you were never interested in an answer.

You said this:

"You're asking why C is designed the way it is. We could waste a
great deal of time and effort answering that for you. There are
numerous documents about the design and history of C, and of
its ancestor languages. I could provide you with links."

Actually I'm not asking why C is like that. We're already there.

I'm saying that there is no value in those extra levels, some people
think is, and I'm arging about that. I was replying to tTh.

As for my question, what /is/ the point? I'm still waiting!

To clarify: the question is, what is the point of those levels?

How is that different from asking "why C is like that"?

My question is actually independent of C or its history.

I accept those levels exist. I was asking do they currently serve a
useful purpose.

If not, people can choose to ignore those them when writing C code, for example like this where all () are technically superfluous:

crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];

And they can choose to not adopt them when devising new languages,
however many still do faithfully recreate the same pattern, with a few
notable exceptions such as Go lang.





--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 30/05/2026 14:40, Janis Papanagnou wrote:

On 2026-05-30 13:52, David Brown wrote:

On 29/05/2026 22:16, BGB wrote:

On 5/29/2026 6:22 AM, David Brown wrote:

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

We avoided macros if possible.

They are de-facto for constants and similar, but for longer stuff
is better avoided.

Macros are rarely the best way to define constants.ÿ They are needed
if you are using the constants for pre-processor stuff like
conditional compilation.ÿ But generally you get clearer code, better
typing, and potentially several other benefits from using
alternative choices like "enum" (even for stand-alone integer
constants), "static const" variables, and in C23, "constexpr"
variables.ÿ There's no doubt that a lot of code /does/ use macros
for constants, but I view it as a relic of the past rather than good
coding practice.

They are traditional...

Like:
ÿÿ static const double M_PI = 3.14159265358979;

Could also make sense, but people don't do usually this, they usually
use macros...

They should not do so (IMHO, of course).ÿ Yes, macros are traditional
- but there are no plus sides to using them for this kind of thing.
(There are no plus sides to using all-caps either, but people do that
too.)

Because in early days Cpp constants have been used and Cpp-stuff often capitalized[*]. Our C++ coding rules back then had mandated lowercase
also for constants, but strangely some folks were so used to uppercase
Cpp literals that they disliked to write constants (as other objects)
in lowercase, and stated opinions were sometimes heated like religious topics.

I wonder what lexical convention regular "C" (or C++) programmers here
use for constants nowadays.

Curiously I inspected my latest C-source to see what convention I've
actually followed recently. But I noticed that I had no hard constants
used at all; all parameters came from a configuration file and through
the command line interface. (That makes sense, I guess.)

Janis

[*] Strangely there were C-function-macros that were written lowercase, though.

I think there is a reasonable case for all-caps for macros that are
doing something "weird", as a warning to users. You know that it's
risky trying to write "MAX(a++, b++)", as it might evaluate one or both
of the parameter expressions twice. But if you also use all-caps for well-behaved macros, that dilutes the warning effect.

I use all-caps for define names that I expect to come from outside the
source files - like a command line flag "-DPROG_VARIANT=2" in a
makefile, and that kind of thing. That, to me, counts as a "weird" macro.

I am happy to use macros where they make sense, but I would not use a
macro if a static const, enum, static inline function, or constexpr
variable will do just as well.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 5/30/2026 6:52 AM, David Brown wrote:

On 29/05/2026 22:16, BGB wrote:

On 5/29/2026 6:22 AM, David Brown wrote:

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

On 2026-05-28 11:57, BGB wrote:

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

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.

Possibly, a lot could depend on how one is counting things as well.


In a lot of cases when using GCC, I end up using:
ÿÿ -ffunction-sections -fdata-sections -Wl,-gc-sections

On many targets, "-fdata-sections" can lead to noticeably larger and
slower code because it effectively eliminates section anchor
optimisations.ÿ It does not negatively affect x86 AFAICS, because x86
does not use section anchors.

<https://godbolt.org/z/zeoq41Y7d>

With -fsection-anchors (enabled with optimisation on targets that
support it - generally RISCy load/store architectures), program-
lifetime variables are kept together in a lump (as though they were
in a struct) and often addressed by a pointer to that pretend struct.
Thus if a function accesses two variables "a" and "b", instead of
having to load the addresses of each of "a" and "b" into separate
registers, it loads an "anchor" into one register and accesses the
variables with reg+offset addressing.

I've seen "-fdata-sections" used regularly in embedded systems - it
is almost always a bad idea.

("-ffunction-sections" is often very helpful to reduce code image
size, so keep that one.)

Both seem to help on x86, x86-64, and also on RISC-V, at making GCC's
output at least sorta space-comparable to my own compilers.

The merit of "-fdata-sections" is mostly that it eliminates unused
global variables; whereas "-ffunction-sections" eliminates unreachable
functions.

That is the point of them, yes.ÿ "-ffunction-sections" can be useful at removing unused code from more general code.ÿ For microcontrollers,
SDK's and manufacturers' driver code will normally contain a large
number of functions that can be eliminated in this way, saving a lot of
code space.

However, in practice, "-fdata-sections" rarely eliminates a significant amount - most programs do not have large amounts of statically-allocated data that is not used.ÿ Gcc, and I think most other compilers, put the static lifetime data for each translation unit in its own section, so if
no data from a translation unit is used it will be eliminated at link
time even with -fno-data-sections.ÿ And of course it makes no difference
for heap data or stack data.

The main place it makes a difference is global arrays from a translation
unit that is included, but for functions that are not included.

Also functions with large static arrays.


void SomeFunc()
{
static char buf[4096];
...
}

Where, say, eliminating SomeFunc does not necessarily eliminate buf.

In my testing, "-ffunction-sections" is absolutely worth using (on
targets where code space is relevant - there's no need for PC software).
ÿOn some targets, it may mean a few lost opportunities for shorter jump/call instructions between functions in the same translation unit,
but the cost is rarely anything more than a slightly longer link time.
But "-fdata-sections" typically gives almost no ram space savings, and
makes code bigger and slower.

As I noted, gcc on x86 does not support section anchors, so there is not likely to be much code cost for -ffdata-sections.

Where section anchors shine - and where -fdata-sections therefore has
cost - is when a function needs to access more than one piece of static lifetime data defined in the same translation unit (or another
translation unit if you are using LTO).ÿ That happens a lot in embedded
ARM programming at least.ÿ I don't know about RISC-V.ÿ If the target normally uses a "small data section" for ram (I know this is common on PowerPC), then there is, in effect, a program-wide section anchor
already.ÿ So it is possible that it relatively few targets have section anchors - but the 32-bit ARM on gcc is a vastly popular choice in the embedded world, so it is important to understand the cost of this
compiler flag for that target at least.

It depends on the way it is built.


A lot of times though (for non-relocatable static-linked binaries) it
mostly tends to use AUIPC+LD or AUIPC+ST pairs to access global
variables. There is a Global Pointer that needs to be loaded when the
binary is started, unclear what it is used for exactly.


in PIC/PIE binaries, it uses AUIPC+ADDI to get a GOT pointer and then
uses the GOT pointers to access global variables (via fetching the
address of the variable from the GOT).


Can note that BGBCC targeting RV works differently, instead using GP to
access global variables, and clustering the commonly accessed global
variables around GP (GP is initialized to point towards at the start of
the ".data" section for the main EXE at program startup, though in my
ABI this may actually be a copy allocated elsewhere in RAM, and not
actually pointing at the version of the section located in the original
PE image; note that the loader also applies base relocs for the data
section separately when locating it; in effect the base relocs being internally partitioned per-section, rather than the per-page
partitioning scheme used in the original PE/COFF).


For my target, I mostly end up needing to use PIE binaries with GCC, as
it needs to be able to load the binary at different locations.

However, I am using a custom C library, as I (still) haven't managed to
get the "ld-linux.so" stuff working. Not yet figured out whatever poorly-documented arcane dark magic is needed to get this part working.


As noted, my compiler's output (including for plain RISC-V) using
PE/COFF, which was also the native format for the OS.


Note that for Linux binaries in this case it would mimics the Linux
syscall interface; though as I hadn't gotten very far with the PIE
loader, most of the syscalls are still not implemented.


My own makeshift OS has a different syscall mechanism, ironically using
the same registers, but a syscall number of -1 (Linux uses positive
syscall numbers).

They work in different ways, IIRC:
X10..X15: Arg1..Arg6
X16: Unused, 0
X17: Syscall Number (always positive)

In my case, syscalls took a different form, IIRC:
X10: Object ID (Handle)
X11: Method Number (Integer)
X12: Method Args List (Pointer)
X13: Return Value (Pointer)
X14..X16: Unused, 0 (RV)
X17: Holds -1 (RV).

In this case, system calls and many OS APIs take the form of object
method calls, with a special range of low-numbered object IDs (Eg, 0 or
NULL) mapping to core/basic syscalls.


But, yeah, some OS APIs would take the form of objects which would be
wrapped in a VTable struct, say:
SomeApi_Vt **api;
(*Api)->ApiMethod(api, arg1, arg2);

In this case, well, there were two major ways of requesting APIs:
Pairs of EIGHTCC values, for some public APIs
Or as FOURCC's for shorthand (zero padded to 64 bits).
As a UUID / GUID:
Primarily used for local / private interfaces.


Well, people probably can't guess where this mechanism originally came
from...


Well, not exactly the same as the inspiration, as there is no IDL
compiler involved, mostly just bare C structs representing the VTables.
There is essentially a blob of generic reusable method-wrappers (and a
whole generic reusable VTable) that is shared across many of these
objects, so calling a method on an object then just sorta translates it
into the corresponding system call to invoke that method slot.

Well, and this mechanism being part of why (for RV) I stuck with an ABI variant that passes everything in X registers (separate X and F
registers would make a big ugly mess for this whenever a method has a floating-point argument).

Neither is needed with my own compiler, which compiles things in a way
such that it eliminates anything that is unreachable.

[...]

That might be the case for a very simplistic compiler.ÿ With an
optimising compiler, these extra variables will quickly be
eliminated. If the compiler has a good scheduling model of the
device, it do whatever instruction scheduling works best for that
processor.ÿ If the model is not good enough, it will be suboptimal.
I would not, however, expect any different in the generated code for
the two code snippets.

Sometimes this kind of "manual optimisation" is helpful when you have
to try to get efficient results from a weak compiler, however.

Possibly, but this sort of thing can help with both BGBCC and with
MSVC IME

I don't tend to think of MSVC as a highly optimising compiler - but it
is not a tool I have much use for, as it does not handle the targets I
need.ÿ When I have sometimes looked at the generated code on godbolt, it
has not impressed me at all.ÿ So it could well fall into the "helpful
when using a weaker compiler" category.

Depends on what target I am building for:
Windows Native: Typically MSVC
WSL: Usually GCC or Clang
Seems to have: GCC 13.2.0; Clang 18.1.3
RISC-V GCC: Also 13.2.0 (also via WSL)
Linux: Typically GCC

I rarely much use Cygwin anymore, as it was mostly rendered obsolete by
WSL (on Win10 or similar).
Though, Cygwin may still be relevant on Win7 or WinXP systems.

For BGBCC, it can build both on native Windows and on Linux/WSL (though recently noted that this build was broken, mostly by GCC and Clang being
more pedantic about missing prototypes, and a few prototypes were being
missed by my function-prototype mining tool). Went and fixed this, but
haven't posted this yet.


As for optimizing in MSVC, yeah, it is in the area of not terrible, but
not super clever either.

If one expects the sort of high-level code-rewriting cleverness that GCC
or Clang often does, one will be disappointed.

But, sometimes, the main "heavy hitter" optimizations are things like constant-folding and register allocation, which it does do effectively.

Though, both MSVC and BGBCC seem to use one sort of strategy for
register allocation:


Static assign things to callee-save registers and use remaining
registers for dynamic allocation within basic-blocks. Variables with
finite non-overlapping lifetimes (that do not cross basic-block
boundaries) may potentially share a register (this more generally
applies to things like temporaries).

And, GCC and Clang use another: Assign dynamically but carry values
across basic-block boundaries along control-flow paths.

Both tend to give different patterns though, and seem to favor different
types of code.

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.

We avoided macros if possible.

They are de-facto for constants and similar, but for longer stuff is
better avoided.

Macros are rarely the best way to define constants.ÿ They are needed
if you are using the constants for pre-processor stuff like
conditional compilation.ÿ But generally you get clearer code, better
typing, and potentially several other benefits from using alternative
choices like "enum" (even for stand-alone integer constants), "static
const" variables, and in C23, "constexpr" variables.ÿ There's no
doubt that a lot of code /does/ use macros for constants, but I view
it as a relic of the past rather than good coding practice.

They are traditional...

Like:
ÿÿ static const double M_PI = 3.14159265358979;

Could also make sense, but people don't do usually this, they usually
use macros...

They should not do so (IMHO, of course).ÿ Yes, macros are traditional -
but there are no plus sides to using them for this kind of thing. (There
are no plus sides to using all-caps either, but people do that too.)

It is more tradition...

My conventions, as noted, are sorta like:
Macros / Constants: All caps;
Functions:
LIBNAME_SysSys_FirstLetterCaps //externally callable within LIBNAME
libname_subsys_nocaps //usually private to a subsystem
LIBNAME_FirstLetterCaps //main API for a private library
somefunction //C library convention
libname_somefunction //some OS API stuff
libFirstLetterCaps //GL-like, common for public APIs
FirstLetterCaps //was common in Win32 API, unused
Conventions are looser for standalone programs, but:
somename, some_name, ... //small programs
S_SomeFunc //id Software like, letter for major subsystem


In my own makeshift OS, had used OpenGL like naming for a lot of OS APIs.
tkWhatever //TestKern OS APIs
tkgdiWhatever //TKGDI: Basically Graphics/GUI stuff


As noted, some amount of these are implemented as object wrappers.
Likewise for my OpenGL implementation.

Though, OpenGL is more annoying in that it usually works via a "GetProcAddress()" type mechanism, so you need to fetch each function
pointer internally (and provide a lookup mechanism for each function).
Where, the main (static linked) part of the GL API is effectively
wrapper functions over function pointers gained via said
"GetProcAddress()" mechanism, which then go into the userland
implementation of those functions (typically, with part of the GL API
running in userland, and a backend part that runs "elsewhere", such as
in the GUI process, and is reached over an Object / COM interface).


FWIW, I didn't design this part of the GL API, but if I had, probably
would have just used COM objects internally.

Still better IMO to provide a nice C API wrapper over said COM objects
though, rather than go the DirectX route and be like "Hey, application
code, have fun with these here bare COM objects!".


Exposing bare COM objects and GUIDs in a public API is poor design IMO.

Well, even if in effect many of the API calls are just:
void apiDoSomething()
{ (*someapi_context)->DoSomething(someapi_context); }


This differs some from Linux APIs, which often like sharing bare
functions and variables across API boundaries (so, no real wall of
separation between the library and application in this sense).


These partly runs into an issue in that in my case, BGBCC (like MSVC)
requires being explicit about DLL imports and exports, and sharing
global variables across DLL boundaries is generally discouraged.

Note that the DLL mechanism doesn't actually support sharing global
variables directly, so if you try to share a global across a DLL
boundary, what you actually get is a hidden function-call that returns a pointer to the variable.

__declspec(dllimport) int somevar; //not actually a variable.

x=somevar;
Is more like:
x=*(int *)(__get_somevar());

But, generally discouraged.


Sharing variables across DLLs is bad practice IMO, and ideally only
sharing functions that represent a public API (and not, "whatever random
stuff happens to be in the library"). Contrast to the Linux "shared
object" approach which does tend to take more of a "share everything" approach, and libraries tend to not maintain as string of a library/application separation.

Well, and then Cygwin goes and tries to fake Linux behavior on top of
DLLs (in which case a large library can also find itself running into
the hard limit on the maximum number of DLL exports).

...


Can note that I had approached C library linking in a different way from MSVC/Windows:
Windows:
Main EXE and every DLL get their own static-linked C library.
Can opt into a shared DLL for the C library, but this adds wonk.
BGBCC+TestKern:
Main EXE gets a static-linked C library;
Exports a COM interface that DLLs can use;
DLLs get a static linked C-library stub;
Invokes main C library via a hidden COM interface.


This basically allows things like malloc/free and stdio to work across
DLL boundaries (unlike Windows where each gets their own local heap and
stdio, and trying to invoke a pointer from one DLL in another tends to
cause stuff to explode).

Granted, the DLLs effectively pulling the C library from the main EXE
via COM objects may seem a little unorthodox, but it seemed like the
best way to address my use cases.

(I'm snipping all the details of your own C compiler, because there is
very little I can comment on.)

But, things can be considered in relative terms:
Like, C++ may carry various penalties vs C.

I don't find C++ carries noticeably penalties compared to C, for my
embedded work.ÿ But I do disable exceptions and RTTI - exceptions may
have very little run-time time overhead, but the unwind tables can be
significant when code size is important in small systems.

Yes, that is the main thing.
ÿÿ They carry zero performance penalty in practice;
ÿÿ But, have a non-zero penalty for image size.

Not enough to be a deal-breaker towards using them if they are used,
but enough that one wants them disabled if not used...

Agreed.

(I could also note that I make heavy use of templates in C++ code - it
often leads to smaller and faster results.)

Curious...


I had tended to use the "write everything one off for the task at hand" approach, but this is a higher-effort approach.

...


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bart <bc@freeuk.com> writes:

On 30/05/2026 13:29, Dan Cross wrote:

In article <10vd1tu$ekvl$1@dont-email.me>, Bart <bc@freeuk.com> wrote:

On 29/05/2026 21:56, Keith Thompson wrote:

[snip]
Upthread, you asked a question:

And then the point becomes, if you always add the parentheses, what >>>> was the point of having that particular precedence level?

You've made it clear that you were never interested in an answer.

You said this:

"You're asking why C is designed the way it is. We could waste a
great deal of time and effort answering that for you. There are
numerous documents about the design and history of C, and of
its ancestor languages. I could provide you with links."

Actually I'm not asking why C is like that. We're already there.

I'm saying that there is no value in those extra levels, some people
think is, and I'm arging about that. I was replying to tTh.

As for my question, what /is/ the point? I'm still waiting!

To clarify: the question is, what is the point of those levels?
How is that different from asking "why C is like that"?

My question is actually independent of C or its history.

I accept those levels exist. I was asking do they currently serve a
useful purpose.

That's very different from your original question, which is quoted
above. Your original question, with its use of the past tense,
seemed clearly (to me) to be about how C was originally designed.

I don't have a straightforward yes or no answer to your restated
question.

C's operator precedence rules are complicated and arguably flawed.
They could have been defined differently. A simpler set of rules,
with fewer levels, *might* have been better. I don't have any
concrete suggestions -- nor do I have any strong preferences.
I accept C's rules as they are. I would accept them if they had
been defined differently.

Nothing about the current rules particularly bothers me. There are
no objective criteria for deciding what the rules *should* be.
Even having multiplication bind more tightly than addition is
fundamentally an arbitrary choice (though one that's almost
universally recognized, even outside the context of programming
languages).

Of course all C implementations must implement the expression
syntax as it's defined by the standard, and any changes in future
editions of the standard would be impractical. As a programmer,
I don't have to be as strict; I can add parentheses when writing
code, and I can look up the rules as needed when reading code.

If not, people can choose to ignore those them when writing C code,
for example like this where all () are technically superfluous:

crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];

Yes, they can, and I personally tend to agree that they should.

And they can choose to not adopt them when devising new languages,
however many still do faithfully recreate the same pattern, with a few notable exceptions such as Go lang.

When designing a new language, there are real advantages in strictly
imitating C's rules, just because so many programmers are familiar
with them. (I would have been silly for C++ or Objective-C to
change the precedence rules, even to improve them.) But there
are also real advantages in using precedence rules that are better
(e.g., simpler) than C's. It depends on the nature of the language.
It could be an interesting discussion for comp.lang.misc.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 30 May 2026 12:01:27 +0100, Bart wrote:

It doesn't beed << >> to be in a distinct group from multiply or add
groups.

But it is also not clear because the part after >> is sprawling.

It?s a counterexample to your claim that ?<< >> [don?t need] to be in
a distinct group?, isn?t it?

You'd want it like this:

Because they are in a distinct group, you don?t need it like this.

Remove ambiguity in the mind of the reader? Leader to fewer
surprises when a new term needs to be added?

The new terms will most likely fit into the existing ones in the
natural way.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-05-31 01:43, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

[...]

[...]

C's operator precedence rules are complicated and arguably flawed.

I'd say that just the (known) flaw makes them (slightly) complicated;
so you need to remember that "flaw" (or "inconsistency") to be safe.
The rest is completely sensible. And even if one doesn't have a table
to look up the precedences they mostly can be derived (presuming one
has a feeling for the underlying logic of these things or experiences
from other related areas).

They could have been defined differently. A simpler set of rules,
with fewer levels, *might* have been better. I don't have any
concrete suggestions -- nor do I have any strong preferences.
I accept C's rules as they are. I would accept them if they had
been defined differently.

Nothing about the current rules particularly bothers me. There are
no objective criteria for deciding what the rules *should* be.

There are. (What I called above as "derived underlying logic".) Some
aspects have already been formulated in this and other threads here.
But maybe not obvious to recognize without background in mathematics,
logic, or CS.

Even having multiplication bind more tightly than addition is
fundamentally an arbitrary choice

(Now opinions are getting really strange; in the above stated sense.)

(though one that's almost
universally recognized, even outside the context of programming
languages).

[...]

If not, people can choose to ignore those them when writing C code,
for example like this where all () are technically superfluous:

crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];

Yes, they can, and I personally tend to agree that they should.

The more complex the expressions are the more structure they need.

IMO, the parenthesis above make precedence clear (if unknown!), but
are not contributing to readability. It would have made more sense
to separate the sub-expression within the [...] in an own object to
enhance readability and to more easily understand what's going on.

To emphasize; not the precedences are the problem above, but the
complexity of the expression in connexion with lack of structuring.

[...]

When designing a new language, there are real advantages in strictly imitating C's rules, just because so many programmers are familiar
with them.

Huh? - How that? - Are you saying here that practically only C-like
languages are in common use? - But even if so; there's quite some
languages with differing precedence rules, not C-based, and without
such a flaw like the one being discussed. - When designing a *new*
language I'd certainly choose one of the sensible precedence rules,
and just without those obvious flaws. (And not use "C" as base, of
course.)

(I would have been silly for C++ or Objective-C to
change the precedence rules, even to improve them.) But there
are also real advantages in using precedence rules that are better
(e.g., simpler) than C's.

Or - with reference to that flaw - just more consistent.

Consistent systems are inherently simpler, in the sense of easier to
understand and thus more straightforward to use. A precondition for
that is, as said, at least a basic understanding of such things.

It depends on the nature of the language.
It could be an interesting discussion for comp.lang.misc.

Janis


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

On 2026-05-31 01:43, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

[...]

[...]
C's operator precedence rules are complicated and arguably flawed.

I'd say that just the (known) flaw makes them (slightly) complicated;
so you need to remember that "flaw" (or "inconsistency") to be safe.
The rest is completely sensible. And even if one doesn't have a table
to look up the precedences they mostly can be derived (presuming one
has a feeling for the underlying logic of these things or experiences
from other related areas).

Reasonable, but I feel the need to say that that's your personal
opinion. You seem to think that C's precedence rules have one and
only one flaw, and a set of rules with that flaw corrected would
be ideal.

I don't even necessarily disagree, but others are likely to have
different opinions, and those opinions might be perfectly valid.

I don't want to make a huge deal out of this. I honestly don't have
a strong opinion myself. I usually find dealing with the rules
as they exist to be a much better use of my time and attention --
and I don't mean that as a criticism of anyone who choose to think
about alternatives.

They could have been defined differently. A simpler set of rules,
with fewer levels, *might* have been better. I don't have any
concrete suggestions -- nor do I have any strong preferences.
I accept C's rules as they are. I would accept them if they had
been defined differently.
Nothing about the current rules particularly bothers me. There are
no objective criteria for deciding what the rules *should* be.

There are. (What I called above as "derived underlying logic".) Some
aspects have already been formulated in this and other threads here.
But maybe not obvious to recognize without background in mathematics,
logic, or CS.

Even having multiplication bind more tightly than addition is
fundamentally an arbitrary choice

(Now opinions are getting really strange; in the above stated sense.)

Mathematical notation almost universally has multiplication binding
more tightly than addition. It's consistent because the consistency
itself has big advantages so that you can write x + y * z (or x +
y ? z) and everyone knows what you mean. Strict left-to-right
evaluation would also have been a valid choice. (I don't know the
history, but it probably goes back several centuries.)

(though one that's almost
universally recognized, even outside the context of programming
languages).
[...]

If not, people can choose to ignore those them when writing C code,
for example like this where all () are technically superfluous:

crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];

Yes, they can, and I personally tend to agree that they should.

The more complex the expressions are the more structure they need.

IMO, the parenthesis above make precedence clear (if unknown!), but
are not contributing to readability. It would have made more sense
to separate the sub-expression within the [...] in an own object to
enhance readability and to more easily understand what's going on.

To emphasize; not the precedences are the problem above, but the
complexity of the expression in connexion with lack of structuring.

[...]

When designing a new language, there are real advantages in strictly
imitating C's rules, just because so many programmers are familiar
with them.

Huh? - How that? - Are you saying here that practically only C-like
languages are in common use?

Huh? No, I didn't say that at all.

I suggest that if you're designing a somewhat C-like language,
sticking to C's precedence rules has advantages due to programmer
familiarity. Even for a language that's not particularly C-like,
but that has C-like expressions, the designer might consider
following C's rules.

Or not.

- But even if so; there's quite some
languages with differing precedence rules, not C-based, and without
such a flaw like the one being discussed. - When designing a *new*
language I'd certainly choose one of the sensible precedence rules,
and just without those obvious flaws. (And not use "C" as base, of
course.)

Certainly.

(I would have been silly for C++ or Objective-C to
change the precedence rules, even to improve them.) But there
are also real advantages in using precedence rules that are better
(e.g., simpler) than C's.

Or - with reference to that flaw - just more consistent.

Consistent systems are inherently simpler, in the sense of easier to understand and thus more straightforward to use. A precondition for
that is, as said, at least a basic understanding of such things.

Ah, but consistent with what? Internal consistency and consistency
with existing practice are not necessarily the same thing.

It depends on the nature of the language.
It could be an interesting discussion for comp.lang.misc.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31/05/2026 00:43, Keith Thompson wrote:

C's operator precedence rules are complicated and arguably flawed.
They could have been defined differently. A simpler set of rules,
with fewer levels,*might* have been better. I don't have any
concrete suggestions -- nor do I have any strong preferences.
I accept C's rules as they are. I would accept them if they had
been defined differently.

Can't the compiler easily remove any parens that aren't necessary?
So - just write complex expressions in a way that a human can most
easily understand, it makes your intention clear and probable doesn't
increase the size of the executable.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 30/05/2026 22:48, BGB wrote:

On 5/30/2026 6:52 AM, David Brown wrote:

On 29/05/2026 22:16, BGB wrote:

On 5/29/2026 6:22 AM, David Brown wrote:

On 29/05/2026 12:20, BGB wrote:

On 5/29/2026 2:52 AM, Janis Papanagnou wrote:

On 2026-05-28 11:57, BGB wrote:

On 5/28/2026 2:18 AM, Janis Papanagnou wrote:

On 2026-05-28 01:49, BGB wrote:

[...]

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.

Possibly, a lot could depend on how one is counting things as well.


In a lot of cases when using GCC, I end up using:
ÿÿ -ffunction-sections -fdata-sections -Wl,-gc-sections

On many targets, "-fdata-sections" can lead to noticeably larger and
slower code because it effectively eliminates section anchor
optimisations.ÿ It does not negatively affect x86 AFAICS, because
x86 does not use section anchors.

<https://godbolt.org/z/zeoq41Y7d>

With -fsection-anchors (enabled with optimisation on targets that
support it - generally RISCy load/store architectures), program-
lifetime variables are kept together in a lump (as though they were
in a struct) and often addressed by a pointer to that pretend
struct. Thus if a function accesses two variables "a" and "b",
instead of having to load the addresses of each of "a" and "b" into
separate registers, it loads an "anchor" into one register and
accesses the variables with reg+offset addressing.

I've seen "-fdata-sections" used regularly in embedded systems - it
is almost always a bad idea.

("-ffunction-sections" is often very helpful to reduce code image
size, so keep that one.)

Both seem to help on x86, x86-64, and also on RISC-V, at making GCC's
output at least sorta space-comparable to my own compilers.

The merit of "-fdata-sections" is mostly that it eliminates unused
global variables; whereas "-ffunction-sections" eliminates
unreachable functions.

That is the point of them, yes.ÿ "-ffunction-sections" can be useful
at removing unused code from more general code.ÿ For microcontrollers,
SDK's and manufacturers' driver code will normally contain a large
number of functions that can be eliminated in this way, saving a lot
of code space.

However, in practice, "-fdata-sections" rarely eliminates a
significant amount - most programs do not have large amounts of
statically-allocated data that is not used.ÿ Gcc, and I think most
other compilers, put the static lifetime data for each translation
unit in its own section, so if no data from a translation unit is used
it will be eliminated at link time even with -fno-data-sections.ÿ And
of course it makes no difference for heap data or stack data.

The main place it makes a difference is global arrays from a translation unit that is included, but for functions that are not included.

Also functions with large static arrays.

void SomeFunc()
{
ÿ static char buf[4096];
ÿ ...
}

Where, say, eliminating SomeFunc does not necessarily eliminate buf.

Yes, if you have such code but want to eliminate it, then
-fdata-sections would definitely benefit. I have not seen such code in practice (at least not with very big static arrays, and that also was
not an essential part of the program). But of course I have only seen a microscopic part of all C code written - if you come across this sort of thing, then I appreciate your point.

(There are several ways to make this more "friendly" to builds that need
to be compact, such as putting the buffer and/or SomeFunc in a separate
file or giving it a specific section of its own.)

In my testing, "-ffunction-sections" is absolutely worth using (on
targets where code space is relevant - there's no need for PC
software). ÿÿOn some targets, it may mean a few lost opportunities for
shorter jump/call instructions between functions in the same
translation unit, but the cost is rarely anything more than a slightly
longer link time. But "-fdata-sections" typically gives almost no ram
space savings, and makes code bigger and slower.

As I noted, gcc on x86 does not support section anchors, so there is
not likely to be much code cost for -ffdata-sections.

Where section anchors shine - and where -fdata-sections therefore has
cost - is when a function needs to access more than one piece of
static lifetime data defined in the same translation unit (or another
translation unit if you are using LTO).ÿ That happens a lot in
embedded ARM programming at least.ÿ I don't know about RISC-V.ÿ If the
target normally uses a "small data section" for ram (I know this is
common on PowerPC), then there is, in effect, a program-wide section
anchor already.ÿ So it is possible that it relatively few targets have
section anchors - but the 32-bit ARM on gcc is a vastly popular choice
in the embedded world, so it is important to understand the cost of
this compiler flag for that target at least.

It depends on the way it is built.

A lot of times though (for non-relocatable static-linked binaries) it
mostly tends to use AUIPC+LD or AUIPC+ST pairs to access global
variables. There is a Global Pointer that needs to be loaded when the
binary is started, unclear what it is used for exactly.

If you have a global pointer, then it will probably be used for
gp+offset access to global data, eliminating the need for section anchors.

I have not used RISC-V, and am not familiar with its details. I can see
from godbolt that when -fdata-sections is in action and you are loading
from static lifetime variables, the compiler generates instructions like

lw a5, a_variable
lw a4, b_variable
lw a0, c_variable

When you do not have "-fdata-sections", it uses anchors :

lla a4, .LANCHOR0
lw a5, 0(a4)
lw a3, 4(a4)
lw a0, 8(a4)

From my (limited) understanding, RISC-V cannot use 32-bit absolute addressing. So the "lw a5, a_variable" must be a pseudo-instruction -
using register + offset addressing. If there is a global pointer, then presumably that is used here. Alternatively, the pseudo instruction
might assemble to two real instruction to support the 32-bit address. I
know both techniques are used in some targets, but don't know about RISC-V.

Certainly it would surprise me if the "lw a5, a_variable" version were
more efficient than using anchors - otherwise why would gcc generate
code with anchors when given a free choice? (Perhaps gcc is not well
tuned for RISC-V code generation - I am wary of making too many
assumptions about the processor just from some simple compiler outputs.)

(clang does not, apparently, support section anchors as an optimisation technique. Both with and without -fdata-sections, on RISC-V it first
uses two instructions to load ".L_MergedGlobals" into a register and
then uses that register plus offset to access data.)

I don't tend to think of MSVC as a highly optimising compiler - but it
is not a tool I have much use for, as it does not handle the targets I
need.ÿ When I have sometimes looked at the generated code on godbolt,
it has not impressed me at all.ÿ So it could well fall into the
"helpful when using a weaker compiler" category.

Depends on what target I am building for:
ÿ Windows Native: Typically MSVC
ÿ WSL: Usually GCC or Clang
ÿÿÿ Seems to have: GCC 13.2.0; Clang 18.1.3
ÿÿÿ RISC-V GCC: Also 13.2.0 (also via WSL)
ÿ Linux: Typically GCC

I rarely much use Cygwin anymore, as it was mostly rendered obsolete by
WSL (on Win10 or similar).
Though, Cygwin may still be relevant on Win7 or WinXP systems.

Cygwin has its own wide range of complications. If you want to use gcc targeting native Windows, msys2 and mingw-64 are probably your best bet, either compiled natively under msys2 or as a cross-compile from Linux.
But don't place too much emphasis on my advice, as I very rarely compile
C or C++ code for Windows - most of my PC target (Linux or Windows)
coding is in Python.

For BGBCC, it can build both on native Windows and on Linux/WSL (though recently noted that this build was broken, mostly by GCC and Clang being more pedantic about missing prototypes, and a few prototypes were being missed by my function-prototype mining tool). Went and fixed this, but haven't posted this yet.

As for optimizing in MSVC, yeah, it is in the area of not terrible, but
not super clever either.

If one expects the sort of high-level code-rewriting cleverness that GCC
or Clang often does, one will be disappointed.

But, sometimes, the main "heavy hitter" optimizations are things like constant-folding and register allocation, which it does do effectively.

Though, both MSVC and BGBCC seem to use one sort of strategy for
register allocation:

Static assign things to callee-save registers and use remaining
registers for dynamic allocation within basic-blocks. Variables with
finite non-overlapping lifetimes (that do not cross basic-block
boundaries) may potentially share a register (this more generally
applies to things like temporaries).

And, GCC and Clang use another: Assign dynamically but carry values
across basic-block boundaries along control-flow paths.

Both tend to give different patterns though, and seem to favor different types of code.

[...]

(I could also note that I make heavy use of templates in C++ code - it
often leads to smaller and faster results.)

Curious...

I had tended to use the "write everything one off for the task at hand" approach, but this is a higher-effort approach.

A lot of code tends to fall into the category of shuffling data around
or doing simple checks or conversions. It's also common to have wrapper functions for libraries to get something nicer, safer and more
convenient than some API that belongs in the early 1990's. Good C++
templates (and sometimes even good macros in C) can make the use of
these things far nicer, and most of the code that the templates appear
to generate inline in the caller disappears in optimisation.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 31/05/2026 03:37, Janis Papanagnou wrote:

On 2026-05-31 01:43, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

[...]

If not, people can choose to ignore those them when writing C code,
for example like this where all () are technically superfluous:

ÿÿÿ crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];

Yes, they can, and I personally tend to agree that they should.

The more complex the expressions are the more structure they need.

IMO, the parenthesis above make precedence clear (if unknown!), but
are not contributing to readability. It would have made more sense
to separate the sub-expression within the [...] in an own object to
enhance readability and to more easily understand what's going on.

To emphasize; not the precedences are the problem above, but the
complexity of the expression in connexion with lack of structuring.

This is an example of how readability depends on the reader. To me,
there is no benefit in having a sub-expression here because the
structure is clear - this is how you do table-based crc's with 4-bit
chunks. But to someone unfamiliar with CRC calculations, splitting the expression up might make it clearer. (Alternatively, a comment block
with an explanation could help.)

I /do/ think the parentheses here are helpful for readability, precisely because they emphasise the structure of the expression. You could write:

crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF];

but that needs significantly more cognitive effort to parse when reading
it, could be misinterpreted, and has lost all the structure that makes
it easy to see what is going on.

(I regularly use bit-manipulation and shift instructions in my code -
but I still felt it best to check the details in a precedence table
before writing that.)

The expression as originally parenthesised is thus definitely easier for
/me/ to read, and is almost exactly the way I would write it myself :

crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];

The only differences I would have are the names (why would anyone put
variable types into the names like "crcu32" ? We are not writing
BASIC), and I'd use a small case "0xf". Unlike almost every example
Bart has shown before, it even has nice spacing!




--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)