On 08/09/2026 21:08, bart wrote:
On 08/09/2026 17:40, Scott Lurndal wrote:
bart <bc@freeuk.com> writes:
On 07/09/2026 23:50, Janis Papanagnou wrote:
˙ <snip>
It's even worse; given - as mentioned in another part of the thread - >>>>> that #includes are costly we often find some means to avoid not only >>>>> duplicated includes (by #ifndef LABEL, #define LABEL, ..., #endif)
in the header files but also to prevent accessing the header file in >>>>> the first place (by #ifndef LABEL, #include <label.h>, #endif). That >>>>> makes such C/C++ code rather messy, IMO. (And makes one appreciate
languages with an inherent good modularization method yet more.)
The duplication is a problem. If 50 modules each includes the header
files for a library such as SDL2, then a full build means a scanning
the
headers 50 times, which means 4000 header files (80 unique) and 2.5M
lines of code (50K unique).
On a modern machine, this may add a few milliseconds to the build.
I don't think so. Here is a one-file test C program:
˙˙˙ '#include <SDL3/SDL.h>'
This is a test that compiles 50 copies of it:
˙˙˙ c:\sdl>tm gcc -c -I. s*.c
˙˙˙ TM: 36.59
That's 36,000 milliseconds, rather more than a few. (SDL3 is not
80Kloc rather than 50Kloc.)
If I use a precompiled header, then it reduces to 5000 milliseconds.
However that header is 30MB, 8 times the size of the headers.
(I believe that SDL3 uses windows.h, another huge set of headers.
Using TCC here takes 1.5 seconds without using precompiled headers,
but TCC uses a compact version of windows.h.)
Without having used SDL, or done any comparisons or measurements, I
think there are a few things worth considering here.˙ I am not
commenting directly on your particular setup.
1. SDL headers are /big/, because the library is big.˙ Programs that use
SDL general involve a lot of files and a lot of code.˙ So compilation of
SDL programs is naturally going to be more demanding than compilation of "hello world" programs - the time taken to "digest" the headers is then
a smaller proportion of the compilation compared to analysing and
optimising the user code.
I see my current project taking perhaps an order of magnitude longer to build on Windows systems than Linux, with similar processors (I do have
more ram in my system, but I don't think that's critical).
˙ Trying to optimise or flatten header sets
for some library would be a waste of effort - the effect is too minor.
Of course, for someone writing and distributing a popular library, it
might be worth making flattened versions of their headers available as
even a small effect is multiplied by the number of people using the
library.
I did a brief check of the most include-heavy file in my currentYes, these are all techniques that can be used to mitigate what remains,
project.˙ There are about 160 include files going into the compile, with about 200 include directives executed (some headers presumably have
include directives before their include guard).˙ Total pre-processed
code is 3.6 million lines, of which 400 are from the actual C++ file. Pre-processing takes 0.1 seconds, with the full optimised compile taking 0.55 seconds.
"Touching" that one file, and doing "make -j" takes 1.3 seconds - it includes linking after the compiler.˙ A full clean "make -j 18" rebuild takes 6.4 seconds in parallel.˙ A non-parallel build takes 63 seconds.
During typical development, I rebuild after changing a file.˙ 1.3
seconds is close enough to "instant" that it is not an issue - I make changes, press ctrl-S then ctrl-B, and the error markers are in the IDE after 0.5 seconds (there's no linking when I have compile-time errors in
the code!).˙ Saving a hypothetical maximum of 0.1 seconds from flattened headers would make no difference.
But using parallel builds controlled by make, rather than serial builds, cuts the full build time by 90%.˙ (Sometimes a header change triggers a re-compile of large parts of the code base.)˙ Using make to handle dependencies and compile only when needed saves 98% of the time compared
to full serial builds.
Of course it would be nice to shave off another 10% from faster header handling - but it's a drop in the ocean compared to the other generic techniques I already use.
Johann 'Myrkraverk' Oskarsson pisze:Yeah, I don't worry about Keith and trolls like him, and discuss what I
On 08/09/2026 7:52 AM, Keith Thompson wrote:
Lane W <cactus_DAC@yahoo.com> writes:
[128 lines deleted]
One of the things I avoid in C# is a nasty makefile, and generally
having to tool around in Unix. That is all taken care of by the C#
compiler included in the suite I use to generate my programs.
OK, I think we've established that you like C# better than C
(or C++).
This is comp.lang.c.˙ Complaints about C are topical here, even
though some of the ones that introduced this thread are silly.
But if you want to discuss C#, please do so elsewhere.
Oh, don't mind Keith.˙ He likes to butt in on other people's discussions
and behave like he's some owner of comp.lang.c.˙ He's not.˙ There isn't
even a comp.lang.csharp group to direct people towards.˙ I guess Keith
will just have to start a discussion in news.groups.proposals about it.
I've added microsoft.public.dotnet.csharp.general to this discussion,
but I have no idea if Eternal September subscribes to it, which I be-
lieve is what most techies use to access usenet.˙ And the last on-topic
post in microsoft.public.dotnet.csharp.general seems to have been six-
teen years ago.
That's a long time for nobody to get comp.lang.csharp running.
So please feel free to complain in comp.lang.c -- and let the # be si-
lent -- until someone gets irritated enough to make a proposal that
sticks!
Best wishes, and happy coding in C#!
this is probably not god taking on this ...the offtopics imo depending
on amount (yet quality)..if group has some focus it should be focus on
c realted things with some offtopics possible not focus on c not realted offtopics with slight amount of c related...
so i find some sense in what keith t says though i personally cant agree
with his inner idea this group is only for discussing
1) c standards
not
2) c ideas
or
3) c programming
On 09/09/2026 09:18, David Brown wrote:
On 08/09/2026 21:08, bart wrote:
On 08/09/2026 17:40, Scott Lurndal wrote:
bart <bc@freeuk.com> writes:
On 07/09/2026 23:50, Janis Papanagnou wrote:
˙ <snip>
The duplication is a problem. If 50 modules each includes the header >>>>> files for a library such as SDL2, then a full build means a
scanning the
headers 50 times, which means 4000 header files (80 unique) and 2.5M >>>>> lines of code (50K unique).
On a modern machine, this may add a few milliseconds to the build.
I don't think so. Here is a one-file test C program:
˙˙˙ '#include <SDL3/SDL.h>'
This is a test that compiles 50 copies of it:
˙˙˙ c:\sdl>tm gcc -c -I. s*.c
˙˙˙ TM: 36.59
That's 36,000 milliseconds, rather more than a few. (SDL3 is not
80Kloc rather than 50Kloc.)
I tried my SDL3 test with WSL and Windows:
WSL˙˙˙˙˙˙ 22.5 seconds˙ (real)
Windows˙˙ 38˙˙ seconds˙ (elapsed)
This is that amount of files/includes described above, times 50. Tests
were done twice and this is the faster of the two. (Yesterday the
Windows one was 36; timings vary.)
However, this doesn't tell me much about whether building on Windows is inherently slower, since SDL for Windows uses 'windows.h', while for
Linux it may use X11 or whatever. Maybe the former is much larger.
It's possible that your magnitude difference is because you need
windows.h or some other MS header that will be more bloated than the equivalent POSIX.
Or maybe WSL is still really Windows (but I haven't seen a spectacular difference when I used a true Linux).
˙ Trying to optimise or flatten header sets for some library would be
a waste of effort - the effect is too minor.
If that was routinely done, then perhaps we wouldn't need all those
extra resources, tools, and workarounds!
On 09/09/2026 4:18 PM, fir wrote:
Johann 'Myrkraverk' Oskarsson pisze:Yeah, I don't worry about Keith and trolls like him, and discuss what I
On 08/09/2026 7:52 AM, Keith Thompson wrote:
Lane W <cactus_DAC@yahoo.com> writes:
[128 lines deleted]
One of the things I avoid in C# is a nasty makefile, and generally
having to tool around in Unix. That is all taken care of by the C#
compiler included in the suite I use to generate my programs.
OK, I think we've established that you like C# better than C
(or C++).
This is comp.lang.c.˙ Complaints about C are topical here, even
though some of the ones that introduced this thread are silly.
But if you want to discuss C#, please do so elsewhere.
Oh, don't mind Keith.˙ He likes to butt in on other people's discussions >>> and behave like he's some owner of comp.lang.c.˙ He's not.˙ There isn't
even a comp.lang.csharp group to direct people towards.˙ I guess Keith
will just have to start a discussion in news.groups.proposals about it.
I've added microsoft.public.dotnet.csharp.general to this discussion,
but I have no idea if Eternal September subscribes to it, which I be-
lieve is what most techies use to access usenet.˙ And the last on-topic
post in microsoft.public.dotnet.csharp.general seems to have been six-
teen years ago.
That's a long time for nobody to get comp.lang.csharp running.
So please feel free to complain in comp.lang.c -- and let the # be si-
lent -- until someone gets irritated enough to make a proposal that
sticks!
Best wishes, and happy coding in C#!
this is probably not god taking on this ...the offtopics imo depending
on amount (yet quality)..if group has some focus it should be focus on
c realted things with some offtopics possible not focus on c not realted
offtopics with slight amount of c related...
so i find some sense in what keith t says though i personally cant agree
with his inner idea this group is only for discussing
1) c standards
not
2) c ideas
or
3) c programming
want in comp.lang.c.˙ Including meta discussions like this one, about
what should and shouldn't be discussed in comp.lang.c.
Plus, it's fairly clear none of the usual trolls code anything in C, as
I demonstrated when I gave you some book recommendations.
Best wishes, and happy C coding!
Johann 'Myrkraverk' Oskarsson pisze:
On 09/09/2026 4:18 PM, fir wrote:
Johann 'Myrkraverk' Oskarsson pisze:Yeah, I don't worry about Keith and trolls like him, and discuss what I
On 08/09/2026 7:52 AM, Keith Thompson wrote:
Lane W <cactus_DAC@yahoo.com> writes:
[128 lines deleted]
One of the things I avoid in C# is a nasty makefile, and generally >>>>>> having to tool around in Unix. That is all taken care of by the C# >>>>>> compiler included in the suite I use to generate my programs.
OK, I think we've established that you like C# better than C
(or C++).
This is comp.lang.c.˙ Complaints about C are topical here, even
though some of the ones that introduced this thread are silly.
But if you want to discuss C#, please do so elsewhere.
Oh, don't mind Keith.˙ He likes to butt in on other people's
discussions
and behave like he's some owner of comp.lang.c.˙ He's not.˙ There isn't >>>> even a comp.lang.csharp group to direct people towards.˙ I guess Keith >>>> will just have to start a discussion in news.groups.proposals about it. >>>>
I've added microsoft.public.dotnet.csharp.general to this discussion,
but I have no idea if Eternal September subscribes to it, which I be-
lieve is what most techies use to access usenet.˙ And the last on-topic >>>> post in microsoft.public.dotnet.csharp.general seems to have been six- >>>> teen years ago.
That's a long time for nobody to get comp.lang.csharp running.
So please feel free to complain in comp.lang.c -- and let the # be si- >>>> lent -- until someone gets irritated enough to make a proposal that
sticks!
Best wishes, and happy coding in C#!
this is probably not god taking on this ...the offtopics imo
depending on amount (yet quality)..if group has some focus it should
be focus on
c realted things with some offtopics possible not focus on c not realted >>> offtopics with slight amount of c related...
so i find some sense in what keith t says though i personally cant agree >>> with his inner idea this group is only for discussing
1) c standards
not
2) c ideas
or
3) c programming
want in comp.lang.c.˙ Including meta discussions like this one, about
what should and shouldn't be discussed in comp.lang.c.
Plus, it's fairly clear none of the usual trolls code anything in C, as
I demonstrated when I gave you some book recommendations.
Best wishes, and happy C coding!
keith probably used to call me a troll (oz i not stick to his own rigid rules)
so i could eventuall call him back a troll but as i once said if i noticed
it is better to value regular users of this group becouse if not hem
the group culd not exist and i would have no place to talk at all
so i dont call him a troll, becouse he is okay user overally i just
disagree in some things
On 2026-09-09 10:35, David Brown wrote:
On 09/09/2026 09:59, Janis Papanagnou wrote:
We defined our company (coding-)standards to cover that. (And had our
technical mechanisms to alleviate the burden of the textual overhead.)
Most serious developers use some kind of IDE or advanced editor, and
most such tools can generate include guards automatically when you
create a new header file.
Yes, that was what I've meant and what we've done. In addition we
provided templates, and there were external (non-editor-dependent)
generators to quickly create source frames for .h and .cc files;
specifically for C++ that was very useful and saved a lot of time
since we also generated standard class contents, standard headers,
comment frames, c'tors, d'tors, copy-c'tors, =ops, and maybe some
more things.
[...]
I follow that principle too.˙ But not everyone does.˙ So I would have :
#ifndef __NUMBER_GENERATOR_H__
#define __NUMBER_GENERATOR_H__ 1
BTW, since I'm seeing that...
I recall we've had defined these without value assignment just as
˙ #define __NUMBER_GENERATOR_H__
and I seem to recall we've determined that this would suffice and
verified to create no problems. - Is that still valid? (And if so,
what's the purpose of the value then?)
Janis
Keith Thompson wrote:
Imagine that you've posted in some forum that discusses C#.
I jump in to tell you that C++ is much better than C#, and I can't
understand why anyone would use C#, unless they're not cultured
enough to experience C++. That would be rude of me. The corollary
is left as an exercise.
I suppose I can understand that. Not only would it be rude of you, it
would also be false information, or perhaps a misled notion. No one
wants to be distributing false information on the Net.
David Brown <david.brown@hesbynett.no> writes:
On 09/09/2026 09:59, Janis Papanagnou wrote:[...]
Hmm.. - I'm not sure I can follow you here. - If some of our headers
had its own dependencies it was the responsibility of that header to
satisfy them. - I recall there were occasionally issues with lacking
consistency, but that was in our project contexts considered a bug.
I follow that principle too. But not everyone does. So I would have :
#ifndef __NUMBER_GENERATOR_H__
#define __NUMBER_GENERATOR_H__ 1
#include <stdint.h>
extern uint64_t make_a_big_number(void);
#endif // #ifndef __NUMBER_GENERATOR_H__
A couple of nitpicks:
I'd choose a non-reserved name for the macro, probably
H_NUMBER_GENERATOR (not NUMBER_GENERATOR_H because that produces a
reserved name for a header whose name starts with 'e'). Admittedly
the odds of a collision with an implementation-defined reserved
name are small, but I prefer to make them zero. I'd also use
`#define ...` rather than `#define ... 1`; it only matters whether
it's defined or not, not what it expands to.
But some people would omit the "#include <stdint.h>" line, and leave
that as the responsibility of the person writing the C file. The same
applies to dependencies on local header files.
Ick. That would mean that if a future version depends on another
standard header, all client code has to be updated, even if it
doesn't use the new functionality.
On 09/09/2026 11:45, Keith Thompson wrote:
David Brown <david.brown@hesbynett.no> writes:
On 09/09/2026 09:59, Janis Papanagnou wrote:[...]
Hmm.. - I'm not sure I can follow you here. - If some of our headers
had its own dependencies it was the responsibility of that header to
satisfy them. - I recall there were occasionally issues with lacking
consistency, but that was in our project contexts considered a bug.
I follow that principle too.˙ But not everyone does.˙ So I would have :
#ifndef __NUMBER_GENERATOR_H__
#define __NUMBER_GENERATOR_H__ 1
#include <stdint.h>
extern uint64_t make_a_big_number(void);
#endif˙˙˙ // #ifndef __NUMBER_GENERATOR_H__
A couple of nitpicks:
I'd choose a non-reserved name for the macro, probably
H_NUMBER_GENERATOR (not NUMBER_GENERATOR_H because that produces a
reserved name for a header whose name starts with 'e').˙ Admittedly
the odds of a collision with an implementation-defined reserved
name are small, but I prefer to make them zero.˙ I'd also use
`#define ...` rather than `#define ... 1`; it only matters whether
it's defined or not, not what it expands to.
Sure.˙ In practice, it's common to include a bit of directory structure
in the header guard name too.
But some people would omit the "#include <stdint.h>" line, and leave
that as the responsibility of the person writing the C file.˙ The same
applies to dependencies on local header files.
Ick.˙ That would mean that if a future version depends on another
standard header, all client code has to be updated, even if it
doesn't use the new functionality.
Yes.
I've seen worse issues than that, however.
Imagine a library where there is a configuration option NUMBER_OF_THINGS that library users might want to specify, or might want to leave as the default.
So you have :
// user_config.h
#define NUMBER_OF_THINGS 20
// platform_default.h
#ifndef NUMBER_OF_THINGS
#define NUMBER_OF_THINGS 30˙˙˙ // Standard on target X
#endif
// library_funcs.h
#ifndef NUMBER_OF_THINGS
#define NUMBER_OF_THINGS 40˙˙˙ // Default if not overridden
#endif
struct Thing_Holder {
˙˙˙˙int things[NUMBER_OF_THINGS];
};
extern void do_things(struct Thing_Holder * th);
// library_funcs.c
#include "user_config.h"˙˙˙ // User overrides
#include "platform_default.h"˙˙˙ // Platform-specific details
#include "library_funcs.h"
void do_things(struct Thing_Holder * th) {
˙˙˙˙...
}
And then your own code has:
#include "library_funcs.h"
#include "user_config.h"
Imagine the hilarity that results when trying to debug the code.˙ And
then suppose that there's another similar pre-processor symbol that
someone has added manually to an IDE project setup (giving a "-DNUMBER_OF_OTHER_THINGS=42" command-line argument to the compiler),
but that's missing when the project is moved over to a different IDE by someone who didn't know about it.
This kind of nonsense turns up regularly in embedded programming for libraries for RTOS's, network stacks, and manufacturer-provided SDKs and other stuff.˙ Oh, and you might also find multiple different files named "user_config.h" in example code from the supplier, with different
settings (and no information about /why/ particular settings are
picked).˙ Every little bit of the SDK is then in its own directory of
two or three files, and each of these directories is added to the
include path for the compilation, in a random and sometimes inconsistent order.
C's include system works well when used in a sensible and disciplined manner, but unfortunately not all C programmers are sensible and disciplined.
David Brown wrote:
C's include system works well when used in a sensible and disciplinedAgreed. Plus some C programmers use the switch keyword, which we all
manner, but unfortunately not all C programmers are sensible and
disciplined.
agree is BAD BAD BAD, right Janis and Keith?
In fact at work, I'm regularly known as __The Evil One__ because of my propensity to use the switch construct.
Every company brochure shows my position as Sauron in the company
fables, with my signature golden ring. Pure evil, I guarantee it.
fir pisze:
Johann 'Myrkraverk' Oskarsson pisze:besides he is partally right - he has a bit rigid definitions who troll
On 09/09/2026 4:18 PM, fir wrote:
Johann 'Myrkraverk' Oskarsson pisze:Yeah, I don't worry about Keith and trolls like him, and discuss what I
On 08/09/2026 7:52 AM, Keith Thompson wrote:
Lane W <cactus_DAC@yahoo.com> writes:
[128 lines deleted]
One of the things I avoid in C# is a nasty makefile, and generally >>>>>>> having to tool around in Unix. That is all taken care of by the C# >>>>>>> compiler included in the suite I use to generate my programs.
OK, I think we've established that you like C# better than C
(or C++).
This is comp.lang.c.˙ Complaints about C are topical here, even
though some of the ones that introduced this thread are silly.
But if you want to discuss C#, please do so elsewhere.
Oh, don't mind Keith.˙ He likes to butt in on other people's
discussions
and behave like he's some owner of comp.lang.c.˙ He's not.˙ There
isn't
even a comp.lang.csharp group to direct people towards.˙ I guess Keith >>>>> will just have to start a discussion in news.groups.proposals about >>>>> it.
I've added microsoft.public.dotnet.csharp.general to this discussion, >>>>> but I have no idea if Eternal September subscribes to it, which I be- >>>>> lieve is what most techies use to access usenet.˙ And the last on-
topic
post in microsoft.public.dotnet.csharp.general seems to have been six- >>>>> teen years ago.
That's a long time for nobody to get comp.lang.csharp running.
So please feel free to complain in comp.lang.c -- and let the # be si- >>>>> lent -- until someone gets irritated enough to make a proposal that
sticks!
Best wishes, and happy coding in C#!
this is probably not god taking on this ...the offtopics imo
depending on amount (yet quality)..if group has some focus it should
be focus on
c realted things with some offtopics possible not focus on c not
realted
offtopics with slight amount of c related...
so i find some sense in what keith t says though i personally cant
agree
with his inner idea this group is only for discussing
1) c standards
not
2) c ideas
or
3) c programming
want in comp.lang.c.˙ Including meta discussions like this one, about
what should and shouldn't be discussed in comp.lang.c.
Plus, it's fairly clear none of the usual trolls code anything in C, as
I demonstrated when I gave you some book recommendations.
Best wishes, and happy C coding!
keith probably used to call me a troll (oz i not stick to his own
rigid rules)
so i could eventuall call him back a troll but as i once said if i
noticed
it is better to value regular users of this group becouse if not hem
the group culd not exist and i would have no place to talk at all
so i dont call him a troll, becouse he is okay user overally i just
disagree in some things
is - but this is kinda complex matter becouse depending on definitions i
may be a troll according to one, he may be atroll according to another
and so on..and which definitions are good and for what reason is a
complex thing - not sure if this is resolvable...
generally i find whats good to improve some focus and knowledge here as
godo and whats the oposite makin brainless spam is bad etc
On 2026-09-09 02:47, Lane W wrote:
Keith Thompson wrote:
[...][...]
[...] You and Janis are opposed to my switch formulation because it
was me, yes me, Lane W.
How cocky (and completely wrong) to believe that my criticism of your 'if'/'switch' code was a personal thing; the keywords I provided as
hints should have made that very clear that it was really bad code;
and not only "bad" code.
(But now I see that there's indeed something evolving that is related
to your personality, but also to the quality of your posts' contents.
So I'll abstain from further seeing your contributions here. *p*)
I think it's okay if there's an argumentative relation or comparisonJanis just said he didn't like it. You've gone so far as to say it was
not relevant.
The only reason people still use C++ is because of its overall speed from what I can tell.
Or else they haven't been cultured enough to experience C# yet.
What can be done to improve C#'s overall speed?
On 09/09/2026 15:14, Lane W wrote:
David Brown wrote:
C's include system works well when used in a sensible and disciplinedAgreed. Plus some C programmers use the switch keyword, which we all
manner, but unfortunately not all C programmers are sensible and
disciplined.
agree is BAD BAD BAD, right Janis and Keith?
In fact at work, I'm regularly known as __The Evil One__ because of my
propensity to use the switch construct.
Every company brochure shows my position as Sauron in the company
fables, with my signature golden ring. Pure evil, I guarantee it.
I can't understand where this martyr complex comes from.˙ I saw your
post about an alternative way to structure fir's code, and I thought it
was a poor solution.˙ That was not because it used "switch", or because /you/ wrote it, but simply because I did not think it was a clear or maintainable way to express the algorithm.˙ It added complexity and a
layer of indirection without adding advantages of flexibility or
clarity.˙ (I fully agree with your comment in the post that there are
many ways to structure the code here - without knowing much more about
the program, it is impossible to give a good comparison to them.)
If you don't want people to express opinions on code snippets or suggestions, don't post them.˙ I think most regulars here (and certainly Janis and Keith) will judge them as fairly as they can, on the merits of
the code - with a total disregard to who posts them.˙ (The exception is
that many regulars have kill-filed some of the more irksome posters.)
Don't imagine that people will treat your posts or code samples
specially.˙ You are not that important, and you haven't been posting in c.l.c. long enough to have established much of a reputation (positive or negative).
It would be a lot better if you stuck to writing posts that are sensible replies within threads, or start new topical threads.˙ Post C code, get feedback on it, and treat that feedback as constructive criticism of the code - not as some kind of personal attack.˙ (My post here is intended
as constructive criticism - it is not a personal attack.)
David Brown wrote:
On 09/09/2026 15:14, Lane W wrote:It's˙ because many of the lot of you are tying your hands with what you think Policy tells you. The poster asked how to avoid if then else and I showed him a way. It solved his problem. Where is the evil in that? Who
David Brown wrote:
C's include system works well when used in a sensible andAgreed. Plus some C programmers use the switch keyword, which we all
disciplined manner, but unfortunately not all C programmers are
sensible and disciplined.
agree is BAD BAD BAD, right Janis and Keith?
In fact at work, I'm regularly known as __The Evil One__ because of
my propensity to use the switch construct.
Every company brochure shows my position as Sauron in the company
fables, with my signature golden ring. Pure evil, I guarantee it.
I can't understand where this martyr complex comes from.˙ I saw your
post about an alternative way to structure fir's code, and I thought
it was a poor solution.˙ That was not because it used "switch", or
because /you/ wrote it, but simply because I did not think it was a
clear or maintainable way to express the algorithm.˙ It added
complexity and a layer of indirection without adding advantages of
flexibility or clarity.˙ (I fully agree with your comment in the post
that there are many ways to structure the code here - without knowing
much more about the program, it is impossible to give a good
comparison to them.)
If you don't want people to express opinions on code snippets or
suggestions, don't post them.˙ I think most regulars here (and
certainly Janis and Keith) will judge them as fairly as they can, on
the merits of the code - with a total disregard to who posts them.
(The exception is that many regulars have kill-filed some of the more
irksome posters.)
Don't imagine that people will treat your posts or code samples
specially.˙ You are not that important, and you haven't been posting
in c.l.c. long enough to have established much of a reputation
(positive or negative).
It would be a lot better if you stuck to writing posts that are
sensible replies within threads, or start new topical threads.˙ Post C
code, get feedback on it, and treat that feedback as constructive
criticism of the code - not as some kind of personal attack.˙ (My post
here is intended as constructive criticism - it is not a personal
attack.)
is this deity you worship that say to you you can gauge a morality of a snippet of code based on your pathetic standards and policies at YOUR company?
Lane W pisze:
David Brown wrote:
On 09/09/2026 15:14, Lane W wrote:It's˙ because many of the lot of you are tying your hands with what
David Brown wrote:
C's include system works well when used in a sensible andAgreed. Plus some C programmers use the switch keyword, which we all
disciplined manner, but unfortunately not all C programmers are
sensible and disciplined.
agree is BAD BAD BAD, right Janis and Keith?
In fact at work, I'm regularly known as __The Evil One__ because of
my propensity to use the switch construct.
Every company brochure shows my position as Sauron in the company
fables, with my signature golden ring. Pure evil, I guarantee it.
I can't understand where this martyr complex comes from.˙ I saw your
post about an alternative way to structure fir's code, and I thought
it was a poor solution.˙ That was not because it used "switch", or
because /you/ wrote it, but simply because I did not think it was a
clear or maintainable way to express the algorithm.˙ It added
complexity and a layer of indirection without adding advantages of
flexibility or clarity.˙ (I fully agree with your comment in the post
that there are many ways to structure the code here - without knowing
much more about the program, it is impossible to give a good
comparison to them.)
If you don't want people to express opinions on code snippets or
suggestions, don't post them.˙ I think most regulars here (and
certainly Janis and Keith) will judge them as fairly as they can, on
the merits of the code - with a total disregard to who posts them.
(The exception is that many regulars have kill-filed some of the more
irksome posters.)
Don't imagine that people will treat your posts or code samples
specially.˙ You are not that important, and you haven't been posting
in c.l.c. long enough to have established much of a reputation
(positive or negative).
It would be a lot better if you stuck to writing posts that are
sensible replies within threads, or start new topical threads.˙ Post
C code, get feedback on it, and treat that feedback as constructive
criticism of the code - not as some kind of personal attack.˙ (My
post here is intended as constructive criticism - it is not a
personal attack.)
you think Policy tells you. The poster asked how to avoid if then else
and I showed him a way. It solved his problem. Where is the evil in
that? Who is this deity you worship that say to you you can gauge a
morality of a snippet of code based on your pathetic standards and
policies at YOUR company?
in fact i was talking about quite other and more theoretical problem,
not how rewrite tis pice of code (as to revrite i think the ones
˙with
˙char* a= "";˙ if(d<0.3) a ="barely" ; if(d>.9) a= "hardly";
slog("siunsusn %s", a);
is best)
On 09/09/2026 13:32, bart wrote:
On 09/09/2026 09:18, David Brown wrote:
On 08/09/2026 21:08, bart wrote:
On 08/09/2026 17:40, Scott Lurndal wrote:
bart <bc@freeuk.com> writes:
On 07/09/2026 23:50, Janis Papanagnou wrote:
˙ <snip>
The duplication is a problem. If 50 modules each includes the header >>>>>> files for a library such as SDL2, then a full build means a
scanning the
headers 50 times, which means 4000 header files (80 unique) and 2.5M >>>>>> lines of code (50K unique).
On a modern machine, this may add a few milliseconds to the build.
I don't think so. Here is a one-file test C program:
˙˙˙ '#include <SDL3/SDL.h>'
This is a test that compiles 50 copies of it:
˙˙˙ c:\sdl>tm gcc -c -I. s*.c
˙˙˙ TM: 36.59
That's 36,000 milliseconds, rather more than a few. (SDL3 is not
80Kloc rather than 50Kloc.)
I only happen to have SDL2/SDL.h on my machine, but I tested that :
$ cat s1.c
#include <SDL2/SDL.h>
$ time gcc -c s1.c
real˙˙˙ 0m0.223s
user˙˙˙ 0m0.184s
sys˙˙˙ 0m0.039s
$ for i in {2..50}; do cp s1.c s$i.c; done
$ time gcc -c s*.c
real˙˙˙ 0m10.088s
user˙˙˙ 0m8.600s
sys˙˙˙ 0m1.483s
$ touch s*.c
$ time make -j s*.o
real˙˙˙ 0m0.958s
user˙˙˙ 0m14.600s
Note that in my example above, the "extra resources, tools and
workarounds" was one line.
And again, let me reiterate the numbers from my real-world use-case.˙ In comparison to a serial build of all files in my project, these
"workarounds" improve my builds by a factor of 50 or more, compared to
your suggestion that could at most save about 10% if it managed to completely eliminate /all/ pre-processing time.
Using appropriate tools and development practices is not a "workaround",
it is common sense.˙ If you were a lumberjack rather than a programmer, you'd be using a flint axe and accusing chainsaw users as using
workarounds when really the answer is to grow trees without bark.˙ That really is the absurdity of your argument.
so conclusions were c lacks some language construct which i described as
case() {}
case() {}
case() {}
otherwise {}
On 09/09/2026 15:14, Lane W wrote:
David Brown wrote:
C's include system works well when used in a sensible and disciplinedAgreed. Plus some C programmers use the switch keyword, which we all
manner, but unfortunately not all C programmers are sensible and
disciplined.
agree is BAD BAD BAD, right Janis and Keith?
In fact at work, I'm regularly known as __The Evil One__ because of my
propensity to use the switch construct.
Every company brochure shows my position as Sauron in the company
fables, with my signature golden ring. Pure evil, I guarantee it.
I can't understand where this martyr complex comes from.˙ I saw your
post about an alternative way to structure fir's code, and I thought it
was a poor solution.˙ That was not because it used "switch", or
because /you/ wrote it, but simply because I did not think it was a
clear or maintainable way to express the algorithm.
fir wrote:
Lane W pisze:
David Brown wrote:
On 09/09/2026 15:14, Lane W wrote:It's˙ because many of the lot of you are tying your hands with what
David Brown wrote:
C's include system works well when used in a sensible andAgreed. Plus some C programmers use the switch keyword, which we
disciplined manner, but unfortunately not all C programmers are
sensible and disciplined.
all agree is BAD BAD BAD, right Janis and Keith?
In fact at work, I'm regularly known as __The Evil One__ because of >>>>> my propensity to use the switch construct.
Every company brochure shows my position as Sauron in the company
fables, with my signature golden ring. Pure evil, I guarantee it.
I can't understand where this martyr complex comes from.˙ I saw your
post about an alternative way to structure fir's code, and I thought
it was a poor solution.˙ That was not because it used "switch", or
because /you/ wrote it, but simply because I did not think it was a
clear or maintainable way to express the algorithm.˙ It added
complexity and a layer of indirection without adding advantages of
flexibility or clarity.˙ (I fully agree with your comment in the
post that there are many ways to structure the code here - without
knowing much more about the program, it is impossible to give a good
comparison to them.)
If you don't want people to express opinions on code snippets or
suggestions, don't post them.˙ I think most regulars here (and
certainly Janis and Keith) will judge them as fairly as they can, on
the merits of the code - with a total disregard to who posts them.
(The exception is that many regulars have kill-filed some of the
more irksome posters.)
Don't imagine that people will treat your posts or code samples
specially.˙ You are not that important, and you haven't been posting
in c.l.c. long enough to have established much of a reputation
(positive or negative).
It would be a lot better if you stuck to writing posts that are
sensible replies within threads, or start new topical threads.˙ Post
C code, get feedback on it, and treat that feedback as constructive
criticism of the code - not as some kind of personal attack.˙ (My
post here is intended as constructive criticism - it is not a
personal attack.)
you think Policy tells you. The poster asked how to avoid if then
else and I showed him a way. It solved his problem. Where is the evil
in that? Who is this deity you worship that say to you you can gauge
a morality of a snippet of code based on your pathetic standards and
policies at YOUR company?
in fact i was talking about quite other and more theoretical problem,
not how rewrite tis pice of code (as to revrite i think the ones
˙˙with
˙˙char* a= "";˙ if(d<0.3) a ="barely" ; if(d>.9) a= "hardly";
slog("siunsusn %s", a);
is best)
My concern here is that Keith Thompson is going to crucify you here
because you assigned a new value to 'a' after the previous one, which offends his exceedingly gentle sensibilities. How will you continue to
write C if you are nailed to one of Keith Thompson's crosses?
I'd choose a non-reserved name for the macro, probably
H_NUMBER_GENERATOR (not NUMBER_GENERATOR_H because that produces a
reserved name for a header whose name starts with 'e').
Janis Papanagnou wrote:
On 2026-09-09 02:47, Lane W wrote:
Keith Thompson wrote:
[...][...]
[...] You and Janis are opposed to my switch formulation because it
was me, yes me, Lane W.
How cocky (and completely wrong) to believe that my criticism of your
'if'/'switch' code was a personal thing; the keywords I provided as
hints should have made that very clear that it was really bad code;
and not only "bad" code.
(But now I see that there's indeed something evolving that is related
to your personality, but also to the quality of your posts' contents.
So I'll abstain from further seeing your contributions here. *p*)
I can see you are concerned about what is 'good' and 'bad' in
programming. It's not important whether it answers the question a poster asked. Oh no, you've got a couple 'standards' and 'policy' cards up your sleeve about what is right and good and Immaculate in programming. But
it's all dashed against the rocks as you exhibit the height of cowardice
by posting this lengthy screed only to say, goodbye, you're killfiled, sucker. I'm afraid I am extremely loathe to take morality lessons from a fleeing elf like yourself. Go back and cry to Lord Elrond of Rivendell
about the orc who programmed with switch.
I think it's okay if there's an argumentative relation or comparisonJanis just said he didn't like it. You've gone so far as to say it
was not relevant.
to make some point clear. (But there's also purists who don't agree
with that and shun or rebuke you for every non-C related reference.)
A simple "I think A is better than B." statement is in any case not
only an IMO stupid statement but it would require detailed off-topic discussions of A and of B, which are both unrelated to "C".
And I'm always astonished when people make such statement, regarding
tools or languages; my observation is that such people are regularly
judging from a very limited view of own experience or even just from
an isolated bubble. It's also not plausible that things are only B/W;
but that's where animosities grow. Nobody gets anywhere by that. Try
to avoid that.
Myself (and quite typical) knowing only a comparably small subset of
the meanwhile thousands existing programming languages I try to focus
on the good things that languages invented, and on their weak points.
But then there's also all this _repeated and enduring_ expression of disfavor. This is really annoying! And I wonder what these complaints
should accomplish. If someone finds "C" that disgusting (and A or B
"better") it would be consequent to move over and enjoy the presumed advantages of those choices in the respective group.
The only reason people still use C++ is because of its overall speed
from what I can tell.
This is another example of a unhelpful, even stupid formulations (even
when alleviating the core statement by a "from what I can tell" phrase. Speaking about "the only reasons", without evidence (and own knowledge
of the peoples' motivations), and (in the generalized form) of "people"
isn't confidence-inspiring as a base of discussion.
(Myself I'm not using C++ because of it's speed, and I don't avoid C#
because I wouldn't know it. - Accept that there's reasons beyond your
limited abilities of perception or imagination.)
Or else they haven't been cultured enough to experience C# yet.
A statement that can only be understood to have been made from a very
limited experience and knowledge, disregarding what's explained above.
(That statement could even be considered showing arrogance and being
rude; if it wouldn't be so stupid in the first place, and be ignored concerning it's content, these irrelevant and unfounded statements.)
What can be done to improve C#'s overall speed?
This is a question that would be topical in the appropriate C# fora.
fir pisze:
so conclusions were c lacks some language construct which i described as
case() {}
case() {}
case() {}
otherwise {}
this is in fact kinda 'typical' construct when some talk on cases
of usage so imo it could even be written in horizontal
case(d<.3) { slog("dodged hardly"); } case(d>.9) {slog("dodged
barely");} otherwise {slog("dodged");}
i mean it can be written vertical as only one of this subblocks will
execute
Janis Papanagnou pisze:
On 2026-09-09 10:38, David Brown wrote:
On 09/09/2026 10:13, Janis Papanagnou wrote:
On 2026-09-08 13:47, bart wrote:
On 08/09/2026 01:02, Waldek Hebisch wrote:
[...][...]
Still, modern languages tend to have a module scheme, suggesting
the 'flexible' C approach (I'd use the term 'prehistoric') wasn't
quite enough.
A necessary consequence of the growing systems and software
architectures. But even some legacy languages had already
modularization concepts back then! So it's not an excuse to
provide only a primitive #include mechanism. But I wouldn't
be so critical given the time when "C" had been designed.
You should take into account C's design-principles and also
when it came out and sort them in, in comparison to other
language schools; compare (for example) the release dates
of Pascal -> Modula (and what these two provided here).
AFAIK, Pascal originally did not have any kind of "unit" system (its
module equivalent) - you used textual inclusion files.˙ But you then
compiled everything as one big Pascal file rather than having
separate compilation.˙ (This may have varied between Pascal
implementations.)
Yes, exactly. - Original Pascal didn't have anything, then came "C"
timely - providing something that Pascal didn't have! - and Wirth's
next language Modula then had a concept.
Sorry if I was unclear.
Janis
note this pascal sign := is not stupid in some way but it has
disadvanteges - whose in best approach should be none
:= DIS 1) it has worse looking (look) than˙ =; note its important coz =
is much more simple much more clean its also˙ one type and is in ascii
:= ADV 2) it has sense of direction (compared to =)
:= DIS 3) it has only left right sense of direcion - and preferably it should have jet up down (so 4 possible versions)
= DIS 4) it collides with normal math world and normal world meaning of
"=" which are not quite assign - though it kinda painlessly may be used
to assign
it maybe come form basiclike
let a=2
without let a=2 is if-like hipothesis and let changes its meaning
so in c this let is like skipped and its standable. but.... (but there
are some subtle reservations
= ADV 5) it has also some advantage its traditional now/widely taken
(should not make thuis numbered list becouse i wanted to list := dis/adv
but then it shows i talk on =)
overally fact imo is assigns in c imo shouldnt be a=2 like,
you ned close dynamic sign but not this - i made 2 proposition there is
yet third
***************
*
***************
there are in fact more if this above is opened rectangle it also ould be opened traingle (but such noy high but more flat and so on),
even maybe this "harpoon" i mean liek arrow with no one˙ propeler blade (only one) ..harpoons maybe not such bad, (herpoon being lying 1 when
there also lying L is an option and so on)
On 09/09/2026 14:31, David Brown wrote:
On 09/09/2026 15:14, Lane W wrote:
David Brown wrote:
C's include system works well when used in a sensible andAgreed. Plus some C programmers use the switch keyword, which we all
disciplined manner, but unfortunately not all C programmers are
sensible and disciplined.
agree is BAD BAD BAD, right Janis and Keith?
In fact at work, I'm regularly known as __The Evil One__ because of
my propensity to use the switch construct.
Every company brochure shows my position as Sauron in the company
fables, with my signature golden ring. Pure evil, I guarantee it.
I can't understand where this martyr complex comes from.˙ I saw your
post about an alternative way to structure fir's code, and I thought
it was a poor solution.˙ That was not because it used "switch", or
because /you/ wrote it, but simply because I did not think it was a
clear or maintainable way to express the algorithm.
Agreed. It was poor, and there was still some duplication. It was also harder to tell whether the logic agreed with the original.
bart wrote:You have 3 near-identical calls to slog(). And in this new version, NEAT
On 09/09/2026 14:31, David Brown wrote:Here's a revision, where I take MORE THAN TEN SECONDS:
On 09/09/2026 15:14, Lane W wrote:
David Brown wrote:
C's include system works well when used in a sensible andAgreed. Plus some C programmers use the switch keyword, which we all
disciplined manner, but unfortunately not all C programmers are
sensible and disciplined.
agree is BAD BAD BAD, right Janis and Keith?
In fact at work, I'm regularly known as __The Evil One__ because of
my propensity to use the switch construct.
Every company brochure shows my position as Sauron in the company
fables, with my signature golden ring. Pure evil, I guarantee it.
I can't understand where this martyr complex comes from.˙ I saw your
post about an alternative way to structure fir's code, and I thought
it was a poor solution.˙ That was not because it used "switch", or
because /you/ wrote it, but simply because I did not think it was a
clear or maintainable way to express the algorithm.
Agreed. It was poor, and there was still some duplication. It was also
harder to tell whether the logic agreed with the original.
enum Dodges {
˙˙˙ NEAT : 1
˙˙˙ FLAWED : 2
˙˙˙ BARELY : 3
˙˙˙ UNSUCCESS : 4
};
enum Dodges d = UNSUCCESS;
if (dodge < 1)
˙˙˙ d = BARELY;
if (dodge < 0.9)
˙˙˙ d = FLAWED;
if (dodge < 0.5)
˙˙˙ d = NEAT;
switch (d)
{
˙˙˙ case NEAT:
˙˙˙˙˙˙˙ slog("%s easily dodged attack...",˙ being[k].name);
˙˙˙˙˙˙˙ return 1;
˙˙˙ case FLAWED:
˙˙˙˙˙˙˙ slog("%s hardly dodged attack...",˙ being[k].name);
˙˙˙˙˙˙˙ return 1;
˙˙˙ case BARELY:
˙˙˙˙˙˙˙ slog("%s dodged˙ attack...",˙ being[k].name);
˙˙˙˙˙˙˙ return 1;
˙˙˙ default:
˙˙˙˙˙˙˙ return -1; // not dodged.
}
WHERE IS THIS DUPLICATION?
On 09/09/2026 13:30, David Brown wrote:
On 09/09/2026 13:32, bart wrote:
On 09/09/2026 09:18, David Brown wrote:
On 08/09/2026 21:08, bart wrote:
On 08/09/2026 17:40, Scott Lurndal wrote:
bart <bc@freeuk.com> writes:
On 07/09/2026 23:50, Janis Papanagnou wrote:
˙ <snip>
The duplication is a problem. If 50 modules each includes the header >>>>>>> files for a library such as SDL2, then a full build means a
scanning the
headers 50 times, which means 4000 header files (80 unique) and 2.5M >>>>>>> lines of code (50K unique).
On a modern machine, this may add a few milliseconds to the build.
I don't think so. Here is a one-file test C program:
˙˙˙ '#include <SDL3/SDL.h>'
This is a test that compiles 50 copies of it:
˙˙˙ c:\sdl>tm gcc -c -I. s*.c
˙˙˙ TM: 36.59
That's 36,000 milliseconds, rather more than a few. (SDL3 is not
80Kloc rather than 50Kloc.)
I only happen to have SDL2/SDL.h on my machine, but I tested that :
$ cat s1.c
#include <SDL2/SDL.h>
$ time gcc -c s1.c
real˙˙˙ 0m0.223s
user˙˙˙ 0m0.184s
sys˙˙˙ 0m0.039s
$ for i in {2..50}; do cp s1.c s$i.c; done
$ time gcc -c s*.c
real˙˙˙ 0m10.088s
user˙˙˙ 0m8.600s
sys˙˙˙ 0m1.483s
$ touch s*.c
$ time make -j s*.o
real˙˙˙ 0m0.958s
user˙˙˙ 0m14.600s
So actual CPU time is 14 seconds?
Note that in my example above, the "extra resources, tools and
workarounds" was one line.
No, they were invoked in one line. Otherwise you're saying NASA didn't
need the Saturn 5 rocket, just the launch button!
And again, let me reiterate the numbers from my real-world use-case.
In comparison to a serial build of all files in my project, these
"workarounds" improve my builds by a factor of 50 or more, compared to
your suggestion that could at most save about 10% if it managed to
completely eliminate /all/ pre-processing time.
Using appropriate tools and development practices is not a
"workaround", it is common sense.˙ If you were a lumberjack rather
than a programmer, you'd be using a flint axe and accusing chainsaw
users as using workarounds when really the answer is to grow trees
without bark.˙ That really is the absurdity of your argument.
Wrong sort of analogy and the wrong sort of approach.
Let's try this one: you have a task to do, and it takes T time on a
certain machine using a certain tool. But now you need to it 50 times so
it would take 50T.
Your solution is to buy 10 machines each 5 times as fast so that all 50 tasks still complete in time T.
To me, just throwing resources at the problem is the wrong approach. Why aren't you looking at why the task takes T seconds in the first place?
In this case, I mentioned too approaches:
(1) Use a faster tool. I said that that TCC is considerably faster at
this stuff, taking 1.5s versus 38s on Windows. (It turns out windows.h, while it occurs in the headers, is not actually used, so both do the
same work.)
Now, TCC is very poor at generating executable code, however we're
talking about scanning declarations! There is no code; it only has to populate a symbol table. (Actually, there are a dozen small function defs.)
I'm not suggesting to use TCC, but gcc etc ought to work faster.
(2) Reduce the size of the task. I applied my tool to the SDL3 headers,
and the 86 files/82Kloc/3.6MB can be reduced to 1 file/4Kloc/0.18MB.
That is a *95% reduction in source code*.
Combine these two approaches, and you can be looking at a two magnitudes improvement in *raw* compilation speed. You might need to buy a smaller computer!
David Brown wrote:
On 09/09/2026 15:14, Lane W wrote:It's˙ because many of the lot of you are tying your hands with what you think Policy tells you. The poster asked how to avoid if then else and I showed him a way. It solved his problem. Where is the evil in that? Who
David Brown wrote:
C's include system works well when used in a sensible andAgreed. Plus some C programmers use the switch keyword, which we all
disciplined manner, but unfortunately not all C programmers are
sensible and disciplined.
agree is BAD BAD BAD, right Janis and Keith?
In fact at work, I'm regularly known as __The Evil One__ because of
my propensity to use the switch construct.
Every company brochure shows my position as Sauron in the company
fables, with my signature golden ring. Pure evil, I guarantee it.
I can't understand where this martyr complex comes from.˙ I saw your
post about an alternative way to structure fir's code, and I thought
it was a poor solution.˙ That was not because it used "switch", or
because /you/ wrote it, but simply because I did not think it was a
clear or maintainable way to express the algorithm.˙ It added
complexity and a layer of indirection without adding advantages of
flexibility or clarity.˙ (I fully agree with your comment in the post
that there are many ways to structure the code here - without knowing
much more about the program, it is impossible to give a good
comparison to them.)
If you don't want people to express opinions on code snippets or
suggestions, don't post them.˙ I think most regulars here (and
certainly Janis and Keith) will judge them as fairly as they can, on
the merits of the code - with a total disregard to who posts them.
(The exception is that many regulars have kill-filed some of the more
irksome posters.)
Don't imagine that people will treat your posts or code samples
specially.˙ You are not that important, and you haven't been posting
in c.l.c. long enough to have established much of a reputation
(positive or negative).
It would be a lot better if you stuck to writing posts that are
sensible replies within threads, or start new topical threads.˙ Post C
code, get feedback on it, and treat that feedback as constructive
criticism of the code - not as some kind of personal attack.˙ (My post
here is intended as constructive criticism - it is not a personal
attack.)
is this deity you worship that say to you you can gauge a morality of a snippet of code based on your pathetic standards and policies at YOUR company?
bart wrote:
On 09/09/2026 14:31, David Brown wrote:Here's a revision, where I take MORE THAN TEN SECONDS:
On 09/09/2026 15:14, Lane W wrote:
David Brown wrote:
C's include system works well when used in a sensible andAgreed. Plus some C programmers use the switch keyword, which we all
disciplined manner, but unfortunately not all C programmers are
sensible and disciplined.
agree is BAD BAD BAD, right Janis and Keith?
In fact at work, I'm regularly known as __The Evil One__ because of
my propensity to use the switch construct.
Every company brochure shows my position as Sauron in the company
fables, with my signature golden ring. Pure evil, I guarantee it.
I can't understand where this martyr complex comes from.˙ I saw your
post about an alternative way to structure fir's code, and I thought
it was a poor solution.˙ That was not because it used "switch", or
because /you/ wrote it, but simply because I did not think it was a
clear or maintainable way to express the algorithm.
Agreed. It was poor, and there was still some duplication. It was also
harder to tell whether the logic agreed with the original.
Can we get ten more people to hop on the bandwagon and RUDELY tell me
how bad it is?
On 08/09/2026 21:08, bart wrote:
On 08/09/2026 17:40, Scott Lurndal wrote:
4. Modern development is done with build systems - make, cmake, ninja, >bazel, whatever. The real work is done in parallel, making good use of
the multi-core machine. This also exasperates OS limitations - now
instead of dealing with a thousand file reads and a dozen processes for
one compilation, you are doing that twenty times in parallel. On *nix >systems, that's effortless - Windows has far more bottlenecks. And if
you have some kind of on-access anti-virus software running on the
Windows system, that can cripple performance.
I gauged that RUDENESS is something you try to avoid here.
On 09/09/2026 15:25, Lane W wrote:
bart wrote:You have 3 near-identical calls to slog(). And in this new version, NEAT
On 09/09/2026 14:31, David Brown wrote:Here's a revision, where I take MORE THAN TEN SECONDS:
On 09/09/2026 15:14, Lane W wrote:
David Brown wrote:
C's include system works well when used in a sensible andAgreed. Plus some C programmers use the switch keyword, which we
disciplined manner, but unfortunately not all C programmers are
sensible and disciplined.
all agree is BAD BAD BAD, right Janis and Keith?
In fact at work, I'm regularly known as __The Evil One__ because of >>>>> my propensity to use the switch construct.
Every company brochure shows my position as Sauron in the company
fables, with my signature golden ring. Pure evil, I guarantee it.
I can't understand where this martyr complex comes from.˙ I saw your
post about an alternative way to structure fir's code, and I thought
it was a poor solution.˙ That was not because it used "switch", or
because /you/ wrote it, but simply because I did not think it was a
clear or maintainable way to express the algorithm.
Agreed. It was poor, and there was still some duplication. It was
also harder to tell whether the logic agreed with the original.
enum Dodges {
˙˙˙˙ NEAT : 1
˙˙˙˙ FLAWED : 2
˙˙˙˙ BARELY : 3
˙˙˙˙ UNSUCCESS : 4
};
enum Dodges d = UNSUCCESS;
if (dodge < 1)
˙˙˙˙ d = BARELY;
if (dodge < 0.9)
˙˙˙˙ d = FLAWED;
if (dodge < 0.5)
˙˙˙˙ d = NEAT;
switch (d)
{
˙˙˙˙ case NEAT:
˙˙˙˙˙˙˙˙ slog("%s easily dodged attack...",˙ being[k].name);
˙˙˙˙˙˙˙˙ return 1;
˙˙˙˙ case FLAWED:
˙˙˙˙˙˙˙˙ slog("%s hardly dodged attack...",˙ being[k].name);
˙˙˙˙˙˙˙˙ return 1;
˙˙˙˙ case BARELY:
˙˙˙˙˙˙˙˙ slog("%s dodged˙ attack...",˙ being[k].name);
˙˙˙˙˙˙˙˙ return 1;
˙˙˙˙ default:
˙˙˙˙˙˙˙˙ return -1; // not dodged.
}
WHERE IS THIS DUPLICATION?
etc occur 3 times each (plus the enum names don't match what is printed
so are confusing).
Here's a version with only one call to slog:
˙ char* sdodge = NULL;
˙ if (dodge < 1.0)
˙˙˙˙˙ sdodge = " hardly";
˙ if (dodge < 0.9)
˙˙˙˙˙ sdodge = "";
˙ if (dodge < 0.5)
˙˙˙˙˙ sdodge = " easily";
˙ if (sdodge) {
˙˙˙˙˙ slog("%s%s dodged attack...", being[k].name, sdodge);
˙˙˙˙˙ return 1;
˙ }
This requires slog() changed to take an extra argument, or a wrapper created. It also corresponds more accurately to the original which I've pasted below.
On 09/09/2026 15:25, Lane W wrote:
You have 3 near-identical calls to slog(). And in this new version, NEAT
WHERE IS THIS DUPLICATION?
etc occur 3 times each (plus the enum names don't match what is printed
so are confusing).
Here's a version with only one call to slog:
char* sdodge = NULL;
if (dodge < 1.0)
sdodge = " hardly";
if (dodge < 0.9)
sdodge = "";
if (dodge < 0.5)
sdodge = " easily";
bart pisze:
This requires slog() changed to take an extra argument, or a wrapper
created. It also corresponds more accurately to the original which
I've pasted below.
slog is vararg so it can take it -
˙slog is just something like my screen log/memory log for text
quite useful and neat pice of code btw
On 09/09/2026 16:25, Lane W wrote:
I gauged that RUDENESS is something you try to avoid here.
If you don't want rude replies, don't make rude posts.˙ Ridiculous
sarcasm and exaggeration are not helpful.
fir pisze:
bart pisze:i see is should add the optimisation˙˙ if(&slog_[i][0]) ....
This requires slog() changed to take an extra argument, or a wrapper
created. It also corresponds more accurately to the original which
I've pasted below.
slog is vararg so it can take it -
˙˙slog is just something like my screen log/memory log for text
quite useful and neat pice of code btw
its maybe even quite noticable as this slog draw is called every frame
like 100 fps and it in turn calls her 500 calls to text draw helvetica
˙500 lines of memory log is much more than drawed on screen so it seems unnecsssary but i wanted it as a history to eventually "scroll up" and
see or flush to file etc
˙const int slog_line_max = 250;it also suggested using vsnprintf(&slog_[slog_top][0], slog_line_max,
˙const int slog_lines_max = 500;
˙char˙˙˙˙˙ slog_[slog_lines_max][slog_line_max];
˙int˙˙˙˙˙ slog_top = 0;
˙void DrawSlog()
˙{
˙˙ for(int i=0; i<slog_top; i++)
˙˙˙˙˙˙ if(&slog_[i][0])˙ text_xyc_helvetica( 10,helvetica_size*(i+3),0xe8e8e0,˙˙ &slog_[i][0]) ;
˙}
˙void ResetSlog() { slog_top = 0; }
˙void slog(char *format, ...)
˙{
˙˙˙˙˙ va_list args;
˙˙˙˙˙ va_start(args, format);
˙˙˙˙˙ vsprintf(&slog_[slog_top][0], format, args);
˙˙˙˙˙ va_end(args);
˙˙˙˙˙ slog_top++;
˙˙˙˙˙ if(slog_top>=slog_lines_max) slog_top=0;
˙ }
lol chatgpt corrected me indeed this if(&slog_[i][0]) cant be null at all as its place in ram table,
fir pisze:
fir pisze:it also suggested using˙ vsnprintf(&slog_[slog_top][0], slog_line_max, format, args); and turning˙ &slog_[i][0] into slog[i]
bart pisze:i see is should add the optimisation˙˙ if(&slog_[i][0]) ....
This requires slog() changed to take an extra argument, or a wrapper
created. It also corresponds more accurately to the original which
I've pasted below.
slog is vararg so it can take it -
˙˙slog is just something like my screen log/memory log for text
quite useful and neat pice of code btw
its maybe even quite noticable as this slog draw is called every frame
like 100 fps and it in turn calls her 500 calls to text draw helvetica
˙˙500 lines of memory log is much more than drawed on screen so it
seems unnecsssary but i wanted it as a history to eventually "scroll
up" and see or flush to file etc
˙˙const int slog_line_max = 250;
˙˙const int slog_lines_max = 500;
˙˙char˙˙˙˙˙ slog_[slog_lines_max][slog_line_max];
˙˙int˙˙˙˙˙ slog_top = 0;
˙˙void DrawSlog()
˙˙{
˙˙˙ for(int i=0; i<slog_top; i++)
˙˙˙˙˙˙˙ if(&slog_[i][0])˙ text_xyc_helvetica(
10,helvetica_size*(i+3),0xe8e8e0,˙˙ &slog_[i][0]) ;
˙˙}
˙˙void ResetSlog() { slog_top = 0; }
˙˙void slog(char *format, ...)
˙˙{
˙˙˙˙˙˙ va_list args;
˙˙˙˙˙˙ va_start(args, format);
˙˙˙˙˙˙ vsprintf(&slog_[slog_top][0], format, args);
˙˙˙˙˙˙ va_end(args);
˙˙˙˙˙˙ slog_top++;
˙˙˙˙˙˙ if(slog_top>=slog_lines_max) slog_top=0;
˙˙ }
lol chatgpt corrected me indeed this˙ if(&slog_[i][0])˙ cant be null
at all as its place in ram table,
bart pisze:
On 09/09/2026 15:25, Lane W wrote:
bart wrote:You have 3 near-identical calls to slog(). And in this new version,
On 09/09/2026 14:31, David Brown wrote:Here's a revision, where I take MORE THAN TEN SECONDS:
On 09/09/2026 15:14, Lane W wrote:
David Brown wrote:
C's include system works well when used in a sensible andAgreed. Plus some C programmers use the switch keyword, which we
disciplined manner, but unfortunately not all C programmers are >>>>>>> sensible and disciplined.
all agree is BAD BAD BAD, right Janis and Keith?
In fact at work, I'm regularly known as __The Evil One__ because
of my propensity to use the switch construct.
Every company brochure shows my position as Sauron in the company >>>>>> fables, with my signature golden ring. Pure evil, I guarantee it.
I can't understand where this martyr complex comes from.˙ I saw
your post about an alternative way to structure fir's code, and I
thought it was a poor solution.˙ That was not because it used
"switch", or because /you/ wrote it, but simply because I did not
think it was a clear or maintainable way to express the algorithm.
Agreed. It was poor, and there was still some duplication. It was
also harder to tell whether the logic agreed with the original.
enum Dodges {
˙˙˙˙ NEAT : 1
˙˙˙˙ FLAWED : 2
˙˙˙˙ BARELY : 3
˙˙˙˙ UNSUCCESS : 4
};
enum Dodges d = UNSUCCESS;
if (dodge < 1)
˙˙˙˙ d = BARELY;
if (dodge < 0.9)
˙˙˙˙ d = FLAWED;
if (dodge < 0.5)
˙˙˙˙ d = NEAT;
switch (d)
{
˙˙˙˙ case NEAT:
˙˙˙˙˙˙˙˙ slog("%s easily dodged attack...",˙ being[k].name);
˙˙˙˙˙˙˙˙ return 1;
˙˙˙˙ case FLAWED:
˙˙˙˙˙˙˙˙ slog("%s hardly dodged attack...",˙ being[k].name);
˙˙˙˙˙˙˙˙ return 1;
˙˙˙˙ case BARELY:
˙˙˙˙˙˙˙˙ slog("%s dodged˙ attack...",˙ being[k].name);
˙˙˙˙˙˙˙˙ return 1;
˙˙˙˙ default:
˙˙˙˙˙˙˙˙ return -1; // not dodged.
}
WHERE IS THIS DUPLICATION?
NEAT etc occur 3 times each (plus the enum names don't match what is
printed so are confusing).
Here's a version with only one call to slog:
˙˙ char* sdodge = NULL;
˙˙ if (dodge < 1.0)
˙˙˙˙˙˙ sdodge = " hardly";
˙˙ if (dodge < 0.9)
˙˙˙˙˙˙ sdodge = "";
˙˙ if (dodge < 0.5)
˙˙˙˙˙˙ sdodge = " easily";
˙˙ if (sdodge) {
˙˙˙˙˙˙ slog("%s%s dodged attack...", being[k].name, sdodge);
˙˙˙˙˙˙ return 1;
˙˙ }
This requires slog() changed to take an extra argument, or a wrapper
created. It also corresponds more accurately to the original which
I've pasted below.
slog is vararg so it can take it -
˙slog is just something like my screen log/memory log for text
quite useful and neat pice of code btw
˙const int slog_line_max = 250;
˙const int slog_lines_max = 500;
˙char˙˙˙˙˙ slog_[slog_lines_max][slog_line_max];
˙int˙˙˙˙˙ slog_top = 0;
˙void DrawSlog()
˙{
˙˙ for(int i=0; i<slog_top; i++)
˙˙˙ text_xyc_helvetica( 10,helvetica_size*(i+3),0xe8e8e0,
&slog_[i][0]) ;
˙}
˙ void ResetSlog()˙˙ {˙˙˙˙˙ slog_top = 0;˙ }
˙ void slog(char *format, ...)
˙˙ {
˙˙˙˙˙ va_list args;
˙˙˙˙˙ va_start(args, format);
˙˙˙˙˙ vsprintf(&slog_[slog_top][0], format, args);
˙˙˙˙˙ va_end(args);
˙˙˙˙˙ slog_top++;
˙˙˙˙˙ if(slog_top>=slog_lines_max) slog_top=0;
˙˙ }
On 09/09/2026 16:09, bart wrote:
I am looking at what /I/ can do to get the results I need in a timely fashion.˙ I am not interested in spending years making a new C compiler
just because it might be a bit faster than gcc - which sane customer
would pay me to do that?
˙I am not interested in spending days or weeks
trying to minimise and optimise the headers from manufacturer's SDKs and third-party libraries to shave a few percent off my built times.
TCC is, at best, a very niche tool.˙ It is not an alternative for
serious development work.
Now, TCC is very poor at generating executable code, however we're
talking about scanning declarations! There is no code; it only has to
populate a symbol table. (Actually, there are a dozen small function
defs.)
No one cares about the speed of scanning declarations.˙ The speed at
which actual programs are compiled can be relevant (though I have yet to
see it as an issue for my work).˙ It doesn't matter how quickly or
slowly a computer can do a useless task.
I'm not suggesting to use TCC, but gcc etc ought to work faster.
(2) Reduce the size of the task. I applied my tool to the SDL3
headers, and the 86 files/82Kloc/3.6MB can be reduced to 1
file/4Kloc/0.18MB.
That is a *95% reduction in source code*.
As I showed in my timings, in real use, that could, at most, reduce the compile time by about 15%.
Certainly, the line counts of big libraries are likely to dwarf that ofCombine these two approaches, and you can be looking at a two
magnitudes improvement in *raw* compilation speed. You might need to
buy a smaller computer!
You /know/ you are talking drivel here.˙ Either that or you are combing
a appallingly inefficient file handling with an extremely simplistic compiler, if you think that reading the header files is the dominant
time factor for actual real-world compilation of C code.
bart <bc@freeuk.com> writes:
On 09/09/2026 15:25, Lane W wrote:
You have 3 near-identical calls to slog(). And in this new version, NEAT
WHERE IS THIS DUPLICATION?
etc occur 3 times each (plus the enum names don't match what is printed
so are confusing).
Here's a version with only one call to slog:
char* sdodge = NULL;
if (dodge < 1.0)
sdodge = " hardly";
if (dodge < 0.9)
sdodge = "";
if (dodge < 0.5)
sdodge = " easily";
So you assign sdodge up to three times. A waste of cycles.
bart <bc@freeuk.com> wrote:
On 08/09/2026 01:02, Waldek Hebisch wrote:
bart <bc@freeuk.com> wrote:
On 07/09/2026 14:33, David Brown wrote:
On 07/09/2026 14:55, bart wrote:
A typical module scheme works like this:
* You have, say, a project of 100 modules
* Each module selectively exports some entities
* Each module selectively imports some subset of the other 99 modules >>>>>>
OK so far.
The result is that each module starts with some rag-tag collection of >>>>>> 'import' statements, each different from any other module, and needing >>>>>> a lot of maintenance.
No.˙ People who write /structured/ code do not do "rag-tag".
When a project is of a size where it is inconvenient to keep track of >>>>> all the separate "import" (or "#include", or whatever) statements, you >>>>> use a hierarchy.˙ Instead of importing "dns", "udp", "http", etc.,
modules, you import "network".˙ The common "network" module pulls in the >>>>> sub-modules.˙ You probably also organise things in directories and sub- >>>>> directories, matching the module layout.˙ It is /structured/.
But it's a pattern I've seen a lot. In C also, as collections of
#includes; this example is from Lua, a project of only 35 modules, and >>>> from one of its .c files:
#include "lprefix.h"
#include <float.h>
#include <limits.h>
#include <math.h>
#include <stdlib.h>
#include "lua.h"
#include "lcode.h"
#include "ldebug.h"
#include "ldo.h"
#include "lgc.h"
#include "llex.h"
#include "lmem.h"
#include "lobject.h"
#include "lopcodes.h"
#include "lparser.h"
#include "lstring.h"
#include "ltable.h"
#include "lvm.h"
Every file has a different set. In all, there are 28K lines of C code
among the .c files, and there are 466 #include lines. That is similar to >>>> the maintenance nightmare where each file imports a particular set of
modules.
The organization looks sensible to me.
Not to me. This project uses these 35 files:
lapi.c lauxlib.c lbaselib.c lcode.c lcorolib.c lctype.c ldblib.c
ldebug.c ldo.c ldump.c lfunc.c lgc.c linit.c liolib.c llex.c
lmathlib.c lmem.c loadlib.c lobject.c lopcodes.c loslib.c lparser.c
lstate.c lstring.c lstrlib.c ltable.c ltablib.c ltests.c ltm.c lua.c
lundump.c lutf8lib.c lvm.c lzio.c onelua.c
(A build will use 34 of them, depending whether it is EXE or DLL.)
With a module scheme, there should be no need for any additional info at
all. But my point was, with how such schemes typically work, you still
have lots of mixed sets of 'import' statements at the start of each file.
Given that #include lines
are less than 2% of total and are likely to change very infrequently
I see no maintennce problem.
You can't quantify it like that. In any case, they will only change
infrequently once you've finished development!
If a program is "finished" it will not change at all. During
normal developement I need to add #include lines, but once
added they tend to stay. Sometimes I realize that given
include is not needed or I decide to rename a file. Normal
code is different, first version may have bugs which need
fixing, I may realize that different structure is better, so
there is lot of changes. Relatively to that I perceive changes
to #include lines to be very infrequent.
I found it annoying enough, and taking up enough time to devise a new
way of doing modules. And it is utter bliss.
I agree that maintaing info that you do not value may be annoying.
But if you are used to maintaing C code bases, than maintaining
#include lines does not take much time.
Still, modern languages tend to have a module scheme, suggesting the
'flexible' C approach (I'd use the term 'prehistoric') wasn't quite enough.
I used or at least looked at several languages with module systems
or things intended to perform similar duty. You approach seem to
be unique, all other require explicit import or equivalent at least
in some (rather frequent) cases. Some languages do not support
re-export, in such case you can rightfully complain. The ones with
re-export allow forming common interface module do that number
of import statements is minimised. But this is developers choice
and apparently most prefer to import only needed things, even
though it requires more import statements.
Module system has other advantages over C. First, in C sane
developers use headers in consistent way, but language
does not enforce it. Typical module system enforces
consistency. Second, module interfaces can be parsed once,
avoiding problem of repeated re-parsing of C headers.
Third, modules resolve name clashes: the "same" name in
two different modules is disambiguated by its source module.
Fourth, given a main module compiler can track its imports
and build the program without need for separate Makefile.
There are different styles. Ada, Modula 2 and Extended Pascal
use separate interface modules. In typical practice they are
stored in separate files so this looks similar to C practice
of having .c and .h files. Other languages like UCSD/Turbo
Pascal have modules with separate iterface and implementation
parts, but both parts are considered a single module. In
practice with such languages whole module is kept in a single
file, so number of separate files is smaller. But you still
have separate declarations in interface part and definitions
in implementation part. Wirth Oberon (or at least some variant
of it) uses different apprach, IIRC exported functions are
marked putting asterisk before function name. That means less
code to write, but to see what is exported you need a separate
tool.
IIUC modules with separate iterface and implementation were
advocated together with database-like storage of source code.
On 09/09/2026 15:58, David Brown wrote:
On 09/09/2026 16:09, bart wrote:
I am looking at what /I/ can do to get the results I need in a timely
fashion.˙ I am not interested in spending years making a new C compiler
just because it might be a bit faster than gcc - which sane customer
would pay me to do that?
I'm not saying that. But people SHOULD be more critical of how fast
their tools are, instead of just throwing more brute force at the problem.
Tiny C *does* seem to do the same task (parse huge amounts of
declarations) at least a magnitude faster than TCC. TCC wouldn't need
those extra cores. Maybe gcc wouldn't either.
And yet, you can see 10:1 difference in assembling the same program.
What on earth are those slow ones up to?
˙I am not interested in spending days or weeks
trying to minimise and optimise the headers from manufacturer's SDKs and
third-party libraries to shave a few percent off my built times.
I'm not saying that either. I think people who supply the API headers
should do that.
TCC is, at best, a very niche tool.˙ It is not an alternative for
serious development work.
It provides one invaluable service: it shows just how slow some
compilers are, even doing the same task.
Now, TCC is very poor at generating executable code, however we're
talking about scanning declarations! There is no code; it only has to
populate a symbol table. (Actually, there are a dozen small function
defs.)
No one cares about the speed of scanning declarations.˙ The speed at
which actual programs are compiled can be relevant (though I have yet to
see it as an issue for my work).˙ It doesn't matter how quickly or
slowly a computer can do a useless task.
And yet, precompiled headers were introduced. Why, if it is a non-issue?
A module scheme should mean less work not more.
bart <bc@freeuk.com> writes:
I'm not saying that either. I think people who supply the API headers
should do that.
Just to make you happy? It wouldn't work, you'd just find something
else to complain about.
TCC is, at best, a very niche tool.˙ It is not an alternative for
serious development work.
It provides one invaluable service: it shows just how slow some
compilers are, even doing the same task.
No, they're not "doing the same task". TCC will not compile
my code successfully. gcc and clang will.
On 09/09/2026 15:58, David Brown wrote:
On 09/09/2026 16:09, bart wrote:
I am looking at what /I/ can do to get the results I need in a timely
fashion.˙ I am not interested in spending years making a new C
compiler just because it might be a bit faster than gcc - which sane
customer would pay me to do that?
I'm not saying that. But people SHOULD be more critical of how fast
their tools are, instead of just throwing more brute force at the problem.
Tiny C *does* seem to do the same task (parse huge amounts of
declarations) at least a magnitude faster than TCC. TCC wouldn't need
those extra cores. Maybe gcc wouldn't either.
You see the same thing assemblers. There, there is no backend optimising
of the kind that compilers do. Assembling is a simple, linear process.
And yet, you can see 10:1 difference in assembling the same program.
What on earth are those slow ones up to?
˙I am not interested in spending days or weeks trying to minimise and
optimise the headers from manufacturer's SDKs and third-party
libraries to shave a few percent off my built times.
I'm not saying that either. I think people who supply the API headers
should do that.
TCC is, at best, a very niche tool.˙ It is not an alternative for
serious development work.
It provides one invaluable service: it shows just how slow some
compilers are, even doing the same task.
Now, TCC is very poor at generating executable code, however we're
talking about scanning declarations! There is no code; it only has to
populate a symbol table. (Actually, there are a dozen small function
defs.)
No one cares about the speed of scanning declarations.˙ The speed at
which actual programs are compiled can be relevant (though I have yet
to see it as an issue for my work).˙ It doesn't matter how quickly or
slowly a computer can do a useless task.
And yet, precompiled headers were introduced. Why, if it is a non-issue?
I'm not suggesting to use TCC, but gcc etc ought to work faster.
(2) Reduce the size of the task. I applied my tool to the SDL3
headers, and the 86 files/82Kloc/3.6MB can be reduced to 1
file/4Kloc/0.18MB.
That is a *95% reduction in source code*.
As I showed in my timings, in real use, that could, at most, reduce
the compile time by about 15%.
So it doesn't matter at all how large and bloated any library's headers
are?
This attitude is why we see bloat everywhere as well as some dead-slow applications. Maybe some people want to sell more RAM and more hardware; that's not going to happen if existing tools are too fast!
According to David Brown and Scott Lurndal, that is a non-problem!Please stop paraphrasing me (and other people) incorrectly. Instead,
And according to DB, reducing a large, complex mass of header files (of external library) into one compact file 95% smaller, would be a waste of time.
bart <bc@freeuk.com> writes:
The days of submitting a deck of cards and waiting 24 hours for your
output are long gone.
And yet, precompiled headers were introduced. Why, if it is a non-issue?
Because someone like you pushed for them. I'm not aware of anyone
that actually uses precompiled headers.
On 09/09/2026 20:12, bart wrote:You said this:
Please stop paraphrasing me (and other people) incorrectly.˙ Instead,
According to David Brown and Scott Lurndal, that is a non-problem!
And according to DB, reducing a large, complex mass of header files
(of external library) into one compact file 95% smaller, would be a
waste of time.
just assume that you have misunderstood what people have said, and
continue discussing them in the relevant thread in the hope that you eventually understand it.˙ I am happy to discuss many things with you,
but I find your repeated misquoting extremely frustrating.
As I showed in my timings, in real use, that [reducing headers by 95%] could, at most, reduce the compile time by about 15%. It does notmatter how long it takes to read the SDL3 headers and throw them away,
Trying to optimise or flatten header sets for some library would bea waste of effort - the effect is too minor.
On 09/09/2026 19:34, bart wrote:
You see the same thing [with] assemblers. There, there is no backend
optimising of the kind that compilers do. Assembling is a simple,
linear process.
And yet, you can see 10:1 difference in assembling the same program.
What on earth are those slow ones up to?
It's not hard to make programs that are slow for a particular task. Once
you have reached a certain point, however, it's far harder to make them
much faster.˙ I believe there was a mainstream assembler that had a particularly poor algorithm somewhere, resulting in surprisingly long
run times once input was over a certain size.˙ I don't imagine it is a general problem, however.
On 09/09/2026 11:05, fir wrote:
Janis Papanagnou pisze:
On 2026-09-09 10:38, David Brown wrote:
On 09/09/2026 10:13, Janis Papanagnou wrote:
On 2026-09-08 13:47, bart wrote:
On 08/09/2026 01:02, Waldek Hebisch wrote:
note this pascal sign := is not stupid in some way but it has
disadvanteges - whose in best approach should be none
:= DIS 1) it has worse looking (look) than˙ =; note its important coz
= is much more simple much more clean its also˙ one type and is in ascii
:= ADV 2) it has sense of direction (compared to =)
:= DIS 3) it has only left right sense of direcion - and preferably it
should have jet up down (so 4 possible versions)
= DIS 4) it collides with normal math world and normal world meaning
of "=" which are not quite assign - though it kinda painlessly may be
used to assign
it maybe come form basiclike
let a=2
without let a=2 is if-like hipothesis and let changes its meaning
so in c this let is like skipped and its standable. but.... (but there
are some subtle reservations
= ADV 5) it has also some advantage its traditional now/widely taken
(should not make thuis numbered list becouse i wanted to list := dis/
adv but then it shows i talk on =)
overally fact imo is assigns in c imo shouldnt be a=2 like,
you ned close dynamic sign but not this - i made 2 proposition there
is yet third
[...]
On 2026-09-09 20:37, Scott Lurndal wrote:
bart <bc@freeuk.com> writes:
The days of submitting a deck of cards and waiting 24 hours for your
output are long gone.
Hey, where have you been working? - We regularly waited less than 1
hour to get the output from our card decks! - Upgrade your systems
or employ more admins. ;-}
[...]
And yet, precompiled headers were introduced. Why, if it is a non-issue?
Because someone like you pushed for them. I'm not aware of anyone
that actually uses precompiled headers.
I have to admit that my memories are faint here, but I seem to recall
that we took advantage from precompiled headers.
And, sadly, I cannot tell whether it were "someone [like you]" (the >customers) that "pushed" the demand or whether the vendors recognized
that feature (whether by customer feedback or by own investigation).
(If you have some substantial evidence about that I'd like to hear.)
On 09/09/2026 02:59, Waldek Hebisch wrote:
[...]
Some even specify individual names to be imported from a module. What a complete waste of time!
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
On 2026-09-09 20:37, Scott Lurndal wrote:
bart <bc@freeuk.com> writes:
The days of submitting a deck of cards and waiting 24 hours for your
output are long gone.
Hey, where have you been working? - We regularly waited less than 1
hour to get the output from our card decks! - Upgrade your systems
or employ more admins. ;-}
[...]
Because someone like you pushed for them. I'm not aware of anyone
And yet, precompiled headers were introduced. Why, if it is a non-issue? >>>
that actually uses precompiled headers.
I have to admit that my memories are faint here, but I seem to recall
that we took advantage from precompiled headers.
And, sadly, I cannot tell whether it were "someone [like you]" (the
customers) that "pushed" the demand or whether the vendors recognized
that feature (whether by customer feedback or by own investigation).
(If you have some substantial evidence about that I'd like to hear.)
It does appear to be used by MSVC somewhat automatically, but it's been
three decades since I wrote any Windows code (and it was driver code for
NT 3.51).
Other restrictions on the GCC implementation include:
Include order matters: The PCH must be the absolute first token the
compiler encounters. You cannot put any code, variable declarations,
or macro defines before it.
One per compilation: Only one precompiled header can be used in a particular
compilation.
Identical flags: The .gch file must be built using the exact same flags
(e.g., -O3, -g, -std=c++20, -m64) as the source files using it.
Matching compiler binary: You must use the exact same compiler version to
build the PCH and the final executable
Tiny C *does* seem to do the same task (parse huge amounts of[...]
declarations) at least a magnitude faster than TCC. TCC wouldn't need
those extra cores. Maybe gcc wouldn't either.
David Brown wrote:[...]
C's include system works well when used in a sensible andAgreed. Plus some C programmers use the switch keyword, which we all
disciplined manner, but unfortunately not all C programmers are
sensible and disciplined.
agree is BAD BAD BAD, right Janis and Keith?
In fact at work, I'm regularly known as __The Evil One__ because of my propensity to use the switch construct.
Every company brochure shows my position as Sauron in the company
fables, with my signature golden ring. Pure evil, I guarantee it.
enum Dodges {
NEAT : 1
FLAWED : 2
BARELY : 3
UNSUCCESS : 4
};
enum Dodges d = UNSUCCESS;
if (dodge < 1)
d = BARELY;
if (dodge < 0.9)
d = FLAWED;
if (dodge < 0.5)
d = NEAT;
switch (d)
{
case NEAT:
slog("%s easily dodged attack...", being[k].name);
return 1;
case FLAWED:
slog("%s hardly dodged attack...", being[k].name);
return 1;
case BARELY:
slog("%s dodged attack...", being[k].name);
return 1;
default:
return -1; // not dodged.
}
WHERE IS THIS DUPLICATION?
WHERE ARE THESE SYNTAX ERRORS YOU NEVER EXPLICITLY STATE?
Am I cleared for Heaven now?
Can we get ten more people to hop on the bandwagon and RUDELY tell me
how bad it is?
I gauged that RUDENESS is something you try to avoid here.
On 2026-09-09 20:12, bart wrote:Why? What is the advantage of so much micromanagement?
On 09/09/2026 02:59, Waldek Hebisch wrote:
[...]
Some even specify individual names to be imported from a module. What
a complete waste of time!
I fear you're just exposing your very limited perception and experience
here. (And en passant probably also the mindset of a technocratic paper pusher than a software designer.)
Myself I'm favoring _to be able_ to import only what I need and not the
whole bunch of existing things of a module (with all potential implicit
and explicit consequences).
Myself I'm favoring _to be able_ to import only what I need and not the whole bunch of existing things of a module (with all potential implicit
and explicit consequences).
bart <bc@freeuk.com> writes:
[...]
Tiny C *does* seem to do the same task (parse huge amounts of[...]
declarations) at least a magnitude faster than TCC. TCC wouldn't need
those extra cores. Maybe gcc wouldn't either.
Aren't Tiny C and TCC the same thing? Did you mean "at least a
magnitude faster than gcc"?
On 09/09/2026 10:45, Keith Thompson wrote:
I'd choose a non-reserved name for the macro, probably
H_NUMBER_GENERATOR (not NUMBER_GENERATOR_H because that produces a
reserved name for a header whose name starts with 'e').
Which header?
I get that __anything, _Capital, E, str, mem and probably a few I've forgotten are reserved prefixes. I never heard of NUM or NUMBER being
off limits. Seems a very common prefix that would get used a lot.
(Please, for the sake of the people that haven't killfiled you, use an online-translator to create comprehensible texts! - In case that your
native language *is* English I suggest to translate your text to some
other language and then back to English; the translators are obviously
good enough to fix your language or writing problems in that process.)
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
(Please, for the sake of the people that haven't killfiled you, use an
online-translator to create comprehensible texts! - In case that your
native language *is* English I suggest to translate your text to some
other language and then back to English; the translators are obviously
good enough to fix your language or writing problems in that process.)
The above was addressed to "fir". As I recall, his native language
is Polish.
"fir" has been posting here for a long time. Here's something our own
David Brown wrote about him in 2015. I can't directly vouch for its accuracy, but it seems plausible.
He does not have dyslexia. English is a second language for him,
but he is capable of writing much better than he does (I have seen
him do so) - he /intentionally/ writes in this manner because he
considers himself too much of a grand thinker and philosopher to
lower himself to our mere "commoner" language. As far as I
understand it, he writes in a similar manner in his own language.
Many of us have tried to suggest he changes his manner for his own
good as well as ours - but to no avail.
Reference:
Subject: Re: Recursion or loop, design questions
Date: Wed, 05 Aug 2015 08:45:25 +0200
Message-ID: <mpsbb5$3s9$1@dont-email.me>
I suggest that one more attempt to get fir to write clearly is
unlikely to be effective. I've solved the problem for myself by
adding him to my killfile.
fir wrote:[...]
in fact i was talking about quite other and more theoretical
problem,
not how rewrite tis pice of code (as to revrite i think the ones
˙with
˙char* a= "";˙ if(d<0.3) a ="barely" ; if(d>.9) a= "hardly";
slog("siunsusn %s", a);
is best)
My concern here is that Keith Thompson is going to crucify you here
because you assigned a new value to 'a' after the previous one, which
offends his exceedingly gentle sensibilities. How will you continue to
write C if you are nailed to one of Keith Thompson's crosses?
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
(Please, for the sake of the people that haven't killfiled you, use an
online-translator to create comprehensible texts! - In case that your
native language *is* English I suggest to translate your text to some
other language and then back to English; the translators are obviously
good enough to fix your language or writing problems in that process.)
The above was addressed to "fir". [...]
[ background info snipped ]
I suggest that one more attempt to get fir to write clearly is
unlikely to be effective. I've solved the problem for myself by
adding him to my killfile.
On 09/09/2026 15:14, Lane W wrote:
David Brown wrote:
C's include system works well when used in a sensible and disciplinedAgreed. Plus some C programmers use the switch keyword, which we all
manner, but unfortunately not all C programmers are sensible and
disciplined.
agree is BAD BAD BAD, right Janis and Keith?
[...]
[ snip ]
It would be a lot better if you stuck to writing posts that are sensible replies within threads, or start new topical threads.˙ Post C code, get feedback on it, and treat that feedback as constructive criticism of the code - not as some kind of personal attack.
(My post here is intended
as constructive criticism - it is not a personal attack.)
On 09/09/2026 10:45, Keith Thompson wrote:
I'd choose a non-reserved name for the macro, probably
H_NUMBER_GENERATOR (not NUMBER_GENERATOR_H because that produces a
reserved name for a header whose name starts with 'e').
Which header?
I get that __anything, _Capital, E, str, mem and probably a few I've forgotten are reserved prefixes.˙ I never heard of NUM or NUMBER being
off limits.˙ Seems a very common prefix that would get used a lot.
On 09/09/2026 22:26, Janis Papanagnou wrote:
[...]
Myself I'm favoring _to be able_ to import only what I need and not the
whole bunch of existing things of a module (with all potential implicit
and explicit consequences).
Why? What is the advantage of so much micromanagement?
Is even the pain of having to do '#include <string.h>' not enough when
your code uses string functions, you would prefer to list them
individually too?!
With other languages, do you also need to specify importing individual variables, enumerations, types, structs and macros?
An enumeration set may have hundreds of names; do you have to list all
of them? That would be insane.
I'd originally complained about having to list modules individually in
in each file; this would be literally magnitudes worse.
You might as well put each entity into its own module, and have a subset
of 1000 modules to manage instead - in each of the 1000 functions.
You people seem to like making life difficult. Well, go ahead!
Myself I'm favoring _to be able_ to import only what I need and not the whole bunch of existing things of a module (with all potential implicit and explicit consequences).
Which consequences are these? If there's too much unrelated stuff in a module, that suggests it is poorly structured.
If you import modules A and B, and use functions from each, but some may clash (say you want F from A but not F from B), then that's not a
problem because you will say A.F or B.F.
If you want to use 'using' because you don't want to type 'A.' or 'B.',
just F and it will be from a specific import, that /that/ would be bad
form. In any case, there are better ways.
On 09/09/2026 20:39, David Brown wrote:
On 09/09/2026 19:34, bart wrote:
You see the same thing [with] assemblers. There, there is no backend
optimising of the kind that compilers do. Assembling is a simple,
linear process.
And yet, you can see 10:1 difference in assembling the same program.
What on earth are those slow ones up to?
It's not hard to make programs that are slow for a particular task.
Once you have reached a certain point, however, it's far harder to
make them much faster.˙ I believe there was a mainstream assembler
that had a particularly poor algorithm somewhere, resulting in
surprisingly long run times once input was over a certain size.˙ I
don't imagine it is a general problem, however.
NASM, MASM, or both?
I know there is a long standing bug in NASM which leads to result like these, for this 270Kloc input (actually, an SQL test compiled into three different x64 ASM formats):
˙˙ nasm -O0 -fwin64˙˙˙˙ 250˙˙˙ seconds (to .obj)
˙˙ yasm -fwin64˙˙˙˙˙˙˙˙˙˙ 1.06 seconds (to .obj)
˙˙ as˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ 0.65 seconds (to .o)
˙˙ aa˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ 0.10 seconds (to .exe)
Obviously, 'aa' is my product. And clearly, NASM has something wrong. (Without -O0, it would be 60% slower!)
MASM (as 'ml64.exe') had its own bug to do with using RESB in a .DATA segment; it got exponentially slower with the size of the block. (I no longer have it to test.)
For whole-program compilers that generate a single ASM file, assembly
speed is critical.
bart <bc@freeuk.com> writes:
On 09/09/2026 15:25, Lane W wrote:
You have 3 near-identical calls to slog(). And in this new version, NEAT
WHERE IS THIS DUPLICATION?
etc occur 3 times each (plus the enum names don't match what is printed
so are confusing).
Here's a version with only one call to slog:
char* sdodge = NULL;
if (dodge < 1.0)
sdodge = " hardly";
if (dodge < 0.9)
sdodge = "";
if (dodge < 0.5)
sdodge = " easily";
So you assign sdodge up to three times. A waste of cycles.
Ugly code.
Difficult to maintain.
On 09/09/2026 20:45, David Brown wrote:
On 09/09/2026 20:12, bart wrote:You said this:
Please stop paraphrasing me (and other people) incorrectly.˙ Instead,
According to David Brown and Scott Lurndal, that is a non-problem!
And according to DB, reducing a large, complex mass of header files
(of external library) into one compact file 95% smaller, would be a
waste of time.
just assume that you have misunderstood what people have said, and
continue discussing them in the relevant thread in the hope that you
eventually understand it.˙ I am happy to discuss many things with you,
but I find your repeated misquoting extremely frustrating.
As I showed in my timings, in real use, that [reducing headers by 95%] could, at most, reduce the compile time by about 15%.˙ It does notmatter how long it takes to read the SDL3 headers and throw them away, because it is not a useful task.
In an earlier post (09:18 BST today) you said:
˙ Trying to optimise or flatten header sets for some library would bea waste of effort - the effect is too minor.
Both sound very much as though consider it a waste of time.
You are also ignoring a simple fact: how large is a typical source file
size in C; 1000 lines maybe?
Well each .c file that includes SDK.h needs to first process 82,000 / unique/ lines of source, before getting around to those 1000 lines.
But that's also ignoring that a lot more than 82Kloc needs to be either processed or skipped since many are re-included: there are 466
#includes! In fact here are the figures from my compiler:
˙ Total lines processed:˙ 551,674
Of those, 150,000 are conditional false blocks that skipped over, but it still leaves 400,000 lines.
This is 400Kloc for a ONE module of 1Kloc, and there could be other
modules pulling in the same header. So, I would say that is quite
dominant, for a non-optimising build.
On 09/09/2026 22:26, Janis Papanagnou wrote:
On 2026-09-09 20:12, bart wrote:Why? What is the advantage of so much micromanagement?
On 09/09/2026 02:59, Waldek Hebisch wrote:
[...]
Some even specify individual names to be imported from a module. What
a complete waste of time!
I fear you're just exposing your very limited perception and experience
here. (And en passant probably also the mindset of a technocratic paper
pusher than a software designer.)
Myself I'm favoring _to be able_ to import only what I need and not the
whole bunch of existing things of a module (with all potential implicit
and explicit consequences).
On 2026-09-09 16:23, Richard Harnden wrote:
On 09/09/2026 11:05, fir wrote:
Janis Papanagnou pisze:
On 2026-09-09 10:38, David Brown wrote:
On 09/09/2026 10:13, Janis Papanagnou wrote:
On 2026-09-08 13:47, bart wrote:
On 08/09/2026 01:02, Waldek Hebisch wrote:
= DIS 4) it collides with normal math world and normal world meaning
of "=" which are not quite assign - though it kinda painlessly may be
used to assign
Yes, that's a long and well-known disadvantage of '=' for assignments.
But there need not be a problem using '=' for assignments and also
for comparisons if the respective languages could tell them apart by
context and with appropriate semantic rules.
let a=2
without let a=2 is if-like hipothesis and let changes its meaning
so in c this let is like skipped and its standable. but.... (but
there are some subtle reservations
= ADV 5) it has also some advantage its traditional now/widely taken
(should not make thuis numbered list becouse i wanted to list := dis/
adv but then it shows i talk on =)
overally fact imo is assigns in c imo shouldnt be a=2 like,
you ned close dynamic sign but not this - i made 2 proposition there
is yet third
(Please, for the sake of the people that haven't killfiled you, use an online-translator to create comprehensible texts! - In case that your
native language *is* English I suggest to translate your text to some
other language and then back to English; the translators are obviously
good enough to fix your language or writing problems in that process.)
On 2026-09-10 00:30, bart wrote:
On 09/09/2026 22:26, Janis Papanagnou wrote:
[...]
Myself I'm favoring _to be able_ to import only what I need and not the
whole bunch of existing things of a module (with all potential implicit
and explicit consequences).
Why? What is the advantage of so much micromanagement?
The advantages of _modularity_ are for example to structure entities
that may be typically used together or to restrict yourself to the
subset of what you actually need.
(Neither an "include all" nor an
"include value_x_of_y" are usually sensible choices!) - You may want
to inspect the various options you have in other languages (inspect,
just for example, Java - beyond any personal liking of that language).
Is even the pain of having to do '#include <string.h>' not enough when
your code uses string functions, you would prefer to list them
individually too?!
No. What makes you think so? (And it is also no "pain" for me, BTW.)
But if all I need from the string class is, say, strcmp() then it is completely sensible to be able to include just that.
If it turns out that I need more I can include the whole "tool-chest"
(unless I get name clashes that a specific import would prevent).
Ideally you may control the import level (all, or selected items) to
your needs.
For example; my recent Algol 68 option parser defines the necessaryDoes Algol68 have such a feature? Does it even have modules?!
types and the (exported) function to handle the options. (All other internally used functions are hidden.) Or my array shuffler function
uses a swap operator, but since that is useful also generally I have
it visible in the module for use. In an encryption module I have the functions to create the subkey-sequence, the encryption/decryption
functions, data types resembling the entities you use with these
functions (e.g. 64-bit and 56-bit integrals). - So these facilities
provide all the _necessary_ in one module each. But there may also
be tool-chests-like modules;
and in this case you may prefer to just
pick the requested entities if the subset is small.
- For example my
ansi-controls module is a huge collection of functions; I'd like to
just pick the 5 or 6 functions I'm needing (but with the language I'm
using I can only pick an include file as a whole; unless I split the functions myself in sub-groups - good that we spoke about that; I'll
probably do that to separate the colors at least - anyway there's a
lot of entries that I'd prefer not to pollute my name space).
Note also that languages may provide structuring means that allow an
own level of modularization. Consider for example the object oriented languages where you collect things that belong together in classes.
BTW, you may want to consider reading more about modularity; B. Meyer
has an introductory small chapter about aspects in his "OO Software Development" book. (I'm sure there's plenty other resources.) You can
also search the Web on principles and advantages including control of modularization.
An enumeration set may have hundreds of names; do you have to list all
of them? That would be insane.
Yes, that would be insane. - How do you manage it to breed such absurd ideas?!
You might as well put each entity into its own module, and have a
subset of 1000 modules to manage instead - in each of the 1000 functions.
Why would you do that? I wouldn't. - You completely missed the point.
You people seem to like making life difficult. Well, go ahead!
Nonsense. - You seem to be stubbornly focused on some "idee fixe" you
have, incapable of evading your own mental cage.
But that's also not that "simple" or clear as you pretend. - Consider
for example C++ with its stream output; would you really write as in
this _simple_ example - there's yet more common things with streams,
like standard-modifiers (e.g. std::oct, std:: setw()) that may often complicate the expression WRT legibility! - always 'std::' like
˙ std::cout << "hello world" << std::endl;
or prefer an extensive all-is-the-least-"burden" directive
˙ using std;
and for all the many output commands just the better legible
˙ cout << "hello world" << endl;
The point is that you should have the possibility to modularize, andThe modularisation is there, but this isn't really controlling it. It's
to control it.
˙public class HelloWorld {
˙˙˙ public static void main(String[] args) {
˙˙˙˙˙˙˙ System.out.println("Hello, World");
˙˙˙ }
˙}
Whereas mine looks like so:
˙ proc main =
˙˙˙˙˙ println "Hello, World"
˙ end
On 2026-09-10 00:52, Keith Thompson wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
(Please, for the sake of the people that haven't killfiled you, use an
online-translator to create comprehensible texts! - In case that your
native language *is* English I suggest to translate your text to some
other language and then back to English; the translators are obviously
good enough to fix your language or writing problems in that process.)
The above was addressed to "fir". [...]
Yes.
[ background info snipped ]
I suggest that one more attempt to get fir to write clearly is
unlikely to be effective.˙ I've solved the problem for myself by
adding him to my killfile.
Thanks for the the info and warning. - Actually he is already in my
killfile, so I see his writings only when he gets quoted my someone.
Janis
bart pisze:
˙˙public class HelloWorld {
˙˙˙˙ public static void main(String[] args) {
˙˙˙˙˙˙˙˙ System.out.println("Hello, World");
˙˙˙˙ }
˙˙}
Whereas mine looks like so:
˙˙ proc main =
˙˙˙˙˙˙ println "Hello, World"
˙˙ end
in c it would be
main() printf("Hello, World");
if they would allow skkip {}
main() { printf("Hello, World"); }
˙in this short cases like it is in ifs
in my proto-extended-c i compile˙ it is
main { printf "Hello, World" }
it is from this compiled example (this void i should remove some way
but it was under work and im not touching it recently)
˙void ProcessMouseMove mouse_x mouse_y { }
˙void OnResize { RunFrame }
˙void main
˙{
˙˙˙˙˙˙˙˙ RegisterMouseMove &ProcessMouseMove
˙˙˙˙˙˙˙˙ RegisterKeyDown &ProcessKeyDown
˙˙˙˙˙˙˙˙ RegisterOnResize &OnResize
˙˙˙˙˙˙˙˙ RegisterRunFrame &RunFrame
˙˙˙˙˙˙˙˙ SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1
˙˙˙˙˙˙˙˙ SetupWindow4 " Example Green Fire App compiled by Furia \x00"
20 20˙ 0.9 0.9 600
˙}
fir pisze:
bart pisze:this void is beoouse i must denote definition and yet has no idea
˙˙public class HelloWorld {
˙˙˙˙ public static void main(String[] args) {
˙˙˙˙˙˙˙˙ System.out.println("Hello, World");
˙˙˙˙ }
˙˙}
Whereas mine looks like so:
˙˙ proc main =
˙˙˙˙˙˙ println "Hello, World"
˙˙ end
in c it would be
main() printf("Hello, World");
if they would allow skkip {}
main() { printf("Hello, World"); }
˙˙in this short cases like it is in ifs
in my proto-extended-c i compile˙ it is
main { printf "Hello, World" }
it is from this compiled example (this void i should remove some way
but it was under work and im not touching it recently)
˙˙void ProcessMouseMove mouse_x mouse_y { }
˙˙void OnResize { RunFrame }
˙˙void main
˙˙{
˙˙˙˙˙˙˙˙˙ RegisterMouseMove &ProcessMouseMove
˙˙˙˙˙˙˙˙˙ RegisterKeyDown &ProcessKeyDown
˙˙˙˙˙˙˙˙˙ RegisterOnResize &OnResize
˙˙˙˙˙˙˙˙˙ RegisterRunFrame &RunFrame
˙˙˙˙˙˙˙˙˙ SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1
˙˙˙˙˙˙˙˙˙ SetupWindow4 " Example Green Fire App compiled by Furia
\x00" 20 20˙ 0.9 0.9 600
˙˙}
from this gemeral bara naked function all conventios im quite happy
gere function calls˙ i name "logical lines" as compiler just breaks
lines on logical lines on newline or ","
so
˙void main
˙˙ {
˙˙˙˙˙˙˙˙˙˙ SetSleepValue 5
˙˙˙˙˙˙˙˙˙ SetScaleOnResize 0
˙˙˙˙˙˙˙˙˙˙ Set3dDrawingMode 1
˙˙˙˙˙˙˙˙˙˙ SetupWindow4 " Example Green Fire App compiled by Furia \x00"
˙20 20˙ 0.9 0.9 600
˙˙ }
ise the same as
void main
˙˙ {
˙˙˙ SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1,
SetupWindow4 " Example Green Fire App compiled by Furia \x00"
˙20 20˙ 0.9 0.9 600
˙˙ }
also blocks may be instead of form {a,b,c,d,e} be a,b,c,d,e;
so above may be
void main
˙˙˙ SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1,
SetupWindow4 " Example Green Fire App compiled by Furia \x00"
˙20 20˙ 0.9 0.9 600 ;
as fay as i remember (im not sure right now if function ending sign i
chose as ";" "." ";." or smthe (possibly it need to be something like ;.
but it yet is not decided
there also may be optional :
void main: SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1, SetupWindow4 " Example Green Fire App compiled by Furia \x00"
˙20 20˙ 0.9 0.9 600;
i emen is optional if after definition header there is newline
those things are somewhat clear (maybe this ending function if there is
no {} is not cleer but other seem clear
but many things are yet not resolved (like if statements or even im not
sure as to assigments, for loops -s till not chosen
but the bare naked form of function calls is imo impressive
fir pisze:
fir pisze:
bart pisze:this void is beoouse i must denote definition and yet has no idea
˙˙public class HelloWorld {
˙˙˙˙ public static void main(String[] args) {
˙˙˙˙˙˙˙˙ System.out.println("Hello, World");
˙˙˙˙ }
˙˙}
Whereas mine looks like so:
˙˙ proc main =
˙˙˙˙˙˙ println "Hello, World"
˙˙ end
in c it would be
main() printf("Hello, World");
if they would allow skkip {}
main() { printf("Hello, World"); }
˙˙in this short cases like it is in ifs
in my proto-extended-c i compile˙ it is
main { printf "Hello, World" }
it is from this compiled example (this void i should remove some way
but it was under work and im not touching it recently)
˙˙void ProcessMouseMove mouse_x mouse_y { }
˙˙void OnResize { RunFrame }
˙˙void main
˙˙{
˙˙˙˙˙˙˙˙˙ RegisterMouseMove &ProcessMouseMove
˙˙˙˙˙˙˙˙˙ RegisterKeyDown &ProcessKeyDown
˙˙˙˙˙˙˙˙˙ RegisterOnResize &OnResize
˙˙˙˙˙˙˙˙˙ RegisterRunFrame &RunFrame
˙˙˙˙˙˙˙˙˙ SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1
˙˙˙˙˙˙˙˙˙ SetupWindow4 " Example Green Fire App compiled by Furia
\x00" 20 20˙ 0.9 0.9 600
˙˙}
from this gemeral bara naked function all conventios im quite happy
gere function calls˙ i name "logical lines" as compiler just breaks
lines on logical lines on newline or ","
so
˙˙void main
˙˙˙ {
˙˙˙˙˙˙˙˙˙˙˙ SetSleepValue 5
˙˙˙˙˙˙˙˙˙˙ SetScaleOnResize 0
˙˙˙˙˙˙˙˙˙˙˙ Set3dDrawingMode 1
˙˙˙˙˙˙˙˙˙˙˙ SetupWindow4 " Example Green Fire App compiled by Furia \x00"
˙˙20 20˙ 0.9 0.9 600
˙˙˙ }
ise the same as
void main
˙˙˙ {
˙˙˙˙ SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1,
SetupWindow4 " Example Green Fire App compiled by Furia \x00"
˙˙20 20˙ 0.9 0.9 600
˙˙˙ }
also blocks may be instead of form {a,b,c,d,e} be a,b,c,d,e;
so above may be
void main
˙˙˙˙ SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1,
SetupWindow4 " Example Green Fire App compiled by Furia \x00"
˙˙20 20˙ 0.9 0.9 600 ;
as fay as i remember (im not sure right now if function ending sign i
chose as ";" "." ";." or smthe (possibly it need to be something like ;.
but it yet is not decided
or maybe it was ";;" as an end - probably this should be just some
unicode sign as ending function definition denoter (even something like small/medium rectangle ) but im trying to go as far in this syntax
thining and cleaning as far as i can go
there also may be optional :
void main: SetSleepValue 5, SetScaleOnResize 0, Set3dDrawingMode 1,
SetupWindow4 " Example Green Fire App compiled by Furia \x00"
˙˙20 20˙ 0.9 0.9 600;
i emen is optional if after definition header there is newline
those things are somewhat clear (maybe this ending function if there
is no {} is not cleer but other seem clear
but many things are yet not resolved (like if statements or even im
not sure as to assigments, for loops -s till not chosen
but the bare naked form of function calls is imo impressive
bart pisze:
˙˙public class HelloWorld {
˙˙˙˙ public static void main(String[] args) {
˙˙˙˙˙˙˙˙ System.out.println("Hello, World");
˙˙˙˙ }
˙˙}
Whereas mine looks like so:
˙˙ proc main =
˙˙˙˙˙˙ println "Hello, World"
˙˙ end
in c it would be
main() printf("Hello, World");
if they would allow skkip {}
main() { printf("Hello, World"); }
˙in this short cases like it is in ifs
in my proto-extended-c i compile˙ it is
main { printf "Hello, World" }
it is from this compiled example (this void i should remove some way
but it was under work and im not touching it recently)
˙void ProcessMouseMove mouse_x mouse_y { }
On 10/09/2026 13:37, fir wrote:
bart pisze:
˙˙public class HelloWorld {
˙˙˙˙ public static void main(String[] args) {
˙˙˙˙˙˙˙˙ System.out.println("Hello, World");
˙˙˙˙ }
˙˙}
Whereas mine looks like so:
˙˙ proc main =
˙˙˙˙˙˙ println "Hello, World"
˙˙ end
in c it would be
main() printf("Hello, World");
In C it would be:
˙˙ #include <stdio.h>
˙˙ int main(void) {
˙˙˙˙˙ printf("Hello, World\n");
˙˙ }
From C23, you can get rid of the 'void' (you can do that now, but it
has a different meaning).
if they would allow skkip {}
main() { printf("Hello, World"); }
˙˙in this short cases like it is in ifs
in my proto-extended-c i compile˙ it is
main { printf "Hello, World" }
it is from this compiled example (this void i should remove some way
but it was under work and im not touching it recently)
˙˙void ProcessMouseMove mouse_x mouse_y { }
C generally has too much punctuation, but you can also have too little!
Your example doesn't specify parameter types for example. With those in place, then you can have syntax that looks like:
˙˙ A B C D E F {}
A is the return type (a user-defined type); B is the function name; D is
a parameter of type C; and F is a parameter of type F. There is little structure.
Further, if this is a function all:
˙˙ F G H I J
Then you don't know if this means F(G, H, I, J), or F (G, H(I), J) etc.
Some languages manage it but it needs very careful design and a set of rules.
Further, if this is a function all:
˙˙ F G H I J
Then you don't know if this means F(G, H, I, J), or F (G, H(I), J) etc.
bart pisze:
Further, if this is a function all:
˙˙˙ F G H I J
Then you don't know if this means F(G, H, I, J), or F (G, H(I), J) etc.
this is not a problem in my bare-naked forms tuday as
it would be
˙ F G (H I) J
then you see F is function all that takes 3 args and H is a function
call that takes one
so this seem totally no problem,
bart pisze:
Further, if this is a function all:
˙˙˙ F G H I J
Then you don't know if this means F(G, H, I, J), or F (G, H(I), J) etc.
this is not a problem in my bare-naked forms tuday as
it would be
˙ F G (H I) J
then you see F is function all that takes 3 args and H is a function
call that takes one
so this seem totally no problem, but types in headers what you mention earlier is a problem..but for now as i sait i only work on "new B"
who knows mayne i should call this language as B i know there is a
language b but maybe it is lowercase ba and i could use bigcase B ;c
On 10/09/2026 15:03, fir wrote:
bart pisze:
Further, if this is a function all:
˙˙˙ F G H I J
Then you don't know if this means F(G, H, I, J), or F (G, H(I), J) etc.
this is not a problem in my bare-naked forms tuday as
it would be
˙˙ F G (H I) J
then you see F is function all that takes 3 args and H is a function
call that takes one
That makes it too strict. C has variadic functions. Some languages have optional arguments with default values. Some languages are dynamically
types so you don't know at compile-time (and the reader can't tell) how
many arguments F takes.
so this seem totally no problem,
Try it with a real example, such as:
˙˙˙ succeeded =˙ tdefl_init pComp˙ pPut_buf_func˙ pPut_buf_user˙ flags
== TDEFL_STATUS_OKAY ;
˙˙˙ succeeded = succeeded &&˙ tdefl_compress_buffer pComp˙ pBuf
buf_len˙ TDEFL_FINISH == TDEFL_STATUS_DONE
These have had parentheses and commas removed. There is also this:
˙˙˙˙ F G H I + J
Even if you know that F takes two arguments, and H takes one, which of
these is the intended meaning:
˙˙˙˙ F(G, H(I) + J)
˙˙˙˙ F(G, H(I)) + J
These have had parentheses and commas removed. There is also this:
˙˙˙˙ F G H I + J
Even if you know that F takes two arguments, and H takes one, which of
these is the intended meaning:
˙˙˙˙ F(G, H(I) + J)
˙˙˙˙ F(G, H(I)) + J
bart pisze:
These have had parentheses and commas removed. There is also this:
˙˙˙˙˙ F G H I + J
Even if you know that F takes two arguments, and H takes one, which of
these is the intended meaning:
˙˙˙˙˙ F(G, H(I) + J)
˙˙˙˙˙ F(G, H(I)) + J
F G H I + J
this above s function f that takes 3 arguments G H and I+J
Try it with a real example, such as:
˙˙˙˙ succeeded =˙ tdefl_init pComp˙ pPut_buf_func˙ pPut_buf_user˙ flags
== TDEFL_STATUS_OKAY ;
˙˙˙˙ succeeded = succeeded &&˙ tdefl_compress_buffer pComp˙ pBuf
buf_len˙ TDEFL_FINISH == TDEFL_STATUS_DONE
fir pisze:
bart pisze:
These have had parentheses and commas removed. There is also this:
˙˙˙˙˙ F G H I + J
Even if you know that F takes two arguments, and H takes one, which
of these is the intended meaning:
˙˙˙˙˙ F(G, H(I) + J)
˙˙˙˙˙ F(G, H(I)) + J
F G H I + J
this above s function f that takes 3 arguments G H and I+J
ypu got
function arg arg arg arg arg
(always..at least if the first one is function name, if it is something another˙ maybe i will change it but as for now it seems its always a function, it cant be int as int would be
_g (initialisation) or g_ (assigment)
so d jkd d d lkjd djl is always faaaaa type (here it would not compile i guess)
so if you got a s d (g d f b) j k˙ it is faa(faaa)aa and so on
fir pisze:
fir pisze:
bart pisze:
These have had parentheses and commas removed. There is also this:
˙˙˙˙˙ F G H I + J
Even if you know that F takes two arguments, and H takes one, which
of these is the intended meaning:
˙˙˙˙˙ F(G, H(I) + J)
˙˙˙˙˙ F(G, H(I)) + J
F G H I + J
this above s function f that takes 3 arguments G H and I+J
ypu got
function arg arg arg arg arg
(always..at least if the first one is function name, if it is
something another˙ maybe i will change it but as for now it seems its
always a function, it cant be int as int would be
_g (initialisation) or g_ (assigment)
so d jkd d d lkjd djl is always faaaaa type (here it would not compile
i guess)
so if you got a s d (g d f b) j k˙ it is faa(faaa)aa and so on
i got kinda more troubles with function returning more values than 1
(as i want to have it)
now i consider
_x_y foo 2 3 4 // (int x, int y) = foo(2,3,4)
x_ _y foo 3 4 5 // (x,˙ int y) = foo(2,3,4)
fir pisze:
Try it with a real example, such as:
˙˙˙˙˙ succeeded =˙ tdefl_init pComp˙ pPut_buf_func˙ pPut_buf_user
flags == TDEFL_STATUS_OKAY ;
˙˙˙˙˙ succeeded = succeeded &&˙ tdefl_compress_buffer pComp˙ pBuf
buf_len˙ TDEFL_FINISH == TDEFL_STATUS_DONE
im not sure what you mean hera bove but with this e conventions im
talkin abouts its
succeeded =˙ tdefl_init( pComp,˙ pPut_buf_func,˙ pPut_buf_user,˙ flags== TDEFL_STATUS_OKAY) ;
andAnd here's the original for this:
succeeded = succeeded &&˙ tdefl_compress_buffer( pComp , pBuf, buf_len, TDEFL_FINISH == TDEFL_STATUS_DONE);
fir pisze:
i got kinda more troubles with function returning more values than 1
(as i want to have it)
now i consider
_x_y foo 2 3 4 // (int x, int y) = foo(2,3,4)
x_ _y foo 3 4 5 // (x,˙ int y) = foo(2,3,4)
this above would need some decisions as the meaning of above would
have different meaning if foo returns onlu 1 value
like
x_ _y f //sets x y if foo returns 2 values
x_ _y f // may be˙ x= (int y = f() ) if f returns one and it is a
question what allow whad disallow and so on,
but this pure naked normal form "d e r g :' is rather totally clear
On 10/09/2026 15:59, fir wrote:
fir pisze:
Try it with a real example, such as:
˙˙˙˙˙ succeeded =˙ tdefl_init pComp˙ pPut_buf_func˙ pPut_buf_user
flags == TDEFL_STATUS_OKAY ;
˙˙˙˙˙ succeeded = succeeded &&˙ tdefl_compress_buffer pComp˙ pBuf
buf_len˙ TDEFL_FINISH == TDEFL_STATUS_DONE
im not sure what you mean hera bove but with this e conventions im
talkin abouts its
succeeded =˙ tdefl_init( pComp,˙ pPut_buf_func,˙ pPut_buf_user,
flags== TDEFL_STATUS_OKAY) ;
Not bad, but this is the original:
˙ succeeded = (tdefl_init(pComp, pPut_buf_func, pPut_buf_user, flags)
== TDEFL_STATUS_OKAY);
andAnd here's the original for this:
succeeded = succeeded &&˙ tdefl_compress_buffer( pComp , pBuf,
buf_len, TDEFL_FINISH == TDEFL_STATUS_DONE);
˙˙˙ succeeded = succeeded && (tdefl_compress_buffer(pComp, pBuf,
buf_len, TDEFL_FINISH) == TDEFL_STATUS_DONE);
I think the parentheses and commas do a good job in removing ambiguity.
Although the originals probably had one pair of superfluous parentheses each, as '=='s precedence is already higher than both = and &&.
But, what are you planning with general expressions: will you still have operator precedences?
On 10/09/2026 17:15, fir wrote:
fir pisze:
i got kinda more troubles with function returning more values than 1
(as i want to have it)
now i consider
_x_y foo 2 3 4 // (int x, int y) = foo(2,3,4)
x_ _y foo 3 4 5 // (x,˙ int y) = foo(2,3,4)
this above would need some decisions as the meaning of above would
have different meaning if foo returns onlu 1 value
like
x_ _y f //sets x y if foo returns 2 values
x_ _y f // may be˙ x= (int y = f() ) if f returns one and it is a
question what allow whad disallow and so on,
but this pure naked normal form "d e r g :' is rather totally clear
This is all getting /very/ far from C.˙ Might it be a good time to start
a new thread in comp.lang.misc instead?
If you are serious about making his own language in some way, then I am
sure he would benefit from paying some attention to Bart's advice (I
might not like his language, or have any use of it, but there's no doubt
he has more experience than most in language design).
And maybe in comp.lang.misc the thread will attract others that have interest in new languages, or advice based on different language
experience.
Janis Papanagnou pisze:
On 2026-09-10 00:52, Keith Thompson wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
(Please, for the sake of the people that haven't killfiled you, use an >>>> online-translator to create comprehensible texts! - In case that your
native language *is* English I suggest to translate your text to some
other language and then back to English; the translators are obviously >>>> good enough to fix your language or writing problems in that process.)
The above was addressed to "fir". [...]
Yes.
[ background info snipped ]
I suggest that one more attempt to get fir to write clearly is
unlikely to be effective.˙ I've solved the problem for myself by
adding him to my killfile.
Thanks for the the info and warning. - Actually he is already in my
killfile, so I see his writings only when he gets quoted my someone.
Janis
welcome in keith team ;c
fir pisze:
Janis Papanagnou pisze:
On 2026-09-10 00:52, Keith Thompson wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
(Please, for the sake of the people that haven't killfiled you, use an >>>>> online-translator to create comprehensible texts! - In case that your >>>>> native language *is* English I suggest to translate your text to some >>>>> other language and then back to English; the translators are obviously >>>>> good enough to fix your language or writing problems in that process.) >>>>The above was addressed to "fir". [...]
Yes.
[ background info snipped ]
I suggest that one more attempt to get fir to write clearly is
unlikely to be effective.˙ I've solved the problem for myself by
adding him to my killfile.
Thanks for the the info and warning. - Actually he is already in my
killfile, so I see his writings only when he gets quoted my someone.
Janis
welcome in keith team ;c
anti-fir Keith's Team of funny asses
David Brown pisze:
this is theoretical c imo - c has some set of ideas internally and is
This is all getting /very/ far from C.˙ Might it be a good time to
start a new thread in comp.lang.misc instead?
If you are serious about making his own language in some way, then I
am sure he would benefit from paying some attention to Bart's advice
(I might not like his language, or have any use of it, but there's no
doubt he has more experience than most in language design).
And maybe in comp.lang.misc the thread will attract others that have
interest in new languages, or advice based on different language
experience.
"made" from this ideas so exploring those ideas ic C imo but more theoretical
i make some theory and some of it is more general (like say this last
things that objects are indeed knots/webs, or code jumping problem)but
its also a c if it uses c
On 10/09/2026 18:21, fir wrote:
David Brown pisze:
this is theoretical c imo - c has some set of ideas internally and is
This is all getting /very/ far from C.˙ Might it be a good time to
start a new thread in comp.lang.misc instead?
If you are serious about making his own language in some way, then I
am sure he would benefit from paying some attention to Bart's advice
(I might not like his language, or have any use of it, but there's no
doubt he has more experience than most in language design).
And maybe in comp.lang.misc the thread will attract others that have
interest in new languages, or advice based on different language
experience.
"made" from this ideas so exploring those ideas ic C imo but more
theoretical
i make some theory and some of it is more general (like say this last
things that objects are indeed knots/webs, or code jumping problem)but
its also a c if it uses c
No, it is not C.˙ You might have started off thinking about small
changes to C, but you are now talking about something completely different.
Either this is just a waste of time (and the fact that most of your
posts are replies to your own posts suggest that this is the case), or
you are really interested in making a new language - and comp.lang.misc would be a better place to discuss it.
David Brown pisze:
On 10/09/2026 18:21, fir wrote:
David Brown pisze:
this is theoretical c imo - c has some set of ideas internally and is
This is all getting /very/ far from C.˙ Might it be a good time to
start a new thread in comp.lang.misc instead?
If you are serious about making his own language in some way, then I
am sure he would benefit from paying some attention to Bart's advice
(I might not like his language, or have any use of it, but there's
no doubt he has more experience than most in language design).
And maybe in comp.lang.misc the thread will attract others that have
interest in new languages, or advice based on different language
experience.
"made" from this ideas so exploring those ideas ic C imo but more
theoretical
i make some theory and some of it is more general (like say this last
things that objects are indeed knots/webs, or code jumping problem)but
its also a c if it uses c
No, it is not C.˙ You might have started off thinking about small
changes to C, but you are now talking about something completely
different.
Either this is just a waste of time (and the fact that most of your
posts are replies to your own posts suggest that this is the case), or
you are really interested in making a new language - and
comp.lang.misc would be a better place to discuss it.
it is but you dont understand it becouse you have shallow view on c
in this context c is like an iceberg it has its surface (i call it skin)
but it has the rationale and deep design decisions under the water
surface level... so if i prove for example that c typical "skin"
(i call it gothic (at least those part around(,,,,);˙ )
san be changed form
foo(a,b, "text",c);
into
foo a b "text" c
it is/are thesis on c not on different anguage - they are about
c consciousnes and about potential sjkin changes (and are also about new skinn too, thats right)
On 10/09/2026 18:21, fir wrote:
David Brown pisze:
Either this is just a waste of time (and the fact that most of your
posts are replies to your own posts suggest that this is the case), or
you are really interested in making a new language - and comp.lang.misc would be a better place to discuss it.
David Brown pisze:
On 10/09/2026 18:21, fir wrote:
David Brown pisze:
this is theoretical c imo - c has some set of ideas internally and is
This is all getting /very/ far from C.˙ Might it be a good time to
start a new thread in comp.lang.misc instead?
If you are serious about making his own language in some way, then I
am sure he would benefit from paying some attention to Bart's advice
(I might not like his language, or have any use of it, but there's
no doubt he has more experience than most in language design).
And maybe in comp.lang.misc the thread will attract others that have
interest in new languages, or advice based on different language
experience.
"made" from this ideas so exploring those ideas ic C imo but more
theoretical
i make some theory and some of it is more general (like say this last
things that objects are indeed knots/webs, or code jumping problem)but
its also a c if it uses c
No, it is not C.˙ You might have started off thinking about small
changes to C, but you are now talking about something completely
different.
Either this is just a waste of time (and the fact that most of your
posts are replies to your own posts suggest that this is the case), or
you are really interested in making a new language - and
comp.lang.misc would be a better place to discuss it.
it is but you dont understand it becouse you have shallow view on c
in this context c is like an iceberg it has its surface (i call it skin)
but it has the rationale and deep design decisions under the water
surface level... so if i prove for example that c typical "skin"
(i call it gothic (at least those part around(,,,,);˙ )
san be changed form
foo(a,b, "text",c);
into
foo a b "text" c
it is/are thesis on c not on different anguage - they are about
c consciousnes and about potential sjkin changes (and are also about new skinn too, thats right)
David Brown pisze:
On 10/09/2026 18:21, fir wrote:
David Brown pisze:
this is theoretical c imo - c has some set of ideas internally and is
This is all getting /very/ far from C.˙ Might it be a good time to
start a new thread in comp.lang.misc instead?
If you are serious about making his own language in some way, then I
am sure he would benefit from paying some attention to Bart's advice
(I might not like his language, or have any use of it, but there's
no doubt he has more experience than most in language design).
And maybe in comp.lang.misc the thread will attract others that have
interest in new languages, or advice based on different language
experience.
"made" from this ideas so exploring those ideas ic C imo but more
theoretical
i make some theory and some of it is more general (like say this last
things that objects are indeed knots/webs, or code jumping problem)but
its also a c if it uses c
No, it is not C.˙ You might have started off thinking about small
changes to C, but you are now talking about something completely
different.
Either this is just a waste of time (and the fact that most of your
posts are replies to your own posts suggest that this is the case), or
you are really interested in making a new language - and
comp.lang.misc would be a better place to discuss it.
it is but you dont understand it becouse you have shallow view on c
in this context c is like an iceberg it has its surface (i call it skin)
but it has the rationale and deep design decisions under the water
surface level... so if i prove for example that c typical "skin"
(i call it gothic (at least those part around(,,,,);˙ )
san be changed form
foo(a,b, "text",c);
into
foo a b "text" c
it is/are thesis on c not on different anguage - they are about
c consciousnes and about potential sjkin changes (and are also about new skinn too, thats right)
fir pisze:
David Brown pisze:
On 10/09/2026 18:21, fir wrote:
David Brown pisze:
this is theoretical c imo - c has some set of ideas internally and is
This is all getting /very/ far from C.˙ Might it be a good time to
start a new thread in comp.lang.misc instead?
If you are serious about making his own language in some way, then
I am sure he would benefit from paying some attention to Bart's
advice (I might not like his language, or have any use of it, but
there's no doubt he has more experience than most in language design). >>>>>
And maybe in comp.lang.misc the thread will attract others that
have interest in new languages, or advice based on different
language experience.
"made" from this ideas so exploring those ideas ic C imo but more
theoretical
i make some theory and some of it is more general (like say this
last things that objects are indeed knots/webs, or code jumping
problem)but
its also a c if it uses c
No, it is not C.˙ You might have started off thinking about small
changes to C, but you are now talking about something completely
different.
Either this is just a waste of time (and the fact that most of your
posts are replies to your own posts suggest that this is the case),
or you are really interested in making a new language - and
comp.lang.misc would be a better place to discuss it.
it is but you dont understand it becouse you have shallow view on c
in this context c is like an iceberg it has its surface (i call it
skin) but it has the rationale and deep design decisions under the
water surface level... so if i prove for example that c typical "skin"
(i call it gothic (at least those part around(,,,,);˙ )
san be changed form
foo(a,b, "text",c);
into
foo a b "text" c
it is/are thesis on c not on different anguage - they are about
c consciousnes and about potential sjkin changes (and are also about
new skinn too, thats right)
you also my not damn know how hard it is
in c i make i would say two work - one s those 'semantic' (?) ideas
(liek one core of cpu on assembly level seing state of other core
for example..great idea of makin cpu's and assembly great again ;c (potentially as im not sure how it would work))
but i also do this skin work and this skin work is hard
for example ide of
_x 640
_y 480
as a syntax for int declarations seem neat
but when considered in expressions like
foo _x 640 _y 480
(which is foo(int x =640, int y = 480);
seems problematic becouse in eye it may look more like foo
takes 4 args etc)
such thing as
foo x'640 y'480
where ' can be replaced by some unicode
would spare 2 spaces
so maybe
x'640
y'480
is better as initialisation - but it in turn looks less neat
yet all this mus be compatible with all other syntaxes or maybe
i should say COMPATIBLE WITH ALL other syntaxes
so its hard work that should be valued - its not a trash
(compared to what soem othar people in languages do do they
make often trash - they design decision are flawedon first flawed step
so where they go in 100th step? (nowhere as they will not go )
so if you got a s d (g d f b) j k
it is faa(faaa)aa and so on
fir pisze:
so if you got a s d (g d f b) j k
it is faa(faaa)aa and so on
so here it is simple as i said if firs thing is function
then all that things are "faa(fa)aa(faa)aaa" type
buy i also consider more powerfull
"aafaaa" thing
like
"ala" cat "bala"
//cat("ala", "bala")
this makes more problems but it has more power
would be harder to reed for exampla
˙foo a b cat d e g
but whwn using meaningfull names it should probably be ok, may also use conventions like naming functions big case and variables lowcase, also anyone can use ()
Foo a b Cat d e g
still doder need what args of Cat are
Foo a (b Cat d) e g
yet there is also a problem of return values
x_ Foo a (z_ b Cat d) e u_ g
//same as above but also makes 3 assigns
i got also havy problem with function definitions header(in more general case) now i consider something like
Just defining the symbol is fine - for use as a pure header guard, where
the check is with "#ifndef" or "#ifdef", defining it to a value has no
added value.˙ Adding the "1" in that example was done without thinking.
On 9/9/2026 5:43 AM, David Brown wrote:
[...]
Just defining the symbol is fine - for use as a pure header guard,________
where the check is with "#ifndef" or "#ifdef", defining it to a value
has no added value.˙ Adding the "1" in that example was done without
thinking.
#ifndef __NUMBER_GENERATOR_H__
#define __NUMBER_GENERATOR_H__ 1
________
Is that __* non conformant? Does it breach the impl name prefix space?
On 10/09/2026 00:30, bart wrote:
On 09/09/2026 22:26, Janis Papanagnou wrote:[...]
[...][...]
Each type of import has its own advantages and disadvantages.
Type 1 would need micro-management if you want a lot of symbols from a module.˙ But if you only need a small number, it can keep things neat -
you only see what you actually want to use.˙ And if the imported module
only really exports a single name (like "my_class.py" exporting
"My_Class"), it's a neat solution that avoids later code clutter from
having to specify the module name.
Type 2 lets you immediately use all the identifiers from the module, but causes a lot of problems if things change in the future.˙ Maybe your own code has a function "fluff", and a later version of "foobar.py" also
adds a function "fluff".˙ That is not going to be good.
Type 3 lets you conveniently import all the exported symbols from the module, but you need to specify the namespace when using them.
As I see it, Janis favours that kind of flexibility for modules (though
of course the details may differ for different languages).
You seem to be favouring just type 2 - or even a "from * import *"
solution.˙ That might be convenient for a personal language where you
are the only one ever writing the code - you know there are no
collisions, because you wrote everything.˙ For anyone else, working
outside a bubble, it is unscalable.
On 2026-09-10 09:48, David Brown wrote:
On 10/09/2026 00:30, bart wrote:
On 09/09/2026 22:26, Janis Papanagnou wrote:[...]
[...][...]
Each type of import has its own advantages and disadvantages.
Type 1 would need micro-management if you want a lot of symbols from a
module.˙ But if you only need a small number, it can keep things neat
- you only see what you actually want to use.˙ And if the imported
module only really exports a single name (like "my_class.py" exporting
"My_Class"), it's a neat solution that avoids later code clutter from
having to specify the module name.
Type 2 lets you immediately use all the identifiers from the module,
but causes a lot of problems if things change in the future.˙ Maybe
your own code has a function "fluff", and a later version of
"foobar.py" also adds a function "fluff".˙ That is not going to be good.
Type 3 lets you conveniently import all the exported symbols from the
module, but you need to specify the namespace when using them.
As I see it, Janis favours that kind of flexibility for modules
(though of course the details may differ for different languages).
Since you mentioned me - and since I don't intend after my thorough explanation to spend yet more time with bart's posts about it - let
me confirm your interpretation, and give an example from practice.
Note also that none of the languages I'm currently using is supporting
that principle - there's no "best" language in that respect, although
some are closer to an ideal modularization than others. (Some recent languages [that I don't know] may do a better job here, I'd expect.)
Once I needed a function to produce Gaussian noise - and nothing else!
(Back then I used, I think, the Fortran IMSL library.) - In a modern modules-supporting environment I'd have liked to have something like
˙ use imsl.math.rand.gauss
I don't want the whole library, nor the whole math package, nor all
the random functions. I want them neither pollute my namespace, nor
do I want that libraries, library components, or functions are even considered for inclusion, neither on the program text level, nor at
the binary module level, if they are not needed.
In case of name clashes that happen despite a pinpointed inclusion
there's still an optional qualification syntax necessary. - In case
of the above example the "structuring path" could be used for that,
say, for example, something like˙ rand.gauss˙ and˙ matrix.gauss .
You seem to be favouring just type 2 - or even a "from * import *"
solution.˙ That might be convenient for a personal language where you
are the only one ever writing the code - you know there are no
collisions, because you wrote everything.˙ For anyone else, working
outside a bubble, it is unscalable.
What I find annoying with his posts is that from within his bubble he's
not even trying to look outside his horizon,
His inept exaggerations, the sloppiness,
On 09/09/2026 23:07, Janis Papanagnou wrote:[...]
But there need not be a problem using '=' for assignments and also
for comparisons if the respective languages could tell them apart by
context and with appropriate semantic rules.
Agreed.˙ In my "dream language", assignment would be a statement, not an expression, which lets you use the same symbol.
Indeed, assignment
would be very rare - normally variables would be initialised once, and
never changed.
[...]
But also, the difference between you and me is that I devise my own solutions, and do not have to settle for someone else's decisions.
When you have to implement this stuff then you can't be
sloppy. Perhaps you're just jealous that my scheme isn't available in
your favourite language.
bart pisze:
On 10/09/2026 15:59, fir wrote:
fir pisze:
Try it with a real example, such as:
˙˙˙˙˙ succeeded =˙ tdefl_init pComp˙ pPut_buf_func˙ pPut_buf_user
flags == TDEFL_STATUS_OKAY ;
˙˙˙˙˙ succeeded = succeeded &&˙ tdefl_compress_buffer pComp˙ pBuf
buf_len˙ TDEFL_FINISH == TDEFL_STATUS_DONE
im not sure what you mean hera bove but with this e conventions im
talkin abouts its
succeeded =˙ tdefl_init( pComp,˙ pPut_buf_func,˙ pPut_buf_user,
flags== TDEFL_STATUS_OKAY) ;
Not bad, but this is the original:
˙˙ succeeded = (tdefl_init(pComp, pPut_buf_func, pPut_buf_user, flags)
== TDEFL_STATUS_OKAY);
thet would be
succeeded = (tdefl_init pComp˙ pPut_buf_func˙ pPut_buf_user˙ flags ) == TDEFL_STATUS_OKAY
andAnd here's the original for this:
succeeded = succeeded &&˙ tdefl_compress_buffer( pComp , pBuf,
buf_len, TDEFL_FINISH == TDEFL_STATUS_DONE);
˙˙˙˙ succeeded = succeeded && (tdefl_compress_buffer(pComp, pBuf,
buf_len, TDEFL_FINISH) == TDEFL_STATUS_DONE);
I think the parentheses and commas do a good job in removing ambiguity.
Although the originals probably had one pair of superfluous
parentheses each, as '=='s precedence is already higher than both =
and &&.
But, what are you planning with general expressions: will you still
have operator precedences?
if the comma and parenthesis are not needed why use them
esp as a most amount of code is like
˙void RunFrame advance
˙{
˙˙˙˙˙ Initialise,
˙˙˙˙˙ ClearFrameData 0x444444
˙˙˙˙˙ DrawLine3d 100.0˙˙ 100.0˙˙ 0.0˙˙˙˙ 100.0 -100.0 0.0˙˙˙ 0xffffff
˙˙˙˙˙ DrawLine3d 100.0˙ -100.0˙˙ 0.0˙˙˙ -100.0 -100.0 0.0˙˙˙ 0xffffff
˙˙˙˙˙ DrawLine3d -100.0 -100.0˙˙ 0.0˙˙˙ -100.0˙ 100.0 0.0˙˙˙ 0xffffff
˙˙˙˙˙ DrawLine3d -100.0˙ 100.0˙˙ 0.0˙˙˙˙ 100.0˙ 100.0 0.0˙˙˙ 0xffffff
˙˙˙˙˙ DrawDot3d 0.0 0.0 100.0˙˙ 20.0˙ 0x557788
˙˙˙˙˙ DrawDot3d 0.0 0.0 150.0˙˙ 30.0˙ 0x557722
˙˙˙˙˙ DrawDot3d 0.0 0.0 -100.0˙ 10.0˙ 0xaa7788
˙˙˙˙˙ InitSomeJointsFigures
˙˙˙˙˙ DrawCloud1, DrawCloud2,
˙˙˙˙ DrawCloud11, DrawCloud12, UpdateDotsBag, DrawDotsBag
˙FillRectangle2 10 10 20 20 color
˙˙ DrawSomeText2F 0xcccccc 0x666666 20 10 " %x \x00"˙˙ 0xffffff
˙˙ DrawSomeText2F 0xcccccc 0x666666 10 20 "hello, this is example
program compiled by fir's furia compiler \x00"
˙˙˙ DeawLines
˙˙˙ DrawTextByBalls "hello\x00" 0 0 0x999999
˙˙˙ DrawCubesCubeGeo
˙˙ BezierPatchTest
˙˙ space_pressed? FireDotFromCameraCurrentColor 0.0 0.0 100000 20
˙˙ a_pressed?!˙ FireDotFromCameraCurrentColor 1.0 0.0 10000 20
˙˙ f5_toggler? DrawManual
˙˙ DrawFloor 20000 30 0x555555
˙˙ DrawRawModel
˙}
i mean lot are "normal" simple calls and there is a lot of (,,,,);
to skip
as to operator precedence ofc its needed and as i said what i show
here is the part that is "resolved" but there are more complex
cases where it is not resolved yet
(for example for this many return values , operator form of functions
(as a would like to have "x foo y" where foo is a function and x y are arguments, and those float char types, some constructions like loops
and so on
On 10/09/2026 00:30, bart wrote:
On 09/09/2026 22:26, Janis Papanagnou wrote:Consider modules in Python, since that is a language with "real" modules
On 2026-09-09 20:12, bart wrote:Why? What is the advantage of so much micromanagement?
On 09/09/2026 02:59, Waldek Hebisch wrote:
[...]
Some even specify individual names to be imported from a module.
What a complete waste of time!
I fear you're just exposing your very limited perception and experience
here. (And en passant probably also the mindset of a technocratic paper
pusher than a software designer.)
Myself I'm favoring _to be able_ to import only what I need and not the
whole bunch of existing things of a module (with all potential implicit
and explicit consequences).
and with which many people are familiar.
# foobar.py
def foo() : return "foo"
def bar() : return "bar"
Another file user.py wants to use "foo" from "foobar.py".˙ They can do
so in three main ways :
1. Specific inclusion
from foobar import foo
x = foo()
2. Global namespace inclusion
from foobar import *
x = foo()
3. Module namespace inclusion
import foobar
x = foobar.foo()
Each type of import has its own advantages and disadvantages.
Type 1 would need micro-management if you want a lot of symbols from a module.˙ But if you only need a small number, it can keep things neat -
you only see what you actually want to use.
And if the imported module
only really exports a single name (like "my_class.py" exporting
"My_Class"), it's a neat solution that avoids later code clutter from
having to specify the module name.
Type 2 lets you immediately use all the identifiers from the module, but causes a lot of problems if things change in the future.˙ Maybe your own code has a function "fluff", and a later version of "foobar.py" also
adds a function "fluff".˙ That is not going to be good.
Type 3 lets you conveniently import all the exported symbols from the module, but you need to specify the namespace when using them.
As I see it, Janis favours that kind of flexibility for modules (though
of course the details may differ for different languages).
You seem to be favouring just type 2 - or even a "from * import *"
solution.
That might be convenient for a personal language where you
are the only one ever writing the code - you know there are no
collisions, because you wrote everything.˙ For anyone else, working
outside a bubble, it is unscalable.
bart <bc@freeuk.com> writes:
[...]
But also, the difference between you and me is that I devise my own
solutions, and do not have to settle for someone else's decisions.
And you insist on discussing your solutions in comp.lang.c.
I see you've posted to comp.lang.misc. I encourage you to do so more
often.
[...]
When you have to implement this stuff then you can't be
sloppy. Perhaps you're just jealous that my scheme isn't available in
your favourite language.
When you're the only user, you can get away with being sloppy and
covering only the use cases that apply to you.
On 10/09/2026 23:52, Keith Thompson wrote:[...]
I see you've posted to comp.lang.misc. I encourage you to do so more
often.
Besides nobody bothers with topicality any more.
[...]When you have to implement this stuff then you can't be
sloppy. Perhaps you're just jealous that my scheme isn't available in
your favourite language.
When you're the only user, you can get away with being sloppy and
covering only the use cases that apply to you.
On 9/9/2026 5:43 AM, David Brown wrote:
[...]
Just defining the symbol is fine - for use as a pure header guard,________
where the check is with "#ifndef" or "#ifdef", defining it to a value
has no added value.˙ Adding the "1" in that example was done without
thinking.
#ifndef __NUMBER_GENERATOR_H__
#define __NUMBER_GENERATOR_H__ 1
________
Is that __* non conformant? Does it breach the impl name prefix space?
David Brown pisze:
On 10/09/2026 18:21, fir wrote:
David Brown pisze:
Either this is just a waste of time (and the fact that most of your
posts are replies to your own posts suggest that this is the case), or
you are really interested in making a new language - and
comp.lang.misc would be a better place to discuss it.
how it suggest that? note thise are 'replies' maybe in some technical
sense of a usenet reader..but on thought /write level they are just continuation of thoughts/topic..its rather quite artificall to write ll
you got to say in one post and assume you have nothing to add ..i often
have things to add
On 10/09/2026 19:17, fir wrote:
David Brown pisze:
On 10/09/2026 18:21, fir wrote:
David Brown pisze:
Either this is just a waste of time (and the fact that most of your
posts are replies to your own posts suggest that this is the case),
or you are really interested in making a new language - and
comp.lang.misc would be a better place to discuss it.
how it suggest that? note thise are 'replies' maybe in some technical
sense of a usenet reader..but on thought /write level they are just
continuation of thoughts/topic..its rather quite artificall to write
ll you got to say in one post and assume you have nothing to add ..i
often have things to add
Public forums - like a Usenet group - are not like having a whiteboard
on your wall.˙ If you ask questions that are topical to the group, or
make comments or replies that are topical to the group, that's great.
When you ramble with wild ideas, post after post, that's just wasting everyone's time.˙ People don't give any feedback, and mostly skip them.
So please, write your ramblings on a bit of paper or a whiteboard.˙ When
you have something worth sharing with other people, and you want
feedback or help, post them to an appropriate group.˙ If it is actually about C, that's comp.lang.c.˙ If it is about a weird new language with
lots of Unicode signs and a very different syntax, comp.lang.misc is a better choice.
This is surely not difficult to understand.
David Brown pisze:
On 10/09/2026 19:17, fir wrote:
David Brown pisze:
On 10/09/2026 18:21, fir wrote:
David Brown pisze:
Either this is just a waste of time (and the fact that most of your
posts are replies to your own posts suggest that this is the case),
or you are really interested in making a new language - and
comp.lang.misc would be a better place to discuss it.
how it suggest that? note thise are 'replies' maybe in some technical
sense of a usenet reader..but on thought /write level they are just
continuation of thoughts/topic..its rather quite artificall to write
ll you got to say in one post and assume you have nothing to add ..i
often have things to add
Public forums - like a Usenet group - are not like having a whiteboard
on your wall.˙ If you ask questions that are topical to the group, or
make comments or replies that are topical to the group, that's great.
When you ramble with wild ideas, post after post, that's just wasting
everyone's time.˙ People don't give any feedback, and mostly skip them.
So please, write your ramblings on a bit of paper or a whiteboard.
When you have something worth sharing with other people, and you want
feedback or help, post them to an appropriate group.˙ If it is
actually about C, that's comp.lang.c.˙ If it is about a weird new
language with lots of Unicode signs and a very different syntax,
comp.lang.misc is a better choice.
This is surely not difficult to understand.
what you say is shallow looking on C so i cant agree... you try to
impose you shallow view (just some way like keith thompson want to
impose˙ his rigid rukles here that this group is only for standard freaks)
i may partially agree that some investigation in possible c syntax/skin
are somewhat intermediate - but those are intermediate results kinda
needed to obtain final conclusions
i dont much can do something with fact that some post dont interest you
- belive many posts who many wrote here not interest me also (like
things keith writes, or trigraph topic and many more)
(regular c stuff is also not so much interesting, its ok, but some
deeper c ideas much more interesting)
speaking about this whiteboard or blackboard : also not this group has
some historical value and people may be interested how this great new language by fir was born (great new B or great new C or great new D
or even more like great new E˙ or ? or í still problems with tha name
On 11/09/2026 13:13, fir wrote:
speaking about this whiteboard or blackboard : also not this group has
some historical value and people may be interested how this great new
language by fir was born (great new B or great new C or great new D
or even more like great new E˙ or ? or í still problems with tha name
If you're looking for a name for your new language ...
... might I suggest ?
Richard Harnden pisze:
On 11/09/2026 13:13, fir wrote:assuming that im right and youre part of history - youre get known for
speaking about this whiteboard or blackboard : also not this group
has some historical value and people may be interested how this great
new language by fir was born (great new B or great new C or great new D
or even more like great new E˙ or ? or í still problems with tha name
If you're looking for a name for your new language ...
... might I suggest ?
this - and its not so much glorious legacy
Richard Harnden pisze:
On 11/09/2026 13:13, fir wrote:assuming that im right and youre part of history - youre get known for
speaking about this whiteboard or blackboard : also not this group
has some historical value and people may be interested how this great
new language by fir was born (great new B or great new C or great new D
or even more like great new E˙ or ? or í still problems with tha name
If you're looking for a name for your new language ...
... might I suggest ?
this - and its not so much glorious legacy
fir pisze:
David Brown pisze:
On 10/09/2026 19:17, fir wrote:
David Brown pisze:
On 10/09/2026 18:21, fir wrote:
David Brown pisze:
Either this is just a waste of time (and the fact that most of your >>>>> posts are replies to your own posts suggest that this is the case), >>>>> or you are really interested in making a new language - and
comp.lang.misc would be a better place to discuss it.
how it suggest that? note thise are 'replies' maybe in some
technical sense of a usenet reader..but on thought /write level they
are just continuation of thoughts/topic..its rather quite artificall
to write ll you got to say in one post and assume you have nothing
to add ..i often have things to add
Public forums - like a Usenet group - are not like having a
whiteboard on your wall.˙ If you ask questions that are topical to
the group, or make comments or replies that are topical to the group,
that's great. When you ramble with wild ideas, post after post,
that's just wasting everyone's time.˙ People don't give any feedback,
and mostly skip them.
So please, write your ramblings on a bit of paper or a whiteboard.
When you have something worth sharing with other people, and you want
feedback or help, post them to an appropriate group.˙ If it is
actually about C, that's comp.lang.c.˙ If it is about a weird new
language with lots of Unicode signs and a very different syntax,
comp.lang.misc is a better choice.
This is surely not difficult to understand.
what you say is shallow looking on C so i cant agree... you try to
impose you shallow view (just some way like keith thompson want to
impose˙ his rigid rukles here that this group is only for standard
freaks)
i may partially agree that some investigation in possible c syntax/skin
are somewhat intermediate - but those are intermediate results kinda
needed to obtain final conclusions
i dont much can do something with fact that some post dont interest
you - belive many posts who many wrote here not interest me also (like
things keith writes, or trigraph topic and many more)
(regular c stuff is also not so much interesting, its ok, but some
deeper c ideas much more interesting)
speaking about this whiteboard or blackboard : also not this group has
some historical value and people may be interested how this great new language by fir was born (great new B or great new C or great new D
or even more like great new E˙ or ? or í still problems with tha name
if i took a way to use unicode maybe i should take unicode sign?
it will make all this printers to print unicode in papers so that would
be kinda new impact )
fir pisze:
fir pisze:
David Brown pisze:
On 10/09/2026 19:17, fir wrote:
David Brown pisze:
On 10/09/2026 18:21, fir wrote:
David Brown pisze:
Either this is just a waste of time (and the fact that most of
your posts are replies to your own posts suggest that this is the >>>>>> case), or you are really interested in making a new language - and >>>>>> comp.lang.misc would be a better place to discuss it.
how it suggest that? note thise are 'replies' maybe in some
technical sense of a usenet reader..but on thought /write level
they are just continuation of thoughts/topic..its rather quite
artificall to write ll you got to say in one post and assume you
have nothing to add ..i often have things to add
Public forums - like a Usenet group - are not like having a
whiteboard on your wall.˙ If you ask questions that are topical to
the group, or make comments or replies that are topical to the
group, that's great. When you ramble with wild ideas, post after
post, that's just wasting everyone's time.˙ People don't give any
feedback, and mostly skip them.
So please, write your ramblings on a bit of paper or a whiteboard.
When you have something worth sharing with other people, and you
want feedback or help, post them to an appropriate group.˙ If it is
actually about C, that's comp.lang.c.˙ If it is about a weird new
language with lots of Unicode signs and a very different syntax,
comp.lang.misc is a better choice.
This is surely not difficult to understand.
what you say is shallow looking on C so i cant agree... you try to
impose you shallow view (just some way like keith thompson want to
impose˙ his rigid rukles here that this group is only for standard
freaks)
i may partially agree that some investigation in possible c syntax/skin
are somewhat intermediate - but those are intermediate results kinda
needed to obtain final conclusions
i dont much can do something with fact that some post dont interest
you - belive many posts who many wrote here not interest me also
(like things keith writes, or trigraph topic and many more)
(regular c stuff is also not so much interesting, its ok, but some
deeper c ideas much more interesting)
speaking about this whiteboard or blackboard : also not this group has
some historical value and people may be interested how this great new
language by fir was born (great new B or great new C or great new D
or even more like great new E˙ or ? or í still problems with tha name
there is also an option of ? to consider
if i took a way to use unicode maybe i should take unicode sign?
it will make all this printers to print unicode in papers so that
would be kinda new impact )
fir pisze:
fir pisze:
fir pisze:
David Brown pisze:
On 10/09/2026 19:17, fir wrote:
David Brown pisze:
On 10/09/2026 18:21, fir wrote:
David Brown pisze:
Either this is just a waste of time (and the fact that most of
your posts are replies to your own posts suggest that this is the >>>>>>> case), or you are really interested in making a new language -
and comp.lang.misc would be a better place to discuss it.
how it suggest that? note thise are 'replies' maybe in some
technical sense of a usenet reader..but on thought /write level
they are just continuation of thoughts/topic..its rather quite
artificall to write ll you got to say in one post and assume you
have nothing to add ..i often have things to add
Public forums - like a Usenet group - are not like having a
whiteboard on your wall.˙ If you ask questions that are topical to
the group, or make comments or replies that are topical to the
group, that's great. When you ramble with wild ideas, post after
post, that's just wasting everyone's time.˙ People don't give any
feedback, and mostly skip them.
So please, write your ramblings on a bit of paper or a whiteboard.
When you have something worth sharing with other people, and you
want feedback or help, post them to an appropriate group.˙ If it is >>>>> actually about C, that's comp.lang.c.˙ If it is about a weird new
language with lots of Unicode signs and a very different syntax,
comp.lang.misc is a better choice.
This is surely not difficult to understand.
what you say is shallow looking on C so i cant agree... you try to
impose you shallow view (just some way like keith thompson want to
impose˙ his rigid rukles here that this group is only for standard
freaks)
i may partially agree that some investigation in possible c syntax/skin >>>> are somewhat intermediate - but those are intermediate results kinda
needed to obtain final conclusions
i dont much can do something with fact that some post dont interest
you - belive many posts who many wrote here not interest me also
(like things keith writes, or trigraph topic and many more)
(regular c stuff is also not so much interesting, its ok, but some
deeper c ideas much more interesting)
speaking about this whiteboard or blackboard : also not this group
has some historical value and people may be interested how this great
new language by fir was born (great new B or great new C or great new D
or even more like great new E˙ or ? or í still problems with tha name
there is also an option of ? to consider
this one may be clever as you may treat C as a mooon shape it suggest
that C might enetered a new mooon (black moon) and after this is˙ ?
phase - C rising again..assuming C and˙ ? are both parts of O
it is some kind of pleasing, but enough to take it?
if i took a way to use unicode maybe i should take unicode sign?
it will make all this printers to print unicode in papers so that
would be kinda new impact )
bart <bc@freeuk.com> writes:
When you have to implement this stuff then you can't be sloppy.
Perhaps you're just jealous
that my scheme isn't available in your favourite language.
bart <bc@freeuk.com> writes:
When you have to implement this stuff then you can't be sloppy.
You demonstrated you can be extremely sloppy in your thinking and
in your argumentation! That doesn't mean that you wouldn't be able
to "write programs" ("this stuff"), for sure. - Another example of
sloppy thinking and argumentation.
Perhaps you're just jealous
Your mindset is so primitive, naive, and erroneous; unprecedentedly
given your stubbornness. Your persistent habit of making guesses,
completely missing the point, topics, and characters, had regularly
been shown to be widely erroneous. - I see you can't just stop your ineffective tries. It won't lead you anywhere.
that my scheme isn't available in your favourite language.
I have no "favourite language". (In a couple languages there's some
concepts that I'd like to be more widely spread. - Not sure you're
capable of understanding that and notice the blatant difference!)
And you should meanwhile know that meaningless home-brewed languages
are neither of general interest nor of mine; but you seem to have a persisting mental hindrance to understand what is easy understandable
by others. - Just to be clear; I don't know that "my scheme" you're
talking about is because I'm not interested in your posts about your
personal tools.
(I also suggest to become a bit more honest about your "achievement"
with creating your tool unless it gets some minimum general relevance
beyond your micro-ecosystem. - Why don't you advertise and offer your
tools at any more appropriate place if you think they're so important, innovative, or generally useful?!)
Janis
Janis Papanagnou pisze:
lol, i told keith's team are funny asses..it needs some funcy answer:bart <bc@freeuk.com> writes:
When you have to implement this stuff then you can't be sloppy.
You demonstrated you can be extremely sloppy in your thinking and
in your argumentation! That doesn't mean that you wouldn't be able
to "write programs" ("this stuff"), for sure. - Another example of
sloppy thinking and argumentation.
Perhaps you're just jealous
Your mindset is so primitive, naive, and erroneous; unprecedentedly
given your stubbornness. Your persistent habit of making guesses,
completely missing the point, topics, and characters, had regularly
been shown to be widely erroneous. - I see you can't just stop your
ineffective tries. It won't lead you anywhere.
that my scheme isn't available in your favourite language.
I have no "favourite language". (In a couple languages there's some
concepts that I'd like to be more widely spread. - Not sure you're
capable of understanding that and notice the blatant difference!)
And you should meanwhile know that meaningless home-brewed languages
are neither of general interest nor of mine; but you seem to have a
persisting mental hindrance to understand what is easy understandable
by others. - Just to be clear; I don't know that "my scheme" you're
talking about is because I'm not interested in your posts about your
personal tools.
(I also suggest to become a bit more honest about your "achievement"
with creating your tool unless it gets some minimum general relevance
beyond your micro-ecosystem. - Why don't you advertise and offer your
tools at any more appropriate place if you think they're so important,
innovative, or generally useful?!)
Janis
you say 'usefull', i tell "your mum is doin new school"
https://www.youtube.com/watch?v=cumbkA5dGDI
fir pisze:
Janis Papanagnou pisze:sorry becouse my bad english i am rather unable to catch some more
lol, i told keith's team are funny asses..it needs some funcy answer:bart <bc@freeuk.com> writes:
When you have to implement this stuff then you can't be sloppy.
You demonstrated you can be extremely sloppy in your thinking and
in your argumentation! That doesn't mean that you wouldn't be able
to "write programs" ("this stuff"), for sure. - Another example of
sloppy thinking and argumentation.
Perhaps you're just jealous
Your mindset is so primitive, naive, and erroneous; unprecedentedly
given your stubbornness. Your persistent habit of making guesses,
completely missing the point, topics, and characters, had regularly
been shown to be widely erroneous. - I see you can't just stop your
ineffective tries. It won't lead you anywhere.
that my scheme isn't available in your favourite language.
I have no "favourite language". (In a couple languages there's some
concepts that I'd like to be more widely spread. - Not sure you're
capable of understanding that and notice the blatant difference!)
And you should meanwhile know that meaningless home-brewed languages
are neither of general interest nor of mine; but you seem to have a
persisting mental hindrance to understand what is easy understandable
by others. - Just to be clear; I don't know that "my scheme" you're
talking about is because I'm not interested in your posts about your
personal tools.
(I also suggest to become a bit more honest about your "achievement"
with creating your tool unless it gets some minimum general relevance
beyond your micro-ecosystem. - Why don't you advertise and offer your
tools at any more appropriate place if you think they're so important,
innovative, or generally useful?!)
Janis
you say 'usefull', i tell "your mum is doin new school"
https://www.youtube.com/watch?v=cumbkA5dGDI
subtle things in this anglish so maybe it should be
you say 'usefull', i tell your mama is doin new school
maybe this would be more appropriate
(by crom.. i feel body pain again)
(fir)
fir pisze:
fir pisze:
Janis Papanagnou pisze:sorry becouse my bad english i am rather unable to catch some more
lol, i told keith's team are funny asses..it needs some funcy answer:bart <bc@freeuk.com> writes:
When you have to implement this stuff then you can't be sloppy.
You demonstrated you can be extremely sloppy in your thinking and
in your argumentation! That doesn't mean that you wouldn't be able
to "write programs" ("this stuff"), for sure. - Another example of
sloppy thinking and argumentation.
Perhaps you're just jealous
Your mindset is so primitive, naive, and erroneous; unprecedentedly
given your stubbornness. Your persistent habit of making guesses,
completely missing the point, topics, and characters, had regularly
been shown to be widely erroneous. - I see you can't just stop your
ineffective tries. It won't lead you anywhere.
that my scheme isn't available in your favourite language.
I have no "favourite language". (In a couple languages there's some
concepts that I'd like to be more widely spread. - Not sure you're
capable of understanding that and notice the blatant difference!)
And you should meanwhile know that meaningless home-brewed languages
are neither of general interest nor of mine; but you seem to have a
persisting mental hindrance to understand what is easy understandable
by others. - Just to be clear; I don't know that "my scheme" you're
talking about is because I'm not interested in your posts about your
personal tools.
(I also suggest to become a bit more honest about your "achievement"
with creating your tool unless it gets some minimum general relevance
beyond your micro-ecosystem. - Why don't you advertise and offer your
tools at any more appropriate place if you think they're so important, >>>> innovative, or generally useful?!)
Janis
you say 'usefull', i tell "your mum is doin new school"
https://www.youtube.com/watch?v=cumbkA5dGDI
subtle things in this anglish so maybe it should be
you say 'usefull', i tell your mama is doin new school
maybe this would be more appropriate
(by crom.. i feel body pain again)
(fir)
this ilustrates this common topic:
if youre not holding any rules of behaviour you may and in a crowd of annoying spammers like quite popular here..bot on˙ oposite side
you got a society of fellows who have so called sticks up their asses
yet worse they oftan talk bulshit as stck up their as not guarantees
talkin sense
but those spamers also seem to have brain small as some seed
so the normality lies somewehere in between imo
(coz really this stick up the ass crowd is imo nonstandable spamers are
also nonstandable)
sadly usenet is not much large today it seems (which is very bad ofc)
bart <bc@freeuk.com> writes:
When you have to implement this stuff then you can't be sloppy.
You demonstrated you can be extremely sloppy in your thinking and
in your argumentation! That doesn't mean that you wouldn't be able
to "write programs" ("this stuff"), for sure. - Another example of
sloppy thinking and argumentation.
Perhaps you're just jealous
Your mindset is so primitive, naive, and erroneous; unprecedentedly
given your stubbornness. Your persistent habit of making guesses,
completely missing the point, topics, and characters, had regularly
been shown to be widely erroneous. - I see you can't just stop your ineffective tries. It won't lead you anywhere.
that my scheme isn't available in your favourite language.
I have no "favourite language". (In a couple languages there's some
concepts that I'd like to be more widely spread. - Not sure you're
capable of understanding that and notice the blatant difference!)
And you should meanwhile know that meaningless home-brewed languages
are neither of general interest nor of mine; but you seem to have a persisting mental hindrance to understand what is easy understandable
by others. - Just to be clear; I don't know that "my scheme" you're
talking about is because I'm not interested in your posts about your
personal tools.
(I also suggest to become a bit more honest about your "achievement"I might have done that 35 years ago or more.
with creating your tool unless it gets some minimum general relevance
beyond your micro-ecosystem. - Why don't you advertise and offer your
tools at any more appropriate place if you think they're so important, innovative, or generally useful?!)
* Mostly semicolon-free syntax (newline terminates statements
˙ unless they clearly continue onto the next line)
bart pisze:
* Mostly semicolon-free syntax (newline terminates statements
˙˙ unless they clearly continue onto the next line)
make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ... i just like removed , and
turned :: into , (as it was fee and better lookin)
˙";" advanced to be a paragraph(block) end sign
also many () in function calls also not needed as i showed in previous examples
as for this " " "," ";" syntax i just described it is probably and of
the road here, cant do better/much beter robably (except maybe ; is not
best looking so this sign eventually can change but the schem is like cleanest possible imo
fir pisze:
bart pisze:there is also an option of making blocks of blocks that would need
* Mostly semicolon-free syntax (newline terminates statements
˙˙ unless they clearly continue onto the next line)
make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ... i just like removed , and
turned :: into , (as it was fee and better lookin)
˙˙";" advanced to be a paragraph(block) end sign
also many () in function calls also not needed as i showed in previous
examples
as for this " " "," ";" syntax i just described it is probably and of
the road here, cant do better/much beter robably (except maybe ; is
not best looking so this sign eventually can change but the schem is
like cleanest possible imo
more signs - or repeating one etc
foo()
˙ a b c, d e f, g h;
˙ i j, k, l m n, o, p; ;
˙ v w, x;
˙ q, r s, t u;˙ ;
;
of course ;; not lokin good but something better here
so this is the same as
foo()
{
˙{{ {a b c, d e f, g h}
˙ {i j, k, l m n, o, p}}
˙ {{v w, x}
˙ {q, r s, t u} }
}
thus the logial lines in functions can be indexed foo[1][0][0] would be
v x (v(x) call)
* Multiple function return values: (a, b) := f(x)
bart pisze:
* Mostly semicolon-free syntax (newline terminates statements
˙˙ unless they clearly continue onto the next line)
make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ...
i just like removed , and
turned :: into , (as it was fee and better lookin)
also many () in function calls also not needed as i showed in previous examples
On 12/09/2026 13:37, fir wrote:
bart pisze:
* Mostly semicolon-free syntax (newline terminates statements
˙˙ unless they clearly continue onto the next line)
make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ...
Removing intra-line commas is not really practical. Even if technically
some code can be parsed without it, humans have difficulty.
Some structure is needed. Take this parameter list with commas:
˙˙ (a b c, d e)
'a' and 'd' are types; b, c, e are parameter names. Without the commas
it would just be:
˙˙ (a b c d e)
(In my language, user-defined types are not resolved into types until
after parsing. The parser relies on structure to determine which names
are types.)
While a function call like F(a + b, -1, sin c) ('sin' is an operator),
would become:
˙˙ F(a + b -1 sin c)
It all runs together, and here there is also an ambiguity between "b,
-1" and "b - 1".
However, I /have/ looked at interline commas: this is where you have a
long list of data initialisers, one per line. There it would be less of
a problem as newline acts as separator.
But I still found it troublesome as the parser needs to keep track of whether it's a semicolon- or comma-separated context.
(This is partly implemented, but as I can't remember in which language
or context, I find it easier to just write the commas.)
i just like removed , and
turned :: into , (as it was fee and better lookin)
Really? So C's 'std::cout' becomes 'std,cout'? That looks totally wrong.
also many () in function calls also not needed as i showed in previous
examples
Minimalist just doesn't work, sorry. It might in a language like Haskell which has special rules (and features like currying), but that is not
the kind of language I want to write.
On 12/09/2026 07:01, Janis Papanagnou wrote:
bart <bc@freeuk.com> writes:
When you have to implement this stuff then you can't be sloppy.
You demonstrated you can be extremely sloppy in your thinking and
in your argumentation! That doesn't mean that you wouldn't be able
to "write programs" ("this stuff"), for sure. - Another example of
sloppy thinking and argumentation.
Perhaps you're just jealous
Your mindset is so primitive, naive, and erroneous; unprecedentedly
given your stubbornness. Your persistent habit of making guesses,
completely missing the point, topics, and characters, had regularly
been shown to be widely erroneous. - I see you can't just stop your
ineffective tries. It won't lead you anywhere.
that my scheme isn't available in your favourite language.
I have no "favourite language". (In a couple languages there's some
concepts that I'd like to be more widely spread. - Not sure you're
capable of understanding that and notice the blatant difference!)
And you should meanwhile know that meaningless home-brewed languages
are neither of general interest nor of mine; but you seem to have a
persisting mental hindrance to understand what is easy understandable
by others. - Just to be clear; I don't know that "my scheme" you're
talking about is because I'm not interested in your posts about your
personal tools.
Then you are blinkered. You should be able to evaluate and appreciate
useful and innovate ideas by yourself, without relying on widespread adoption to tell you if they are good or bad.
If, tomorrow, a major mainstream language introduced a module scheme
just like mine, would you still hate it and think it useless, or would
you suddenly change your mind?!
Obviously not, because you are bigoted.
(I also suggest to become a bit more honest about your "achievement"I might have done that 35 years ago or more.
with creating your tool unless it gets some minimum general relevance
beyond your micro-ecosystem. - Why don't you advertise and offer your
tools at any more appropriate place if you think they're so important,
innovative, or generally useful?!)
For example, at one time my small company produced business computers.
We designed everything about them (my job was taking care of the motherboard). We did the PCB layout, manufactured the actual PCBs, and populated the PCBS by hand, all in the UK (my boss owned two other small companies that took care of that).
We even produced our own OS for it (via a 3rd associated company)!.
Today's landscape is utterly different. Can you imagine one company in
the UK producing dozens of computers per week compared with current mass-production in the far east that produces millions?
bart pisze:
On 12/09/2026 13:37, fir wrote:
bart pisze:
* Mostly semicolon-free syntax (newline terminates statements
˙˙ unless they clearly continue onto the next line)
make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ...
Removing intra-line commas is not really practical. Even if
technically some code can be parsed without it, humans have difficulty.
Some structure is needed. Take this parameter list with commas:
˙˙˙ (a b c, d e)
'a' and 'd' are types; b, c, e are parameter names. Without the commas
it would just be:
˙˙˙ (a b c d e)
its becouse you give examples with not know what it mean if it would be
int b c float e its more clear (fully clear imo
though im was not saying˙ on this case - as i said , works in a place of
; (its a "logical line" seperator so it work like ";" in c where the c usages of "," are ust removed
i mean , removed
; replaced by ,
(In my language, user-defined types are not resolved into types until
after parsing. The parser relies on structure to determine which names
are types.)
While a function call like F(a + b, -1, sin c) ('sin' is an operator),
would become:
˙˙˙ F(a + b -1 sin c)
F a+b -1 sin c
is clear imo˙ 9though better is to use separate - sign for neg values
not subtraction)
in above i mean probably its good to take you baf write
foo arg arg arg foo arg arg
i mean "only one function acll in logical line so you would need
foo arg arg arg, foo arg arg
to satisfy this rule so if
you see this
F a+b -1 sin c
you know its one function call thus sin c is argument
It all runs together, and here there is also an ambiguity between "b,
-1" and "b - 1".
However, I /have/ looked at interline commas: this is where you have a
long list of data initialisers, one per line. There it would be less
of a problem as newline acts as separator.
But I still found it troublesome as the parser needs to keep track of
whether it's a semicolon- or comma-separated context.
(This is partly implemented, but as I can't remember in which language
or context, I find it easier to just write the commas.)
i just like removed , and
turned :: into , (as it was fee and better lookin)
sorry i meant ; not :: (shift didnt worked )
Really? So C's 'std::cout' becomes 'std,cout'? That looks totally wrong.
also many () in function calls also not needed as i showed in
previous examples
Minimalist just doesn't work, sorry. It might in a language like
Haskell which has special rules (and features like currying), but that
is not the kind of language I want to write.
there is alos to use ' optionally i mean some may use them in ()
like
print a b c
may use
(print a b c) //optionally
or
print (a b c)˙ //optionally
or
print (a,b,c) //optionally
aventually
thet would probbaly not collide with general "bare naked" {s n j, s d f,
s d}
syntax
im not sure if allowing print(a b c) could not cause slight collisions
if so some slight changes there would need be here but in worst case
it would be disalowed but probably i would prefer in worst case
doing meaningful space it is not eventually allowing
print (a b c)
in that case (at worst ) but maybe its not needed, i would need to
check it
F a+b -1 sin c
fir pisze:
F a+b -1 sin c
this second minus is in fact needed so normally
this above is f a+b-2 sin(c)
unicode as usually instead of having something cruciallu usful provides
soem weirdos here
this above with -2 not subtraction would be˙ f a+b ?2 sin(c)
but meybe somethin could be find
fir pisze:
F a+b -1 sin c
this second minus is in fact needed so normally
this above is f a+b-2 sin(c)
unicode as usually instead of having something cruciallu usful provides
soem weirdos here
this above with -2 not subtraction would be˙ f a+b ?2 sin(c)
but meybe somethin could be find
bart pisze:
On 12/09/2026 13:37, fir wrote:
bart pisze:
* Mostly semicolon-free syntax (newline terminates statements
˙˙ unless they clearly continue onto the next line)
make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ...
Removing intra-line commas is not really practical. Even if
technically some code can be parsed without it, humans have difficulty.
Some structure is needed. Take this parameter list with commas:
˙˙˙ (a b c, d e)
'a' and 'd' are types; b, c, e are parameter names. Without the commas
it would just be:
˙˙˙ (a b c d e)
its becouse you give examples with not know what it mean if it would be
int b c float e its more clear (fully clear imo
though im was not saying˙ on this case - as i said , works in a place
of ; (its a "logical line" seperator so it work like ";" in c where the
c usages of "," are ust removed
i mean , removed
; replaced by ,
(In my language, user-defined types are not resolved into types until
after parsing. The parser relies on structure to determine which names
are types.)
While a function call like F(a + b, -1, sin c) ('sin' is an operator),
would become:
˙˙˙ F(a + b -1 sin c)
F a+b -1 sin c
is clear imo˙ 9though better is to use separate - sign for neg values
not subtraction)
in above i mean probably its good to take you baf write
foo arg arg arg foo arg arg
i mean "only one function acll in logical line so you would need
foo arg arg arg, foo arg arg
to satisfy this rule so if
you see this
F a+b -1 sin c
you know its one function call thus sin c is argument
i just like removed , and
turned :: into , (as it was fee and better lookin)
sorry i meant ; not :: (shift didnt worked )
im not sure if allowing print(a b c) could not cause slight collisionsHow sure are you that two user identifiers can never be adjacent?
if so some slight changes there would need be here but in worst case
it would be disalowed but probably i would prefer in worst case
doing meaningful space it is not eventually allowing
print (a b c)
What exactly are trying to achieve here: saving a few seconds of typing
but then spending ten times as long trying to understand the code, or
1000 times as long trying to debug all the subtle bugs that have crept in?
On 12/09/2026 14:44, fir wrote:
bart pisze:
On 12/09/2026 13:37, fir wrote:
bart pisze:
* Mostly semicolon-free syntax (newline terminates statements
˙˙ unless they clearly continue onto the next line)
make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ...
Removing intra-line commas is not really practical. Even if
technically some code can be parsed without it, humans have difficulty.
Some structure is needed. Take this parameter list with commas:
˙˙˙ (a b c, d e)
'a' and 'd' are types; b, c, e are parameter names. Without the
commas it would just be:
˙˙˙ (a b c d e)
its becouse you give examples with not know what it mean if it would be
int b c float e its more clear (fully clear imo
Sure, but what happens when someone /wants/ to have user-define types?
So in general it is ambiguous.
In C you can also have a parameter list which has only types, no
parameter names. If that is still a feature, then:
˙ (a, b, c, d);
can be assumed (by the reader) to be all types. But this:
˙ (a b c d)
is more ambiguous; how many parameters are there: is it 4 (abcd are all types); 3 (a is a type, bcd are names), or 2 (ac are types, bd are
names)? Other combinations may be possible.
though im was not saying˙ on this case - as i said , works in a place
of ; (its a "logical line" seperator so it work like ";" in c where
the c usages of "," are ust removed
i mean , removed
; replaced by ,
(In my language, user-defined types are not resolved into types until
after parsing. The parser relies on structure to determine which
names are types.)
While a function call like F(a + b, -1, sin c) ('sin' is an
operator), would become:
˙˙˙ F(a + b -1 sin c)
F a+b -1 sin c
Significant white space now? Come pm, what sort of crazy language is
this going to be?!
But since this is a fantasy language anyway that is never going to be implemented, then sure, leave out whatever you want. But it will be a terrible language to work with.
is clear imo˙ 9though better is to use separate - sign for neg values
not subtraction)
in above i mean probably its good to take you baf write
foo arg arg arg foo arg arg
Users can make their own identifiers so it could be this:
˙ arg foo foo foo arg foo foo
In general a compiler will see:
˙ a b c d e f g
Seven consecutive identifiers.
i mean "only one function acll in logical line so you would need
foo arg arg arg, foo arg arg
to satisfy this rule so if
you see this
F a+b -1 sin c
you know its one function call thus sin c is argument
I'm sorry, but this stuff needs to be COMPLETELY AMBIGUOUS. Someone
should INSTANTLY be able to know what is intended, rather than waste
time trying to infer it. This is supposed to be the source code of some program, not a puzzle!
You can make it unambiguous by using commas and parentheses, and
EVERYONE will understand what is being expressed.
What exactly are trying to achieve here: saving a few seconds of typing
but then spending ten times as long trying to understand the code, or
1000 times as long trying to debug all the subtle bugs that have crept in?
I know this is a fantasy, but aren't you interested in practicalities at all?
i just like removed , and
turned :: into , (as it was fee and better lookin)
sorry i meant ; not :: (shift didnt worked )
std;cout isn't much better! Both "::" and "." are commonly used for this purpose.
im not sure if allowing print(a b c) could not cause slight collisionsHow sure are you that two user identifiers can never be adjacent?
if so some slight changes there would need be here but in worst case
it would be disalowed but probably i would prefer in worst case
doing meaningful space it is not eventually allowing
print (a b c)
What about operators that can be both unary and binary? A further example:
˙ a b * c * d
Is this a(b * c * d), or a(b, *c * d), or (b, *c, *d) etc?
Please don't say that you have to work it out by hunting for the definitions; as I said this should not be a puzzle.
Sure, but what happens when someone /wants/ to have user-define types?
So in general it is ambiguous.
In C you can also have a parameter list which has only types, no
parameter names. If that is still a feature, then:
˙ (a, b, c, d);
can be assumed (by the reader) to be all types. But this:
˙ (a b c d)
is more ambiguous; how many parameters are there: is it 4 (abcd are all types); 3 (a is a type, bcd are names), or 2 (ac are types, bd are
names)? Other combinations may be possible.
bart pisze:
Sure, but what happens when someone /wants/ to have user-define types?
So in general it is ambiguous.
In C you can also have a parameter list which has only types, no
parameter names. If that is still a feature, then:
˙˙ (a, b, c, d);
can be assumed (by the reader) to be all types. But this:
˙˙ (a b c d)
is more ambiguous; how many parameters are there: is it 4 (abcd are
all types); 3 (a is a type, bcd are names), or 2 (ac are types, bd are
names)? Other combinations may be possible.
this one i dont understand whats difference id someone uses like
structure nameinstead of int?
no difference
and if ou see such thing as int int a b foo float
do i ask you how many type names are there? how many wariables and how
many function names?
note in code if it is not obfuscated names are meaningfull, type names
are not popular ther repeat and you know them generally function names
are usualy verbs (i write is mostly in big letter, variables i
personally always write low leter)
some functions i write low letter but those very qshort very quick usage
one like sin strcmp print - only few things like that
bart pisze:
In general a compiler will see:this is your very serious problem here that you assume 'unlearned' human should understand it, compiler must understand it...
˙˙ a b c d e f g
you know what you talk also fits to c you also neeeded to learn what
given construction mean here its just the same jus construction have
less ,,, () stuf
kompiler knows what given symbols are..if it make sense it will compile
it if not he will not if you make some complex stuff with a net of
functions like
f1 a f2 f3 f4 a a f5 f6
compiler know which function takes how many arguments
and will resolve it to fit
im not sure if there is any disimbiguity here or none
if you know one tell me and i will tell a rule to resolve it
(as it may be resolved by some rule
if yu worry on humen radibilit y you just add parentheses and you
end up at worst in your initial form
do it much cleaner and many use will use the clean lightweight 'naked'
form (no gothic clothes)
when i see this its totally clear to me
no worry , definitions wouldnt help here
this above is obviously non possible˙ you cant have unary and binary
here (as far as it seems, i may be maybe wrong)
a*b must be binary if *b would be unary then it mean you have
a *b so its ambiguity , so there some additional rule would need to be
used at least
rule can be
a*b˙ // is binary
a(*b) //is unary
(a*)b //is unary
this touches some problem becouse it blocks a(b) syntax which eventually could be usefull, but it eventually may be seen not much usefull
as i see () more like separators not˙ 'calling' operator
(it only be blocked for those types of ab though not necessary for
fiunction calls
there is also option to use this space as a seperator ..this kind of mmeaningfull spaces i use here all time for example in a b c d
apaces are meaningfull coz its not ab c d
so a *b wouldnt be considered good idea but a (*b) being different than a(*b) may be (but VERY eventually)
a(b(c, d))
Does that help?
a (b c d)
combination of 4 not meaningful names in programing is not usual i would
say
bart pisze:>
˙˙˙ a(b(c, d))
Does that help?
not much honestly - if youre so much in hole you can find
definitions..as you say you are
two terrible mistakes you do
1) you somewhat assume that definitions are not pesent - all definitions
are present - if definitions are not present it would not compile
2) you talk about this human reader its not a problem
you may add those parenthesis optionally... and if someone not added it blame him
though as i said i would add the () different way
not˙˙ a(b(c, d))
but
˙ a (b c d)
you anyway should use meaningdull names in this examples becouse names
carry an information
DrawLine x y p q color
for basic function call IS TOO GOD TO NOT TAKE IT -
BTW here is a draw-line routine in my scripting language:
˙ proc gxline(w, x, y, ?x2, ?y2) ...
It takes either one point or two. It is these optional args that would
make it hard to figure out a call like this:
˙˙ gxline w a b c d
Is this gxline(w, a, b, c, d), or is it gxline(w, a, b(c, d))? In this dynamic language, b might be a variable containing a function reference.
A little contrived, but no matter because the same contrivance is here
in my systems language:
˙˙ proc main =
˙˙˙˙˙˙ for i to 10 do
˙˙˙˙˙˙˙˙˙˙ println i, sqrt i
˙˙˙˙˙˙˙˙˙˙ println "----------"
˙˙˙˙˙˙ end
˙˙ end
bart pisze:
A little contrived, but no matter because the same contrivance is here
in my systems language:
˙˙˙ proc main =
˙˙˙˙˙˙˙ for i to 10 do
˙˙˙˙˙˙˙˙˙˙˙ println i, sqrt i
˙˙˙˙˙˙˙˙˙˙˙ println "----------"
˙˙˙˙˙˙˙ end
˙˙˙ end
() and ; removed which is good but you alsoe need˙ to remove keywords
and this one ' and it will be ok
fir pisze:
bart pisze:
A little contrived, but no matter because the same contrivance is
here in my systems language:
˙˙˙ proc main =
˙˙˙˙˙˙˙ for i to 10 do
˙˙˙˙˙˙˙˙˙˙˙ println i, sqrt i
˙˙˙˙˙˙˙˙˙˙˙ println "----------"
˙˙˙˙˙˙˙ end
˙˙˙ end
() and ; removed which is good but you alsoe need˙ to remove keywords
and this one ' and it will be ok
something like - you need a billet to mark definitions ..next one may be used by another definition but may also put empty one
˙? main
˙˙˙ ?10
˙˙˙˙˙˙ println ? sqrt ?
˙˙˙˙˙˙ println "----------"
˙?
* The function doesn't use an unspecified parameter list (this was a
feature of C but C23 may have deprecated that)
bart pisze:The same code runs as-is in my scripting language, but that also allows
A little contrived, but no matter because the same contrivance is here
in my systems language:
˙˙˙ proc main =
˙˙˙˙˙˙˙ for i to 10 do
˙˙˙˙˙˙˙˙˙˙˙ println i, sqrt i
˙˙˙˙˙˙˙˙˙˙˙ println "----------"
˙˙˙˙˙˙˙ end
˙˙˙ end
() and ; removed which is good but you alsoe need˙ to remove keywords
and this one ' and it will be ok
On 13/09/2026 09:15, fir wrote:
bart pisze:The same code runs as-is in my scripting language, but that also allows
A little contrived, but no matter because the same contrivance is
here in my systems language:
˙˙˙ proc main =
˙˙˙˙˙˙˙ for i to 10 do
˙˙˙˙˙˙˙˙˙˙˙ println i, sqrt i
˙˙˙˙˙˙˙˙˙˙˙ println "----------"
˙˙˙˙˙˙˙ end
˙˙˙ end
() and ; removed which is good but you alsoe need˙ to remove keywords
and this one ' and it will be ok
this version:
˙ for i to 10 do
˙˙˙˙˙ ? i, ûi
˙˙˙˙˙ ? "-"*10
˙ od
Any better? (The "-"*10 works above too but it was two extra tokens! The
'û' is an alias for 'sqrt' and was added for fun.)
There used to be a compact form of loop too which may have looked like
this:
˙(i:10 || ?i, ûi; "-"*10)
That's great. But now imagine 1000 lines full of such gobbledygook.
It sounds like your ideal language would be APL, if is not 'clean' and 'clear' that you're after, but 'minimal' and 'cryptic'.
The first version above is the best balance in my view. You /want/ some mixture of keywords and symbols.
In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.
bart pisze:
On 13/09/2026 09:15, fir wrote:
bart pisze:The same code runs as-is in my scripting language, but that also
A little contrived, but no matter because the same contrivance is
here in my systems language:
˙˙˙ proc main =
˙˙˙˙˙˙˙ for i to 10 do
˙˙˙˙˙˙˙˙˙˙˙ println i, sqrt i
˙˙˙˙˙˙˙˙˙˙˙ println "----------"
˙˙˙˙˙˙˙ end
˙˙˙ end
() and ; removed which is good but you alsoe need˙ to remove keywords
and this one ' and it will be ok
allows this version:
˙˙ for i to 10 do
˙˙˙˙˙˙ ? i, ûi
˙˙˙˙˙˙ ? "-"*10
˙˙ od
Any better? (The "-"*10 works above too but it was two extra tokens!
The 'û' is an alias for 'sqrt' and was added for fun.)
There used to be a compact form of loop too which may have looked like
this:
˙˙(i:10 || ?i, ûi; "-"*10)
That's great. But now imagine 1000 lines full of such gobbledygook.
It sounds like your ideal language would be APL, if is not 'clean' and
'clear' that you're after, but 'minimal' and 'cryptic'.
The first version above is the best balance in my view. You /want/
some mixture of keywords and symbols.
In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.
i gave you example - its only cryptic if you dont know what it means
fir pisze:
bart pisze:
consider for example french or polish language its totally cryptic untilIt sounds like your ideal language would be APL, if is not 'clean'
and 'clear' that you're after, but 'minimal' and 'cryptic'.
The first version above is the best balance in my view. You /want/
some mixture of keywords and symbols.
In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.
i gave you example - its only cryptic if you dont know what it means
you will learn it...
definitions
overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things
On 12/09/2026 19:58, bart wrote:
(Snipping lots of good points about language design - I don't want to discuss fir's hypothetical language, but I can still give you a little
more information on a C point.)
* The function doesn't use an unspecified parameter list (this was a
feature of C but C23 may have deprecated that)
The use of non-prototype function declarations (including implicit ones)
was marked as an "obsolescent" feature in C90.˙ (That is, if I
understand correctly, it was not actually deprecated but was planned to
be deprecated in the near future).˙ C23 skipped deprecation entirely and removed it from the language.˙ (I think most C programmers see that as absurdly slow timing from the C standards committee and C compiler implementers.˙ I only know of one C expert who thought non-prototype function declarations were useful to keep around, and I don't think he
ever gave a good reason for that.)
On 13/09/2026 10:53, fir wrote:
fir pisze:
bart pisze:
consider for example french or polish language its totally crypticIt sounds like your ideal language would be APL, if is not 'clean'
and 'clear' that you're after, but 'minimal' and 'cryptic'.
The first version above is the best balance in my view. You /want/
some mixture of keywords and symbols.
In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.
i gave you example - its only cryptic if you dont know what it means
until you will learn it...
That is not your aim. That appears to be to start with a language that
you know perfectly well, but remove all punctuation, capitalisation and structure, and half the words. But to what purpose; because you're too
lazy to type?
˙not to say you want to understand it without
definitions
So an APL (or J or K) program is never cryptic because all you have to
do is learn it? If only I'd thought of that!
The same applies to Assembly I guess. And machine code?
overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things
And you keep repeating the same nonsense. What is your endpoint: a
program that can be expressed in one byte?
bart pisze:
On 13/09/2026 10:53, fir wrote:
fir pisze:
bart pisze:
consider for example french or polish language its totally crypticIt sounds like your ideal language would be APL, if is not 'clean'
and 'clear' that you're after, but 'minimal' and 'cryptic'.
The first version above is the best balance in my view. You /want/
some mixture of keywords and symbols.
In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.
i gave you example - its only cryptic if you dont know what it means
until you will learn it...
That is not your aim. That appears to be to start with a language that
you know perfectly well, but remove all punctuation, capitalisation
and structure, and half the words. But to what purpose; because you're
too lazy to type?
˙˙not to say you want to understand it without
definitions
So an APL (or J or K) program is never cryptic because all you have to
do is learn it? If only I'd thought of that!
The same applies to Assembly I guess. And machine code?
apl i dont know but ofc it applies to assembly but x86 assembly is
terribly flawed
x86 assembly is like c++
overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things
And you keep repeating the same nonsense. What is your endpoint: a
program that can be expressed in one byte?
my goal is to make it cleanest possible
and also make thsi sintax more powerfull - it is "carrying" a lot more "weight" (semantic weight).. i men where short sentences may expres much meaning
Note that the code will still have braces. I suggest a better aim is to eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.
fir pisze:
bart pisze:
On 13/09/2026 10:53, fir wrote:
fir pisze:
bart pisze:
consider for example french or polish language its totally crypticIt sounds like your ideal language would be APL, if is not 'clean' >>>>>> and 'clear' that you're after, but 'minimal' and 'cryptic'.
The first version above is the best balance in my view. You /want/ >>>>>> some mixture of keywords and symbols.
In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.
i gave you example - its only cryptic if you dont know what it means >>>>>
until you will learn it...
That is not your aim. That appears to be to start with a language
that you know perfectly well, but remove all punctuation,
capitalisation and structure, and half the words. But to what
purpose; because you're too lazy to type?
˙˙not to say you want to understand it without
definitions
So an APL (or J or K) program is never cryptic because all you have
to do is learn it? If only I'd thought of that!
The same applies to Assembly I guess. And machine code?
apl i dont know but ofc it applies to assembly but x86 assembly is
terribly flawed
x86 assembly is like c++
overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things
And you keep repeating the same nonsense. What is your endpoint: a
program that can be expressed in one byte?
my goal is to make it cleanest possible
and also make thsi sintax more powerfull - it is "carrying" a lot more
"weight" (semantic weight).. i men where short sentences may expres
much meaning
this example is quite clean and weighty
˙ ? main
˙˙˙˙ ?10
˙˙˙˙˙˙˙ println ? sqrt ?
˙˙˙˙˙˙˙ println "----------"
˙ ?
esp this ?10 is clean and weighty i got a lot of problems with this
becouse x10 eventually worked but has terrible disadwantage xa is not standable (a is variable value say 100) but unicode resolves a lot of problems coz ?a work
NOTE this all now seem obvious but before discovering this what seems obvious LATER BEFORE this all conclusions was VERY FAR form obvious
im saying this becouse i thing that people will take some outcome and
not adress its orygination..all this conclusion i take are oryginal at
least in a sense it is not copied from someo other source (except the
most common typical knowledge base)
(not saying that some solutions i use by chance were already invented
but often in some different contextes and not fully)
even seint the fact some just should take unicode was not obvious not to mention many other things
esp this ?10 is clean and weighty i got a lot of problems with this
becouse x10 eventually worked but has terrible disadwantage xa is not standable (a is variable value say 100) but unicode resolves a lot of problems coz ?a work
NOTE this all now seem obvious but before discovering this what seems obvious LATER BEFORE this all conclusions was VERY FAR form obvious
On 13/09/2026 10:53, fir wrote:
fir pisze:
bart pisze:
consider for example french or polish language its totally crypticIt sounds like your ideal language would be APL, if is not 'clean'
and 'clear' that you're after, but 'minimal' and 'cryptic'.
The first version above is the best balance in my view. You /want/
some mixture of keywords and symbols.
In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.
i gave you example - its only cryptic if you dont know what it means
until you will learn it...
That is not your aim. That appears to be to start with a language that
you know perfectly well, but remove all punctuation, capitalisation and structure, and half the words. But to what purpose; because you're too
lazy to type?
˙not to say you want to understand it without
definitions
So an APL (or J or K) program is never cryptic because all you have to
do is learn it? If only I'd thought of that!
The same applies to Assembly I guess. And machine code?
overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things
And you keep repeating the same nonsense. What is your endpoint: a
program that can be expressed in one byte?
bart wrote:
On 13/09/2026 10:53, fir wrote:He wants to compress the language, metaphor a plum, into a prune that
fir pisze:
bart pisze:
consider for example french or polish language its totally crypticIt sounds like your ideal language would be APL, if is not 'clean'
and 'clear' that you're after, but 'minimal' and 'cryptic'.
The first version above is the best balance in my view. You /want/
some mixture of keywords and symbols.
In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.
i gave you example - its only cryptic if you dont know what it means
until you will learn it...
That is not your aim. That appears to be to start with a language that
you know perfectly well, but remove all punctuation, capitalisation
and structure, and half the words. But to what purpose; because you're
too lazy to type?
˙˙not to say you want to understand it without
definitions
So an APL (or J or K) program is never cryptic because all you have to
do is learn it? If only I'd thought of that!
The same applies to Assembly I guess. And machine code?
overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things
And you keep repeating the same nonsense. What is your endpoint: a
program that can be expressed in one byte?
has much reduced.
It is the same way with a newsgroup when the warlord Lane W has
compressed all the shitheads, David Brown, Keith, bart, and the rest
except I guess the fellows who are in the mood, when they all conspire
by email to not respond to anything he writes. It is at such a time that
he declares victory. As I roll over yet another group in the 97 I have subjugated to my rule and made complacent, a tear drips from my eye. C,
such a beautiful language, yet what hypocrites such as David Brown
defending it. Really, nothing personal? I beg to differ. Under my boot,
a serpent crawls out of the skull of another victim.
On 2026-09-12, bart <bc@freeuk.com> wrote:
Note that the code will still have braces. I suggest a better aim is to
eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.
There can be a difference; for example (assume <stdio.h> included):
if (0) { if (1) puts("foo"); else puts("bar"); }
if (0) { if (1) puts("foo"); } else { puts("bar"); }
The first line will print nothing; the second one will print "bar".
On 13/09/2026 11:53, Ike Naar wrote:
On 2026-09-12, bart <bc@freeuk.com> wrote:
Note that the code will still have braces. I suggest a better aim is to
eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.
There can be a difference; for example (assume <stdio.h> included):
˙˙˙˙ if (0) { if (1) puts("foo");˙˙ else˙˙ puts("bar"); }
˙˙˙˙ if (0) { if (1) puts("foo"); } else { puts("bar"); }
The first line will print nothing; the second one will print "bar".
This illustrates my point; first some Pascal:
˙ if cond then begin s1; s2 end else begin s3; s4 end
C is the same but uses braces, and semicolons are terminators:
˙ if (cond) { s1; s2; } else { s3; s4; }
One has 'end else begin', the other has '} else {'.
However the Pascal version can be improved; since 'then' and 'else' can
act as block delimiters:
˙ if cond then s1; s2 end else s3; s4 end
Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.
Unfortunately this doesn't transfer well to C:
˙ if (cond) s1; s2; else s3; s4; }
The () around 'cond' are needed as the ')' separates cond and s1 (fir doesn't not appreciate this point; he thinks it is fine for statements
and expressions to run together provided that there is a way to infer
where one logically ends and the other starts).
The trouble is that lone, unbalanced } at the end.
So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)
bart pisze:
On 13/09/2026 11:53, Ike Naar wrote:
On 2026-09-12, bart <bc@freeuk.com> wrote:
Note that the code will still have braces. I suggest a better aim is to >>>> eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.
There can be a difference; for example (assume <stdio.h> included):
˙˙˙˙ if (0) { if (1) puts("foo");˙˙ else˙˙ puts("bar"); }
˙˙˙˙ if (0) { if (1) puts("foo"); } else { puts("bar"); }
The first line will print nothing; the second one will print "bar".
This illustrates my point; first some Pascal:
˙˙ if cond then begin s1; s2 end else begin s3; s4 end
C is the same but uses braces, and semicolons are terminators:
˙˙ if (cond) { s1; s2; } else { s3; s4; }
One has 'end else begin', the other has '} else {'.
However the Pascal version can be improved; since 'then' and 'else'
can act as block delimiters:
˙˙ if cond then s1; s2 end else s3; s4 end
Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.
Unfortunately this doesn't transfer well to C:
˙˙ if (cond) s1; s2; else s3; s4; }
The () around 'cond' are needed as the ')' separates cond and s1 (fir
doesn't not appreciate this point; he thinks it is fine for statements
and expressions to run together provided that there is a way to infer
where one logically ends and the other starts).
The trouble is that lone, unbalanced } at the end.
So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)
what you consider problems is so siple i dont even think on it
as to ifs syntax i am yet not sure
some like this may be considered but its not much good loking
though is sorta logical
x<10 ? x++>5
˙˙˙˙˙˙ ?˙ more_than_five
˙˙˙˙˙˙ ? less_than_six
˙˙˙ ? do_nothing
On 13/09/2026 14:21, fir wrote:
bart pisze:
On 13/09/2026 11:53, Ike Naar wrote:
On 2026-09-12, bart <bc@freeuk.com> wrote:
Note that the code will still have braces. I suggest a better aim
is to
eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.
There can be a difference; for example (assume <stdio.h> included):
˙˙˙˙ if (0) { if (1) puts("foo");˙˙ else˙˙ puts("bar"); }
˙˙˙˙ if (0) { if (1) puts("foo"); } else { puts("bar"); }
The first line will print nothing; the second one will print "bar".
This illustrates my point; first some Pascal:
˙˙ if cond then begin s1; s2 end else begin s3; s4 end
C is the same but uses braces, and semicolons are terminators:
˙˙ if (cond) { s1; s2; } else { s3; s4; }
One has 'end else begin', the other has '} else {'.
However the Pascal version can be improved; since 'then' and 'else'
can act as block delimiters:
˙˙ if cond then s1; s2 end else s3; s4 end
Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.
Unfortunately this doesn't transfer well to C:
˙˙ if (cond) s1; s2; else s3; s4; }
The () around 'cond' are needed as the ')' separates cond and s1 (fir
doesn't not appreciate this point; he thinks it is fine for
statements and expressions to run together provided that there is a
way to infer where one logically ends and the other starts).
The trouble is that lone, unbalanced } at the end.
So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)
what you consider problems is so siple i dont even think on it
as to ifs syntax i am yet not sure
some like this may be considered but its not much good loking
though is sorta logical
x<10 ? x++>5
˙˙˙˙˙˙˙ ?˙ more_than_five
˙˙˙˙˙˙˙ ? less_than_six
˙˙˙˙ ? do_nothing
Try: if 5 < x < 10.
bart pisze:
On 13/09/2026 14:21, fir wrote:
bart pisze:
On 13/09/2026 11:53, Ike Naar wrote:
On 2026-09-12, bart <bc@freeuk.com> wrote:
Note that the code will still have braces. I suggest a better aim >>>>>> is to
eliminate most braces. The should be no need to ever see '} else {' >>>>>> instead of just 'else'.
There can be a difference; for example (assume <stdio.h> included):
˙˙˙˙ if (0) { if (1) puts("foo");˙˙ else˙˙ puts("bar"); }
˙˙˙˙ if (0) { if (1) puts("foo"); } else { puts("bar"); }
The first line will print nothing; the second one will print "bar".
This illustrates my point; first some Pascal:
˙˙ if cond then begin s1; s2 end else begin s3; s4 end
C is the same but uses braces, and semicolons are terminators:
˙˙ if (cond) { s1; s2; } else { s3; s4; }
One has 'end else begin', the other has '} else {'.
However the Pascal version can be improved; since 'then' and 'else'
can act as block delimiters:
˙˙ if cond then s1; s2 end else s3; s4 end
Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.
Unfortunately this doesn't transfer well to C:
˙˙ if (cond) s1; s2; else s3; s4; }
The () around 'cond' are needed as the ')' separates cond and s1
(fir doesn't not appreciate this point; he thinks it is fine for
statements and expressions to run together provided that there is a
way to infer where one logically ends and the other starts).
The trouble is that lone, unbalanced } at the end.
So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)
what you consider problems is so siple i dont even think on it
as to ifs syntax i am yet not sure
some like this may be considered but its not much good loking
though is sorta logical
x<10 ? x++>5
˙˙˙˙˙˙˙ ?˙ more_than_five
˙˙˙˙˙˙˙ ? less_than_six
˙˙˙˙ ? do_nothing
Try: if 5 < x < 10.
why? its the same
5<x<10 ?
On 13/09/2026 14:21, fir wrote:
bart pisze:
On 13/09/2026 11:53, Ike Naar wrote:
On 2026-09-12, bart <bc@freeuk.com> wrote:
Note that the code will still have braces. I suggest a better aim
is to
eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.
There can be a difference; for example (assume <stdio.h> included):
˙˙˙˙ if (0) { if (1) puts("foo");˙˙ else˙˙ puts("bar"); }
˙˙˙˙ if (0) { if (1) puts("foo"); } else { puts("bar"); }
The first line will print nothing; the second one will print "bar".
This illustrates my point; first some Pascal:
˙˙ if cond then begin s1; s2 end else begin s3; s4 end
C is the same but uses braces, and semicolons are terminators:
˙˙ if (cond) { s1; s2; } else { s3; s4; }
One has 'end else begin', the other has '} else {'.
However the Pascal version can be improved; since 'then' and 'else'
can act as block delimiters:
˙˙ if cond then s1; s2 end else s3; s4 end
Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.
Unfortunately this doesn't transfer well to C:
˙˙ if (cond) s1; s2; else s3; s4; }
The () around 'cond' are needed as the ')' separates cond and s1 (fir
doesn't not appreciate this point; he thinks it is fine for
statements and expressions to run together provided that there is a
way to infer where one logically ends and the other starts).
The trouble is that lone, unbalanced } at the end.
So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)
what you consider problems is so siple i dont even think on it
as to ifs syntax i am yet not sure
some like this may be considered but its not much good loking
though is sorta logical
x<10 ? x++>5
˙˙˙˙˙˙˙ ?˙ more_than_five
˙˙˙˙˙˙˙ ? less_than_six
˙˙˙˙ ? do_nothing
Try: if 5 < x < 10.
bart pisze:
On 13/09/2026 14:21, fir wrote:not btw that if you want make much more rigid and more descriptive
bart pisze:
On 13/09/2026 11:53, Ike Naar wrote:
On 2026-09-12, bart <bc@freeuk.com> wrote:
Note that the code will still have braces. I suggest a better aim >>>>>> is to
eliminate most braces. The should be no need to ever see '} else {' >>>>>> instead of just 'else'.
There can be a difference; for example (assume <stdio.h> included):
˙˙˙˙ if (0) { if (1) puts("foo");˙˙ else˙˙ puts("bar"); }
˙˙˙˙ if (0) { if (1) puts("foo"); } else { puts("bar"); }
The first line will print nothing; the second one will print "bar".
This illustrates my point; first some Pascal:
˙˙ if cond then begin s1; s2 end else begin s3; s4 end
C is the same but uses braces, and semicolons are terminators:
˙˙ if (cond) { s1; s2; } else { s3; s4; }
One has 'end else begin', the other has '} else {'.
However the Pascal version can be improved; since 'then' and 'else'
can act as block delimiters:
˙˙ if cond then s1; s2 end else s3; s4 end
Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.
Unfortunately this doesn't transfer well to C:
˙˙ if (cond) s1; s2; else s3; s4; }
The () around 'cond' are needed as the ')' separates cond and s1
(fir doesn't not appreciate this point; he thinks it is fine for
statements and expressions to run together provided that there is a
way to infer where one logically ends and the other starts).
The trouble is that lone, unbalanced } at the end.
So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)
what you consider problems is so siple i dont even think on it
as to ifs syntax i am yet not sure
some like this may be considered but its not much good loking
though is sorta logical
x<10 ? x++>5
˙˙˙˙˙˙˙ ?˙ more_than_five
˙˙˙˙˙˙˙ ? less_than_six
˙˙˙˙ ? do_nothing
Try: if 5 < x < 10.
language youre obviously fukll right to implement this philosophy im not denying this
i waguely remember i sad to you something like "try" or "you my try"
giving some of my outcomes as to my philosophy as i assumed you
want to use something good ;c
im joking (imo ofc my philosophy here is better but you may use your own ofc)
for me your conventions are suboptimal (all those ones who not by chance
are mine own ;c )
fir pisze:
bart pisze:for me the ones im searching are optimal at least ofr last 'research
On 13/09/2026 14:21, fir wrote:not btw that if you want make much more rigid and more descriptive
bart pisze:
On 13/09/2026 11:53, Ike Naar wrote:
On 2026-09-12, bart <bc@freeuk.com> wrote:
Note that the code will still have braces. I suggest a better aim >>>>>>> is to
eliminate most braces. The should be no need to ever see '} else {' >>>>>>> instead of just 'else'.
There can be a difference; for example (assume <stdio.h> included): >>>>>>
˙˙˙˙ if (0) { if (1) puts("foo");˙˙ else˙˙ puts("bar"); }
˙˙˙˙ if (0) { if (1) puts("foo"); } else { puts("bar"); }
The first line will print nothing; the second one will print "bar". >>>>>
This illustrates my point; first some Pascal:
˙˙ if cond then begin s1; s2 end else begin s3; s4 end
C is the same but uses braces, and semicolons are terminators:
˙˙ if (cond) { s1; s2; } else { s3; s4; }
One has 'end else begin', the other has '} else {'.
However the Pascal version can be improved; since 'then' and 'else' >>>>> can act as block delimiters:
˙˙ if cond then s1; s2 end else s3; s4 end
Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.
Unfortunately this doesn't transfer well to C:
˙˙ if (cond) s1; s2; else s3; s4; }
The () around 'cond' are needed as the ')' separates cond and s1
(fir doesn't not appreciate this point; he thinks it is fine for
statements and expressions to run together provided that there is a >>>>> way to infer where one logically ends and the other starts).
The trouble is that lone, unbalanced } at the end.
So it would need a bigger change. But then that's what fir is
doing. (He's never going to get there, but there's no harm in
humouring him.)
what you consider problems is so siple i dont even think on it
as to ifs syntax i am yet not sure
some like this may be considered but its not much good loking
though is sorta logical
x<10 ? x++>5
˙˙˙˙˙˙˙ ?˙ more_than_five
˙˙˙˙˙˙˙ ? less_than_six
˙˙˙˙ ? do_nothing
Try: if 5 < x < 10.
language youre obviously fukll right to implement this philosophy im
not denying this
i waguely remember i sad to you something like "try" or "you my try"
giving some of my outcomes as to my philosophy as i assumed you
want to use something good ;c
im joking (imo ofc my philosophy here is better but you may use your
own ofc)
for me your conventions are suboptimal (all those ones who not by
chance are mine own ;c )
state' though i got different worry (on whch i was saint more than one)
c indeed is on some very impressive track to me and im not quite sure
using my filosophy (which is at seen very fractal and syntax
minimalising) is in fact worse than this oryginal "railroad" track
in old c i by chance see something like 'coal' and 'rails'/railroad
feeling and in this mine i see its more like light and plastic 'style'
not so much nice eventually - it worries my but dont know what to do
with that..maybe its too much far form assembly/machine language but
today hard to work in machne language on raw steel and oil machines..
bart pisze:
On 13/09/2026 14:21, fir wrote:
bart pisze:
On 13/09/2026 11:53, Ike Naar wrote:
On 2026-09-12, bart <bc@freeuk.com> wrote:
Note that the code will still have braces. I suggest a better aim >>>>>> is to
eliminate most braces. The should be no need to ever see '} else {' >>>>>> instead of just 'else'.
There can be a difference; for example (assume <stdio.h> included):
˙˙˙˙ if (0) { if (1) puts("foo");˙˙ else˙˙ puts("bar"); }
˙˙˙˙ if (0) { if (1) puts("foo"); } else { puts("bar"); }
The first line will print nothing; the second one will print "bar".
This illustrates my point; first some Pascal:
˙˙ if cond then begin s1; s2 end else begin s3; s4 end
C is the same but uses braces, and semicolons are terminators:
˙˙ if (cond) { s1; s2; } else { s3; s4; }
One has 'end else begin', the other has '} else {'.
However the Pascal version can be improved; since 'then' and 'else'
can act as block delimiters:
˙˙ if cond then s1; s2 end else s3; s4 end
Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.
Unfortunately this doesn't transfer well to C:
˙˙ if (cond) s1; s2; else s3; s4; }
The () around 'cond' are needed as the ')' separates cond and s1
(fir doesn't not appreciate this point; he thinks it is fine for
statements and expressions to run together provided that there is a
way to infer where one logically ends and the other starts).
The trouble is that lone, unbalanced } at the end.
So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)
what you consider problems is so siple i dont even think on it
as to ifs syntax i am yet not sure
some like this may be considered but its not much good loking
though is sorta logical
x<10 ? x++>5
˙˙˙˙˙˙˙ ?˙ more_than_five
˙˙˙˙˙˙˙ ? less_than_six
˙˙˙˙ ? do_nothing
Try: if 5 < x < 10.
why? its the same
5<x<10 ?
On 09/09/2026 02:59, Waldek Hebisch wrote:
bart <bc@freeuk.com> wrote:
On 08/09/2026 01:02, Waldek Hebisch wrote:
bart <bc@freeuk.com> wrote:
On 07/09/2026 14:33, David Brown wrote:
On 07/09/2026 14:55, bart wrote:
A typical module scheme works like this:
* You have, say, a project of 100 modules
* Each module selectively exports some entities
* Each module selectively imports some subset of the other 99 modules >>>>>>>
OK so far.
The result is that each module starts with some rag-tag collection of >>>>>>> 'import' statements, each different from any other module, and needing >>>>>>> a lot of maintenance.
No.˙ People who write /structured/ code do not do "rag-tag".
When a project is of a size where it is inconvenient to keep track of >>>>>> all the separate "import" (or "#include", or whatever) statements, you >>>>>> use a hierarchy.˙ Instead of importing "dns", "udp", "http", etc., >>>>>> modules, you import "network".˙ The common "network" module pulls in the >>>>>> sub-modules.˙ You probably also organise things in directories and sub- >>>>>> directories, matching the module layout.˙ It is /structured/.
But it's a pattern I've seen a lot. In C also, as collections of
#includes; this example is from Lua, a project of only 35 modules, and >>>>> from one of its .c files:
#include "lprefix.h"
#include <float.h>
#include <limits.h>
#include <math.h>
#include <stdlib.h>
#include "lua.h"
#include "lcode.h"
#include "ldebug.h"
#include "ldo.h"
#include "lgc.h"
#include "llex.h"
#include "lmem.h"
#include "lobject.h"
#include "lopcodes.h"
#include "lparser.h"
#include "lstring.h"
#include "ltable.h"
#include "lvm.h"
Every file has a different set. In all, there are 28K lines of C code >>>>> among the .c files, and there are 466 #include lines. That is similar to >>>>> the maintenance nightmare where each file imports a particular set of >>>>> modules.
The organization looks sensible to me.
Not to me. This project uses these 35 files:
lapi.c lauxlib.c lbaselib.c lcode.c lcorolib.c lctype.c ldblib.c
ldebug.c ldo.c ldump.c lfunc.c lgc.c linit.c liolib.c llex.c
lmathlib.c lmem.c loadlib.c lobject.c lopcodes.c loslib.c lparser.c
lstate.c lstring.c lstrlib.c ltable.c ltablib.c ltests.c ltm.c lua.c
lundump.c lutf8lib.c lvm.c lzio.c onelua.c
(A build will use 34 of them, depending whether it is EXE or DLL.)
With a module scheme, there should be no need for any additional info at >>> all. But my point was, with how such schemes typically work, you still
have lots of mixed sets of 'import' statements at the start of each file. >>>
Given that #include lines
are less than 2% of total and are likely to change very infrequently
I see no maintennce problem.
You can't quantify it like that. In any case, they will only change
infrequently once you've finished development!
If a program is "finished" it will not change at all. During
normal developement I need to add #include lines, but once
added they tend to stay. Sometimes I realize that given
include is not needed or I decide to rename a file. Normal
code is different, first version may have bugs which need
fixing, I may realize that different structure is better, so
there is lot of changes. Relatively to that I perceive changes
to #include lines to be very infrequent.
I found it annoying enough, and taking up enough time to devise a new
way of doing modules. And it is utter bliss.
I agree that maintaing info that you do not value may be annoying.
But if you are used to maintaing C code bases, than maintaining
#include lines does not take much time.
People around here always seems to be making excuses for C!
I find that adding include files, creating headers, maintaining forward declarations etc to be a complete PITA.
Still, modern languages tend to have a module scheme, suggesting theI used or at least looked at several languages with module systems
'flexible' C approach (I'd use the term 'prehistoric') wasn't quite enough. >>
or things intended to perform similar duty. You approach seem to
be unique, all other require explicit import or equivalent at least
in some (rather frequent) cases. Some languages do not support
re-export, in such case you can rightfully complain. The ones with
re-export allow forming common interface module do that number
of import statements is minimised. But this is developers choice
and apparently most prefer to import only needed things, even
though it requires more import statements.
Some even specify individual names to be imported from a module. What a complete waste of time!
It's bad enough listing the modules themselves, of which there may a
dozen or two, but there could be hundreds of imported functions.
A module scheme should mean less work not more.
Module system has other advantages over C. First, in C sane
developers use headers in consistent way, but language
does not enforce it. Typical module system enforces
consistency. Second, module interfaces can be parsed once,
avoiding problem of repeated re-parsing of C headers.
According to David Brown and Scott Lurndal, that is a non-problem!
And according to DB, reducing a large, complex mass of header files (of external library) into one compact file 95% smaller, would be a waste of time.
Third, modules resolve name clashes: the "same" name in
two different modules is disambiguated by its source module.
Fourth, given a main module compiler can track its imports
and build the program without need for separate Makefile.
I tried a scheme in C once. That is, a scheme where you submitted only
the main.c file to the compiler, then it discovered the rest.
It worked well, but required programs to be written in a certain way.
For example, each module file.c required a matching file.h header.
In the main module, you only included the .h files needed by this
module. It would then add those .c files, and applied the process recursively.
However all the projects I wanted to build weren't structured like this.
There are different styles. Ada, Modula 2 and Extended Pascal
use separate interface modules. In typical practice they are
stored in separate files so this looks similar to C practice
of having .c and .h files. Other languages like UCSD/Turbo
Pascal have modules with separate iterface and implementation
parts, but both parts are considered a single module. In
practice with such languages whole module is kept in a single
file, so number of separate files is smaller. But you still
have separate declarations in interface part and definitions
in implementation part. Wirth Oberon (or at least some variant
of it) uses different apprach, IIRC exported functions are
marked putting asterisk before function name. That means less
code to write, but to see what is exported you need a separate
tool.
With separate interface files, who writes the interface: is it the programmer who has to duplicate what is in the implementation? (In which case, what checks are made that it matches?)
Or is it automatic?
My first attempts at (modern) modules tried to do the latter, but it was hard. For example, compile module A.m and it generates A.exp which is
the interface that can be used elsewhere via 'import A'.
But suppose A and B import each other; which is compiled first?
This is an advantage of a manually written interface, in that cyclic
imports become easier, and you don't need a heirarchical structure.
IIUC modules with separate iterface and implementation were
advocated together with database-like storage of source code.
I now work with whole program compilers. There, a discrete interface
file doesn't make sense and is not needed between the modules of the
same program.
But they still exist at the boundaries of the program: when the program imports an external library, or my program is a library that exports functions. In that case, they are only partly automated.
On 13/09/2026 15:34, fir wrote:
bart pisze:
On 13/09/2026 14:21, fir wrote:why? its the same
bart pisze:
On 13/09/2026 11:53, Ike Naar wrote:
On 2026-09-12, bart <bc@freeuk.com> wrote:
Note that the code will still have braces. I suggest a better aim >>>>>>> is to
eliminate most braces. The should be no need to ever see '} else {' >>>>>>> instead of just 'else'.
There can be a difference; for example (assume <stdio.h> included): >>>>>>
˙˙˙˙ if (0) { if (1) puts("foo");˙˙ else˙˙ puts("bar"); }
˙˙˙˙ if (0) { if (1) puts("foo"); } else { puts("bar"); }
The first line will print nothing; the second one will print "bar". >>>>>
This illustrates my point; first some Pascal:
˙˙ if cond then begin s1; s2 end else begin s3; s4 end
C is the same but uses braces, and semicolons are terminators:
˙˙ if (cond) { s1; s2; } else { s3; s4; }
One has 'end else begin', the other has '} else {'.
However the Pascal version can be improved; since 'then' and 'else' >>>>> can act as block delimiters:
˙˙ if cond then s1; s2 end else s3; s4 end
Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.
Unfortunately this doesn't transfer well to C:
˙˙ if (cond) s1; s2; else s3; s4; }
The () around 'cond' are needed as the ')' separates cond and s1
(fir doesn't not appreciate this point; he thinks it is fine for
statements and expressions to run together provided that there is a >>>>> way to infer where one logically ends and the other starts).
The trouble is that lone, unbalanced } at the end.
So it would need a bigger change. But then that's what fir is
doing. (He's never going to get there, but there's no harm in
humouring him.)
what you consider problems is so siple i dont even think on it
as to ifs syntax i am yet not sure
some like this may be considered but its not much good loking
though is sorta logical
x<10 ? x++>5
˙˙˙˙˙˙˙ ?˙ more_than_five
˙˙˙˙˙˙˙ ? less_than_six
˙˙˙˙ ? do_nothing
Try: if 5 < x < 10.
The same as ... what?
I don't know what your example was meant to do. But if testing whether x
was in some interval, and with my example 'x' is only written once.
Otherwise you might want to look at how lots of languages do more
general pattern-matching.>
5<x<10 ?
bart wrote:
On 13/09/2026 10:53, fir wrote:He wants to compress the language, metaphor a plum, into a prune that
fir pisze:
bart pisze:
consider for example french or polish language its totally crypticIt sounds like your ideal language would be APL, if is not 'clean'
and 'clear' that you're after, but 'minimal' and 'cryptic'.
The first version above is the best balance in my view. You /want/
some mixture of keywords and symbols.
In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.
i gave you example - its only cryptic if you dont know what it means
until you will learn it...
That is not your aim. That appears to be to start with a language that
you know perfectly well, but remove all punctuation, capitalisation
and structure, and half the words. But to what purpose; because you're
too lazy to type?
˙˙not to say you want to understand it without
definitions
So an APL (or J or K) program is never cryptic because all you have to
do is learn it? If only I'd thought of that!
The same applies to Assembly I guess. And machine code?
overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things
And you keep repeating the same nonsense. What is your endpoint: a
program that can be expressed in one byte?
has much reduced.
It is the same way with a newsgroup when the warlord Lane W has
compressed all the shitheads, David Brown, Keith, bart, and the rest
except I guess the fellows who are in the mood, when they all conspire
by email to not respond to anything he writes. It is at such a time that
he declares victory. As I roll over yet another group in the 97 I have subjugated to my rule and made complacent, a tear drips from my eye. C,
such a beautiful language, yet what hypocrites such as David Brown
defending it. Really, nothing personal? I beg to differ. Under my boot,
a serpent crawls out of the skull of another victim.
On 2026-09-12, bart <bc@freeuk.com> wrote:
Note that the code will still have braces. I suggest a better aim is to
eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.
There can be a difference; for example (assume <stdio.h> included):
if (0) { if (1) puts("foo"); else puts("bar"); }
if (0) { if (1) puts("foo"); } else { puts("bar"); }
The first line will print nothing; the second one will print "bar".
bart <bc@freeuk.com> wrote:
On 09/09/2026 02:59, Waldek Hebisch wrote:
I find that adding include files, creating headers, maintaining forward
declarations etc to be a complete PITA.
Apparenty you ignored first part above. So, let me expand this.
I see value in specifying interfaces. For me it is important
design information. It takes some time to get it right. Not
time to code or type. It takes time to find good design.
Writing declarations is small part of it.
In my use typical import
statement imports several declarations so is even smaller issue.
I mentioned non-C project where I have about 1200 modules. There
are 1115 import statements. Note that some uses imply/are equivalent
to import, for example there is inheritance of interfaces (given
interface exports everything that its parents export plus usually some additional things), there is probably about 5 thousends of instances
of inheritance. Alternatives would involve duplicating some thousends
of declarations (probably around 10-15 thousends). The system
has about 150000 LOC (215000 wc lines).
Compared to total import
statements and inheritance specifications are small part. And they
are relatively trivial: cases where code compiled but import or
inheritance statements were wrong wre quite rare and they mainly
were cases of missing export or not needed import. Later re-design
may change interfaces, but I mean correctness with respect to design
at time where code was compiled. OTOH normal executable code may
compile fine but behaves completely wrong, so requires more work,
I do not think that C can do what this system is doing. But extrapolating, design in C of similar spirt would probably need say 5000 #include
lines, some hairy macros and 200000-300000 LOC. And executable part
would be much more tricky to get right.
So, I think that your problem is mostly psychological: you consider export/import info as unimportant and it is painful to you to do
work that you consider useless. I consider maintaining export/import
info as important and can do this with resonable efficiency.
Still, modern languages tend to have a module scheme, suggesting the
'flexible' C approach (I'd use the term 'prehistoric') wasn't quite enough.
I used or at least looked at several languages with module systems
or things intended to perform similar duty. You approach seem to
be unique, all other require explicit import or equivalent at least
in some (rather frequent) cases. Some languages do not support
re-export, in such case you can rightfully complain. The ones with
re-export allow forming common interface module do that number
of import statements is minimised. But this is developers choice
and apparently most prefer to import only needed things, even
though it requires more import statements.
Some even specify individual names to be imported from a module. What a
complete waste of time!
If I need 1 or 2 names from a module, then it makes sense to specify
them explicitely.
Mismatched
declarations may cause troubles like crashes or wrong output
that take work to fix. Compared to that mismatches in explicit
declarations are trivial to fix. So one adds some extra work
to write and maintain declarations for benefit of better error
detection and reduction of total work.
Type inference means
almost no reduction in ability to detect errors and some reduction
of work in maintaining declarations. At least in case of C and
C++ type inference optional: you can still give explicit types.
At least your description of of your module system suggest that
it is more like FORTRAN than modern type interface.
Module system has other advantages over C. First, in C sane
developers use headers in consistent way, but language
does not enforce it. Typical module system enforces
consistency. Second, module interfaces can be parsed once,
avoiding problem of repeated re-parsing of C headers.
According to David Brown and Scott Lurndal, that is a non-problem!
And according to DB, reducing a large, complex mass of header files (of
external library) into one compact file 95% smaller, would be a waste of
time.
If they want, they can write what they think about this issue.
Here I am stating my opinion in context of what you wrote.
One problem with C headers is that a single macro can choose
a differenet branch in a header, so you either need some sophisticated
system of dealing with conditionals or you need to re-parse
whenever any macro is defined differently than during previous
With separate interface files, who writes the interface: is it the
programmer who has to duplicate what is in the implementation? (In which
case, what checks are made that it matches?)
In system that I use it is the programmer. System checks that
declaration match.
My first attempts at (modern) modules tried to do the latter, but it was
hard. For example, compile module A.m and it generates A.exp which is
the interface that can be used elsewhere via 'import A'.
But suppose A and B import each other; which is compiled first?
This I resolve with what you would call "whole program compilation".
First pass tries to recognize types. Second pass collects info
about exported functions. I use this in context of explicit interface
parts, but in fact compiler parses everthing and extracts some
information from implementation part. So in principle I could
extract interace based on some markers. After the second pass there
is normal compilation where imports use info colleded in the second
pass. This in not particularly fast, for 150000 LOC I need 3.5s
to extract the interface info. Still, it is small part of the
whole compilation which needs about 300s CPU time (about 38s
real time when using 20 cores).
I now work with whole program compilers. There, a discrete interface
file doesn't make sense and is not needed between the modules of the
same program.
Well, I want well specified interfaces between parts of the program.
With this it is much easier to decide which module is wrong (does not
comply with its interface) and consequently to fix bugs.
Also
I have modules which can use use one of several other modules.
That is module M can use function from A, B, C, ... and it should
work correctly which each one. As long as A, B, C, ... have the
same interface I can test that M works with say A and the A, B, C, ...
in fact implement the same interface and after that expect that
M will also work with B or C. Without well specified interfaces
that would be much harder (or impossible).
In different context, one may have collection of modules such that
some subsets form programs. That is particularly relevant for microcontrollers, where target is too small to include all available
modules. Also, different microcontrollers may need different
(alternative) hardware specific modules. In such situation you
do not want to leak hardware specific details to general modules.
And in general, you want to limit what is pulled in only to stuff
that is actually needed.
On 13/09/2026 19:55, Waldek Hebisch wrote:
bart <bc@freeuk.com> wrote:
On 09/09/2026 02:59, Waldek Hebisch wrote:
I find that adding include files, creating headers, maintaining forward
declarations etc to be a complete PITA.
Apparenty you ignored first part above. So, let me expand this.
I see value in specifying interfaces. For me it is important
design information. It takes some time to get it right. Not
time to code or type. It takes time to find good design.
Writing declarations is small part of it.
Sure. But interfaces to what? To some sort of library?
And it isn't really much to do with modules. C libraries have
interfaces, usually as headers, but it doesn't have modules.
A more typical problem is organising the functions, variables, types,
enums and tables of an application into multiple modules: what goes
where; what needs to be shared.
Once you have your N modules, then that's the list the language's module scheme uses to build your app.
A formal interface would be used for external libraries, or for internal libraries where a group of modules form a private sub-program.
In my use typical import
statement imports several declarations so is even smaller issue.
I mentioned non-C project where I have about 1200 modules. There
are 1115 import statements. Note that some uses imply/are equivalent
to import, for example there is inheritance of interfaces (given
interface exports everything that its parents export plus usually some
additional things), there is probably about 5 thousends of instances
of inheritance. Alternatives would involve duplicating some thousends
of declarations (probably around 10-15 thousends). The system
has about 150000 LOC (215000 wc lines).
If you have 215Kloc and 1200 modules, then you have other challenges
than a module scheme. (That's some 0.18Kloc/module on average, while my stuff might be more like 1Kloc, and used to be nearer 2Kloc.)
But I'm surprised you only have about one import statement per file: is
it the same project-wide interface file, or is each much more specific?
Compared to total import
statements and inheritance specifications are small part. And they
are relatively trivial: cases where code compiled but import or
inheritance statements were wrong wre quite rare and they mainly
were cases of missing export or not needed import. Later re-design
may change interfaces, but I mean correctness with respect to design
at time where code was compiled. OTOH normal executable code may
compile fine but behaves completely wrong, so requires more work,
I do not think that C can do what this system is doing. But extrapolating, >> design in C of similar spirt would probably need say 5000 #include
lines, some hairy macros and 200000-300000 LOC. And executable part
would be much more tricky to get right.
I'm now curious as to what weird things you're doing. Is this other language/scheme one like C++, or something that you have devised?
So, I think that your problem is mostly psychological: you consider
export/import info as unimportant and it is painful to you to do
work that you consider useless. I consider maintaining export/import
info as important and can do this with resonable efficiency.
As I suggested above, perhaps 'import/export' are too-strong terms for talking about sharing between friendly modules of the same subprogram.
(A 'subprogram' is my language is one building block down from
'program', which equates to a single EXE or DLL binary. 'Module' is just below that and that corresponds to one source file.)
Meanwhile interfaces between programs (ie. between EXE/DLL files) is something that doesn't come up often for me; it is a different subject,
and something I would also apply automatic methods to as much as
possible. It is FFI more than modules.
Still, modern languages tend to have a module scheme, suggesting the >>>>> 'flexible' C approach (I'd use the term 'prehistoric') wasn't quite enough.
I used or at least looked at several languages with module systems
or things intended to perform similar duty. You approach seem to
be unique, all other require explicit import or equivalent at least
in some (rather frequent) cases. Some languages do not support
re-export, in such case you can rightfully complain. The ones with
re-export allow forming common interface module do that number
of import statements is minimised. But this is developers choice
and apparently most prefer to import only needed things, even
though it requires more import statements.
Some even specify individual names to be imported from a module. What a
complete waste of time!
If I need 1 or 2 names from a module, then it makes sense to specify
them explicitely.
I don't see why. Unless you mean it is more important to exclude the
names you haven't listed?
Support a library or module M exports functions A - F. You'd write:
import M
then later you can write M.A() to M.F() without doing anything else.
Suppose you only need function D. In that case you just call M.D();
nothing is forcing you to call M.E() too!
If this is about not having to include those functions in the binary,
then that would be something for the language to deal with: it knows
which functions have called, and knows those are the ones to import.
Mismatched
declarations may cause troubles like crashes or wrong output
that take work to fix. Compared to that mismatches in explicit
declarations are trivial to fix. So one adds some extra work
to write and maintain declarations for benefit of better error
detection and reduction of total work.
What benefits are these? All I can see are loads of annoying errors
because you've forgotten to declare entities.
Type inference means
almost no reduction in ability to detect errors and some reduction
of work in maintaining declarations. At least in case of C and
C++ type inference optional: you can still give explicit types.
At least your description of of your module system suggest that
it is more like FORTRAN than modern type interface.
Type inference and modules are different things. Modules manage
visibility named entities including types across source files.
With my whole-program scheme, there will never be type mismatches across
the sources files of a particular program. That can only happen when interface/API info and implementation or binary are separate.
(Type inference is minimal, nothing like H-M. In any case my Modules
work the same way across two languages, one fully typed and static, the other dynamically typed.)
Module system has other advantages over C. First, in C sane
developers use headers in consistent way, but language
does not enforce it. Typical module system enforces
consistency. Second, module interfaces can be parsed once,
avoiding problem of repeated re-parsing of C headers.
According to David Brown and Scott Lurndal, that is a non-problem!
And according to DB, reducing a large, complex mass of header files (of
external library) into one compact file 95% smaller, would be a waste of >>> time.
If they want, they can write what they think about this issue.
They're users who are proficient in their tools. Nothing ever seem to be
a problem - that superfast hardware and dozens of parallel cores can't
fix! I've learnt from experience that even a build time of minutes
(where the result might be a mere 1MB binary) doesn't faze them.
Oh, it's a 'one-off', or they are not curious as to why a simple task
isn't faster.
Basically they are not interested in any merits of my solutions.
Here I am stating my opinion in context of what you wrote.
One problem with C headers is that a single macro can choose
a differenet branch in a header, so you either need some sophisticated
system of dealing with conditionals or you need to re-parse
whenever any macro is defined differently than during previous
All the problems with C headers would be a big subject by itself!
With separate interface files, who writes the interface: is it the
programmer who has to duplicate what is in the implementation? (In which >>> case, what checks are made that it matches?)
In system that I use it is the programmer. System checks that
declaration match.
C uses the 'linkage' system for functions and variables. It uses text replication to share entities such as types, structs, enumerations and macros. How do other language's modules cope with the latter?
(I only know about Python. My languages of course handle all those too.)
My first attempts at (modern) modules tried to do the latter, but it was >>> hard. For example, compile module A.m and it generates A.exp which is
the interface that can be used elsewhere via 'import A'.
But suppose A and B import each other; which is compiled first?
This I resolve with what you would call "whole program compilation".
First pass tries to recognize types. Second pass collects info
about exported functions. I use this in context of explicit interface
parts, but in fact compiler parses everthing and extracts some
information from implementation part. So in principle I could
extract interace based on some markers. After the second pass there
is normal compilation where imports use info colleded in the second
pass. This in not particularly fast, for 150000 LOC I need 3.5s
to extract the interface info. Still, it is small part of the
whole compilation which needs about 300s CPU time (about 38s
real time when using 20 cores).
This is that 215Kloc project? 300s (approx time for single core) is
pretty slow for that. What is the problem here; the language being hard
to process?
(As you know my stuff works perhaps 3 magnitudes faster, assuming your machine is faster.
Although I am currently investigating why my C compiler takes 0.12
seconds to process some 0.5M lines of SDL3 headers when TCC takes only
0.05 seconds. I'm just curious.
An odd fact I discovered today: if SDL3 headers (86 files/82Kloc) are preprocessed, the result is only 4000 lines and 27K tokens, even though
550K lines are processed according to my compiler (but maybe that's why
it's slow).
This output is not enough to use as a new compact header; it will need #defines etc that have been stripped. But it shows the core of the API
is quite small. I will investigate further.)
I now work with whole program compilers. There, a discrete interface
file doesn't make sense and is not needed between the modules of the
same program.
Well, I want well specified interfaces between parts of the program.
With this it is much easier to decide which module is wrong (does not
comply with its interface) and consequently to fix bugs.
As I said, many of my modules are friendly. I don't care about formal interfaces. When I do, a module or several can form their own more
private group.
This makes coding much, much simpler.
Also
I have modules which can use use one of several other modules.
That is module M can use function from A, B, C, ... and it should
work correctly which each one. As long as A, B, C, ... have the
same interface I can test that M works with say A and the A, B, C, ...
in fact implement the same interface and after that expect that
M will also work with B or C. Without well specified interfaces
that would be much harder (or impossible).
When happens when A gets too big and you want to split it into A1 and
A2; will it need a new formal interface between them?
In different context, one may have collection of modules such that
some subsets form programs. That is particularly relevant for
microcontrollers, where target is too small to include all available
modules. Also, different microcontrollers may need different
(alternative) hardware specific modules. In such situation you
do not want to leak hardware specific details to general modules.
And in general, you want to limit what is pulled in only to stuff
that is actually needed.
I work with a 64-bit supercomputer with huge amounts of memory. (In
other words, the second-cheapest PC in the shop.)
Still, last year I adapted my systems language to work with an emulated
Z80 system, and the module scheme still worked!
Yes, the memory is more limited, you just have less stuff in the
modules. The scheme allows for some flexibility.
And it isn't really much to do with modules. C libraries have
interfaces, usually as headers, but it doesn't have modules.
bart pisze:
And it isn't really much to do with modules. C libraries have
interfaces, usually as headers, but it doesn't have modules.
out of contex as i not readed most of this branch but obviously C has modules
if you may compile some c files with no resolved 'linkage' to like .o
or .obj etc they are modules
bart <bc@freeuk.com> wrote:
A more typical problem is organising the functions, variables, types,
enums and tables of an application into multiple modules: what goes
where; what needs to be shared.
You may view interface as information about what needs to be shared,
but IMO there is more to this. In badly designed program a lot
must be shared. In well designed program and assuming that problem
domain is suitable for modularization sharing is quite limited.
And frequently is is possible to replace implementation part by
quite a different thing without affectiong correctness of the
program.
To make a concrete example, I needed simple varianat of regular
expressions. In principle I could call existing library via FFI, but
that had its own problems. Since the core algorithm is quite simple
I decided to roll my own. I ended with collection of 4 modules.
One module implements a single node of automation, second one
implements matching algorithm and build automation (that is graph
of nodes) from other data. Third module provides a higher level abstractions, representing patterns build from simpler automatons
via boolean operations. Fourth module contains a parser which
converts textual patterns to internal representation, using
operations provided by earlier modules. Together this is 452
wc lines. One may be tempted to do this a single module, but
I think that what I did have better structure: first module
essentially defines data struture (or maybe I should say data
type) and in principle this could be part of the second module.
But having module means that some things are hidden and some
are exported in nicer form. So I do not consider having this
as a separtate module as a big deal, but I think that overall
thanks to this code is a little nicer. Second module implements
core algorithm. IMO is is nice that this code is not mixed
with other parts and also it is potentially reusable in the
future. Third module implements feature that I needed, it
is something that AFAIK is not supported by standard libraries
so I would need it even if I decided to scrap the first two
modules and replace them by FFI calls to some standard library.
The actual syntax of supported patterns is confined to the
fourth module. If I needed different syntax (possibly with
different featurs set) I can provide an alternative parser
module. As you later write those are "friendly" modules
designed to work together. But each of them have reasonably
well specified responsibilities. And since responsiblity
of each module is rather narrow, each of them is simple,
almost trivial. Functionality provided by this collection
of 4 modules is not very impressive, but less trivial than
each of the involved modules.
To summarise using this example 4-module library:
˙ (1) Add 4 'module' directives to my own app
˙ (2) Put them into rex.m then add 'module rex' to my app
˙ (3) Put them into rex.m, build as DLL, then add 'module rex/rex_lib'And that module contains 'importdll rex`, yet a further level in my
˙˙˙˙˙ to my app
On 14/09/2026 08:49, fir wrote:
bart pisze:
And it isn't really much to do with modules. C libraries have
interfaces, usually as headers, but it doesn't have modules.
out of contex as i not readed most of this branch but obviously C has
modules
if you may compile some c files with no resolved 'linkage' to like .o
or .obj etc they are modules
No. We might informally use 'modules' to mean individual source files or translation units. A program may comprise multiple translation units. C allows independent compilation of such units and there needs to be a
linking process to combine them.
This is not the same as a language supporting a proper module scheme. Otherwise even Assembly has modules!
Without modules, building a program in C looks like this:
˙ tcc prog.c a.c b.c c.c d.c e.c ...
With modules, it would be just:
˙ tcc prog.c
Both produce prog.exe. This illustrates automatic discovery of the
source files, but real modules would have other benefits too.
bart pisze:
On 14/09/2026 08:49, fir wrote:No, C has modules those compilation units are modules (it that make
bart pisze:
And it isn't really much to do with modules. C libraries have
interfaces, usually as headers, but it doesn't have modules.
out of contex as i not readed most of this branch but obviously C has
modules
if you may compile some c files with no resolved 'linkage' to like .o
or .obj etc they are modules
No. We might informally use 'modules' to mean individual source files
or translation units. A program may comprise multiple translation
units. C allows independent compilation of such units and there needs
to be a linking process to combine them.
This is not the same as a language supporting a proper module scheme.
Otherwise even Assembly has modules!
Without modules, building a program in C looks like this:
˙˙ tcc prog.c a.c b.c c.c d.c e.c ...
With modules, it would be just:
˙˙ tcc prog.c
Both produce prog.exe. This illustrates automatic discovery of the
source files, but real modules would have other benefits too.
binary modules that you can then link)
ofc those modules are quite 'thin' or how to call it but for shure those
are modules.. what you cay with this example is specific functionality related to modules but not all need to have it
(also no need to enlight me on things i was talking quite clearly and
loudly many years ago (as far as i remember my first post oon this group
was on related things - i mean the problem that c cupports those modules
but dont support module names and it may simply make crash or clask of symbols
Ike Naar <ike@sdf.org> writes:
On 2026-09-12, bart <bc@freeuk.com> wrote:
Note that the code will still have braces. I suggest a better aim is to >>> eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.
There can be a difference; for example (assume <stdio.h> included):
if (0) { if (1) puts("foo"); else puts("bar"); }
if (0) { if (1) puts("foo"); } else { puts("bar"); }
The first line will print nothing; the second one will print "bar".
I believe bart was suggesting a language change, not offering advice
on how to program in C.
In C, the syntax for an "if" statement is:
if ( expression ) statement
if ( expression ) statement else statement
(C23 tweaks this very slightly in ways that are not relevant to
the current discussion.) Since it's defined in terms of single
statements, if you want multiple statements in a branch you need to
create one by enclosing multiple statements in braces. This also
requires a rule about which "if" a given "else" is associated with.
Many other langauges allow multiple statements where C only allows
a single statement. They typically do so by requiring a closing
delimiter matching the "if", for example "endif", "end if", "end",
or "fi". They also typically add a single token combining "else"
and "if", typically "elseif", "elsif", or "elif".
(Pascal follows the C approach, but spells "{" and "}" as "begin"
and "end".)
It's not practical to follow bart's advice (always use "else" rather
than "} else {" unless you're using some language other than C.
bart's point, I think, is that he dislikes the way C does this.
Personally, I tend to prefer the non-C delimited approach, since
it's a bit less error-prone, but both approaches are perfectly
valid and can be used cleanly and correctly with a little care.
It's not a factor I consider when deciding which language to use.
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Personally, I tend to prefer the non-C delimited approach, since
it's a bit less error-prone, but both approaches are perfectly
valid and can be used cleanly and correctly with a little care.
It's not a factor I consider when deciding which language to use.
I simply always use braces, regardless of whether or not
the clause contains a single statement or a compound statement.
I simply always use braces, regardless of whether or not
the clause contains a single statement or a compound statement.
That's always a safe choice, but some C programmers prefer to use fewer braces.˙ A compromise is to insist on always using braces if there is an "else" clause (in both the "if" and "else" parts), or at the very least,
to do so if there are nested "if" statements.
On 14/09/2026 17:01, Scott Lurndal wrote:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Personally, I tend to prefer the non-C delimited approach, since
it's a bit less error-prone, but both approaches are perfectly
valid and can be used cleanly and correctly with a little care.
It's not a factor I consider when deciding which language to use.
I simply always use braces, regardless of whether or not
the clause contains a single statement or a compound statement.
That's always a safe choice, but some C programmers prefer to use fewer >braces. A compromise is to insist on always using braces if there is an >"else" clause (in both the "if" and "else" parts), or at the very least,
to do so if there are nested "if" statements.
Always using braces (combined with a consistent indent style) is the
choice with the lowest risk of mistakes or misinterpretation, and means
that changes such as adding or removing statements to the controlled
parts do not lead to additional changes. For anyone using version
control systems, the advantage of :
if (test) {
do_this();
}
over :
if (test)
do_this();
is obvious the first time they need to change the code to :
if (test) {
do_this();
do_that();
}
On 9/9/2026 5:43 AM, David Brown wrote:
[...]
Just defining the symbol is fine - for use as a pure header guard, where________
the check is with "#ifndef" or "#ifdef", defining it to a value has no
added value.˙ Adding the "1" in that example was done without thinking.
#ifndef __NUMBER_GENERATOR_H__
#define __NUMBER_GENERATOR_H__ 1
________
Is that __* non conformant? Does it breach the impl name prefix space?
On 9/14/26 18:11, David Brown wrote:
I simply always use braces, regardless of whether or not
the clause contains a single statement or a compound statement.
That's always a safe choice, but some C programmers prefer to use
fewer braces.˙ A compromise is to insist on always using braces if
there is an "else" clause (in both the "if" and "else" parts), or at
the very least, to do so if there are nested "if" statements.
˙˙ About braces, I always use them except in one case :
˙˙ when the code fragment is on the same line as the if.
˙˙ if (retval) fprintf(stderr, "retval is %d\n", retval);
˙˙ I think it's dangerous, but for some little things
˙˙ like my sample, it make things clearer for me.
David Brown <david.brown@hesbynett.no> writes:
On 14/09/2026 17:01, Scott Lurndal wrote:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Personally, I tend to prefer the non-C delimited approach, since
it's a bit less error-prone, but both approaches are perfectly
valid and can be used cleanly and correctly with a little care.
It's not a factor I consider when deciding which language to use.
I simply always use braces, regardless of whether or not
the clause contains a single statement or a compound statement.
That's always a safe choice, but some C programmers prefer to use fewer
braces. A compromise is to insist on always using braces if there is an
"else" clause (in both the "if" and "else" parts), or at the very least,
to do so if there are nested "if" statements.
Always using braces (combined with a consistent indent style) is the
choice with the lowest risk of mistakes or misinterpretation, and means
that changes such as adding or removing statements to the controlled
parts do not lead to additional changes. For anyone using version
control systems, the advantage of :
if (test) {
do_this();
}
over :
if (test)
do_this();
is obvious the first time they need to change the code to :
if (test) {
do_this();
do_that();
}
That's true for anyone still using 80-column punched cards
(or ancient line-oriented editors) as well.
:-)
On 14/09/2026 20:54, Scott Lurndal wrote:
David Brown <david.brown@hesbynett.no> writes:
On 14/09/2026 17:01, Scott Lurndal wrote:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Personally, I tend to prefer the non-C delimited approach, since
it's a bit less error-prone, but both approaches are perfectly
valid and can be used cleanly and correctly with a little care.
It's not a factor I consider when deciding which language to use.
I simply always use braces, regardless of whether or not
the clause contains a single statement or a compound statement.
That's always a safe choice, but some C programmers prefer to use fewer
braces. A compromise is to insist on always using braces if there is an >>> "else" clause (in both the "if" and "else" parts), or at the very least, >>> to do so if there are nested "if" statements.
Always using braces (combined with a consistent indent style) is the
choice with the lowest risk of mistakes or misinterpretation, and means
that changes such as adding or removing statements to the controlled
parts do not lead to additional changes. For anyone using version
control systems, the advantage of :
if (test) {
do_this();
}
over :
if (test)
do_this();
is obvious the first time they need to change the code to :
if (test) {
do_this();
do_that();
}
That's true for anyone still using 80-column punched cards
(or ancient line-oriented editors) as well.
:-)
I don't quite follow you. (I use line lengths up to perhaps 120
characters, but not rigidly fixed.)
On 14/09/2026 20:21, tTh wrote:
On 9/14/26 18:11, David Brown wrote:
I simply always use braces, regardless of whether or not
the clause contains a single statement or a compound statement.
That's always a safe choice, but some C programmers prefer to use
fewer braces.˙ A compromise is to insist on always using braces if
there is an "else" clause (in both the "if" and "else" parts), or at
the very least, to do so if there are nested "if" statements.
˙˙˙ About braces, I always use them except in one case :
˙˙˙ when the code fragment is on the same line as the if.
˙˙˙ if (retval) fprintf(stderr, "retval is %d\n", retval);
˙˙˙ I think it's dangerous, but for some little things
˙˙˙ like my sample, it make things clearer for me.
I do the same, but restrict it to simpler statements.
"Simpler" is a matter of taste and subjective judgement here -
"return;", "break;", "continue;" are all "simple".˙ A short assignment
is "simple".˙ For a longer printf, I'd usually use braces.˙ If the
statement is too long to be comfortable on one line, or may reasonably become so in future modifications, then I'd have braces.
David Brown <david.brown@hesbynett.no> writes:
On 14/09/2026 17:01, Scott Lurndal wrote:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Personally, I tend to prefer the non-C delimited approach, since
it's a bit less error-prone, but both approaches are perfectly
valid and can be used cleanly and correctly with a little care.
It's not a factor I consider when deciding which language to use.
I simply always use braces, regardless of whether or not
the clause contains a single statement or a compound statement.
That's always a safe choice, but some C programmers prefer to use fewer
braces. A compromise is to insist on always using braces if there is an
"else" clause (in both the "if" and "else" parts), or at the very least,
to do so if there are nested "if" statements.
Always using braces (combined with a consistent indent style) is the
choice with the lowest risk of mistakes or misinterpretation, and means
that changes such as adding or removing statements to the controlled
parts do not lead to additional changes. For anyone using version
control systems, the advantage of :
if (test) {
do_this();
}
over :
if (test)
do_this();
is obvious the first time they need to change the code to :
if (test) {
do_this();
do_that();
}
That's true for anyone still using 80-column punched cards
(or ancient line-oriented editors) as well.
:-)
bart <bc@freeuk.com> wrote:....> As I wrote I can use equvalent of M.A() without import.
As I wrote, there is inheritance which is used much more frequently
than import. And import means that all functions from imported
module may be used without qualification. That is if module A
exports function f, than after importing A I can just write 'f()'
to call 'f' (assuming it needs no arguments).
In my case import means that functions are available without
qualification, so plain E() may call function from imported module.
And I have function overloading and partial type inference. In
effect, it is not entirely trivial to decide which function is
actually called when you write E(). Most functions either needs
arguments or produces values (or both), so calling wrong functions
almost surely is not a big problem, that is either overloading
machinery would choose the correct one, or call to wrong one will
result in type error. But still, I think that is better to limit
possible confusion and import as little as possible.
More generally, I also worked with dynamic languages where one
simply calls a function and types of arguments are only checked
on use. IME code in such languages needs a lot of testing, much
more than with type checking. That is without type checking
it is too easy to ship code which calls a function with argument
of wrong type. Clearly to check types compiler must know them.
And absent total type reconstrution (like in ML), one needs to
declare types of arguments and return type of functions.
So I hope that is part is clear.
You may doubt necessity of having duplicate declaration in the
module interface. In principle compiler could do all needed
checks having only single declaration. But compilers that I
use need declaration in interface part. And when reading code I
actually prefer to have both declarations. Namely, when looking
at interactions between modules I look at interface parts and
want to see relevant declarations there.
When working on inner
part of module I want relevant info there. For example, I disliked
standard Pascal rule that forward declaration contained all
info, but corresponding defintion contained just function name
skipping arguments types and names. For me extra effort during
reading, due to extral lookup for missing info meant more work
compared to cut-and-paste needed to duplicate function header.
Type inference means
almost no reduction in ability to detect errors and some reduction
of work in maintaining declarations. At least in case of C and
C++ type inference optional: you can still give explicit types.
At least your description of of your module system suggest that
it is more like FORTRAN than modern type interface.
Type inference and modules are different things. Modules manage
visibility named entities including types across source files.
Sure. I mentioned type inference to illustrate that approach may
change and if compiler can infer needed information, then languages
may depend on this saving programmer work. But gross rules like
firt letter rule of old FORTRAN (or implicit int from traditional
C) are unsatisfactory. And when talking about modules your
rule "all modules are visible" looks more like old gross rules and
unlike inference process.
C uses the 'linkage' system for functions and variables. It uses text
replication to share entities such as types, structs, enumerations and
macros. How do other language's modules cope with the latter?
Typical approach is to have compiled version of interface. That
requires some method to write such info to files. IIUC GNU C
precompiled headers use (or used) crude but simple method: they
just dumpled memory area containing intenal compiler representation
of the header. This is simple and fast, but any tiny mismatch could
lead to error, so this mechanizm has serious limitations and is
unsuitable for use with modules. GNU Pascal walked internal tree
of nodes, keeping visted nodes in a hash table to make sure that
needed node is stored exactly one. During storing each node was
assigned integer identifier and all pointers were repleaced by
identifiers (numbers) of taget node. Reading worked in reverse:
it re-build nodes in memory, replacing numeric indentifiers by
pointers.
The system I mentioned above writes interface information in textual
form, but it is easier to parse and more explicit than source code.
This is that 215Kloc project? 300s (approx time for single core) is
pretty slow for that. What is the problem here; the language being hard
to process?
In addition compiler uses linear search in symbol table.
Getting rid of recursion and implied by this multiple re-compilation
probably would give 3-5 times faster compilation (and hopefully
would eliminate really bad cases). If things could be simplified
so that hash table is enough, that probably would double speed.
Once that is handled other things would requre attention. But
it does not make much sense to fight for small speedups in other
places when biggest issues (that is recursive compilation and
linear search are unresolved). And that require substantial
rework. Even after rework compiler is unlikly to be as fast as
yours. Namely overloading and type inference
Also, compiler is using higher level data structures that
has its own costs. Parsing this 215K wc lines takes 1 second,
while it should be possible to do this in 0.1 second. But
again, before other issues are handled relative gain from
faster parser is too small to bother (I may speed up parser
if I need to reorganize it to implement some extra feature).
BTW: It is hard to compare compile speed in longer time because
machines got faster. But when I started my work build needed
something like 2.5 hours,
When I need to look at preprocessed files I frequently see a lot of
blank lines, so I am not surprised that headers get smaller. At first
glance 4000 lines after preprocessing looks too small, but maybe it
is real.
This output is not enough to use as a new compact header; it will need
#defines etc that have been stripped. But it shows the core of the API
is quite small. I will investigate further.)
At some time I did a little work on Mac OS API. There was about
220 tousends symbols, of which something like 200 tousends where
various magic constants. So, maybe bulk od SDL3 headers is due
to defiend constants?
On 14/09/2026 08:41, Waldek Hebisch wrote:
bart <bc@freeuk.com> wrote:
As I wrote, there is inheritance which is used much more frequently....> As I wrote I can use equvalent of M.A() without import.
than import. And import means that all functions from imported
module may be used without qualification. That is if module A
exports function f, than after importing A I can just write 'f()'
to call 'f' (assuming it needs no arguments).
Do you mean that you can call imported function A() without importing
its owner module M()?
Above (in the example that uses A.f() instead of M.A()) you suggest the module name must be explicitly exported.
Otherwise there must be some other approach for the compiler to know
what imports are to be done. (I think some schemes are file-based: eg.
all source files in the current directory are assumed to be project modules.)
In my case import means that functions are available without
qualification, so plain E() may call function from imported module.
And I have function overloading and partial type inference. In
effect, it is not entirely trivial to decide which function is
actually called when you write E(). Most functions either needs
arguments or produces values (or both), so calling wrong functions
almost surely is not a big problem, that is either overloading
machinery would choose the correct one, or call to wrong one will
result in type error. But still, I think that is better to limit
possible confusion and import as little as possible.
My language only allows one top-level name E in scope at any one
location. If two imported modules both export E, then the compiler will complain; they need to be disambiguated.
There is also shadowing, so here it is possible to mistakenly call a
local function that happens to have the same name and signature.
But such problems are well-known when you have nested scopes, and you
see them in other languages too.
More generally, I also worked with dynamic languages where one
simply calls a function and types of arguments are only checked
on use. IME code in such languages needs a lot of testing, much
more than with type checking. That is without type checking
it is too easy to ship code which calls a function with argument
of wrong type. Clearly to check types compiler must know them.
And absent total type reconstrution (like in ML), one needs to
declare types of arguments and return type of functions.
So I hope that is part is clear.
I have a lot of experience of dynamic languages that ran at customer
sites. Such language errors were extremely rare.
It's not that I did extensive testing, but with normal development over
a longish time-frame (eg. 1-2 years), you will uncover a lot of bugs!
You may doubt necessity of having duplicate declaration in the
module interface. In principle compiler could do all needed
checks having only single declaration. But compilers that I
use need declaration in interface part. And when reading code I
actually prefer to have both declarations. Namely, when looking
at interactions between modules I look at interface parts and
want to see relevant declarations there.
The duplicate declarations are necessary in some situations. For example
you don't have the implementation source code, but that info is
necessary to be able to use those exports in your program.
However, they could be automatically generated by whoever /does/ have
the source code, by a compiler option.
When working on inner
part of module I want relevant info there. For example, I disliked
standard Pascal rule that forward declaration contained all
info, but corresponding defintion contained just function name
skipping arguments types and names. For me extra effort during
reading, due to extral lookup for missing info meant more work
compared to cut-and-paste needed to duplicate function header.
I don't remember that in Pascal. However I remember similar schemes from
my own early languages. Functions were routinely declared in advance, whether necessary or not (I didn't want to worry about definition order).
But the declaration contained only the parameter types, and the
definition contained only the parameter names! I recently rediscovered
this fact and wondered how I tolerated it.
Type inference means
almost no reduction in ability to detect errors and some reduction
of work in maintaining declarations. At least in case of C and
C++ type inference optional: you can still give explicit types.
At least your description of of your module system suggest that
it is more like FORTRAN than modern type interface.
Type inference and modules are different things. Modules manage
visibility named entities including types across source files.
Sure. I mentioned type inference to illustrate that approach may
change and if compiler can infer needed information, then languages
may depend on this saving programmer work. But gross rules like
firt letter rule of old FORTRAN (or implicit int from traditional
C) are unsatisfactory. And when talking about modules your
rule "all modules are visible" looks more like old gross rules and
unlike inference process.
Well, all functions and other top-level names are visible everywhere
inside one module. That is not usually considered a problem.
Since you mentioned big modules, I will say that in my old stuff, one
module had 7K lines (an interpreter core), and another nearly 6K (a
one-pass bytecode compiler), although bloated by inline assembly.
This is basically taking such a module and splitting it up into N
chunks. Entities used in more than one chunk need to be shared.
C uses the 'linkage' system for functions and variables. It uses text
replication to share entities such as types, structs, enumerations and
macros. How do other language's modules cope with the latter?
Typical approach is to have compiled version of interface. That
requires some method to write such info to files. IIUC GNU C
precompiled headers use (or used) crude but simple method: they
just dumpled memory area containing intenal compiler representation
of the header. This is simple and fast, but any tiny mismatch could
lead to error, so this mechanizm has serious limitations and is
unsuitable for use with modules. GNU Pascal walked internal tree
of nodes, keeping visted nodes in a hash table to make sure that
needed node is stored exactly one. During storing each node was
assigned integer identifier and all pointers were repleaced by
identifiers (numbers) of taget node. Reading worked in reverse:
it re-build nodes in memory, replacing numeric indentifiers by
pointers.
The system I mentioned above writes interface information in textual
form, but it is easier to parse and more explicit than source code.
I was asking more about managing the names of variables, types etc
across modules. In C that is very crude, and it can be unintuitive.
As I do it, all of these named, top-level entities:
functions
variables
named constants
enumerations
user-defined types and records
macros
are handled in the same way: stick 'global' or 'export' in front of the definitions, and it makes the names visible outside the module.
I was asking if the same applied to other languages.
This is that 215Kloc project? 300s (approx time for single core) is
pretty slow for that. What is the problem here; the language being hard
to process?
In addition compiler uses linear search in symbol table.
Actually I use linear searching extensively too. Except in the global
symbol table which is a hash-table. So lexical lookups use that, but resolving a generic identifier into a special one uses linear methods.
Generally it is still very fast because the lists are short. But some programs could cause it trouble.
Getting rid of recursion and implied by this multiple re-compilation
probably would give 3-5 times faster compilation (and hopefully
would eliminate really bad cases). If things could be simplified
so that hash table is enough, that probably would double speed.
Once that is handled other things would requre attention. But
it does not make much sense to fight for small speedups in other
places when biggest issues (that is recursive compilation and
linear search are unresolved). And that require substantial
rework. Even after rework compiler is unlikly to be as fast as
yours. Namely overloading and type inference
So, is type inference (eg. Hindley-Milner) inherently slow?
Also, compiler is using higher level data structures that
has its own costs. Parsing this 215K wc lines takes 1 second,
while it should be possible to do this in 0.1 second. But
again, before other issues are handled relative gain from
faster parser is too small to bother (I may speed up parser
if I need to reorganize it to implement some extra feature).
BTW: It is hard to compare compile speed in longer time because
machines got faster. But when I started my work build needed
something like 2.5 hours,
I would never have tolerated that. I considered it part of my job to
make sure my tools stayed productive whatever the hardware.
When I need to look at preprocessed files I frequently see a lot of
blank lines, so I am not surprised that headers get smaller. At first
glance 4000 lines after preprocessing looks too small, but maybe it
is real.
I can tell you that 1/3 of my processing type is to do with comments.
(After stripping them it took 2/3 as long.) So I might look at how efficiently that is done, for a start. But there is a lot of mystery still.
This output is not enough to use as a new compact header; it will need
#defines etc that have been stripped. But it shows the core of the API
is quite small. I will investigate further.)
At some time I did a little work on Mac OS API. There was about
220 tousends symbols, of which something like 200 tousends where
various magic constants. So, maybe bulk od SDL3 headers is due
to defiend constants?
From the end result (via a tool to convert to my bindings), there are
about 500 #defines and 1100 enum names. But probably there are lots of duplicates in the headers, some may be in 'dead' blocks. And some
headers are processed more than once.
It's messy, but it seems a big downside of C's 'module' scheme!
And of course, all the work has to be repeated for each file that
includes SDK.h.
On 14/09/2026 08:41, Waldek Hebisch wrote:
bart <bc@freeuk.com> wrote:
A more typical problem is organising the functions, variables, types,
enums and tables of an application into multiple modules: what goes
where; what needs to be shared.
You may view interface as information about what needs to be shared,
but IMO there is more to this. In badly designed program a lot
must be shared. In well designed program and assuming that problem
domain is suitable for modularization sharing is quite limited.
And frequently is is possible to replace implementation part by
quite a different thing without affectiong correctness of the
program.
To make a concrete example, I needed simple varianat of regular
expressions. In principle I could call existing library via FFI, but
that had its own problems. Since the core algorithm is quite simple
I decided to roll my own. I ended with collection of 4 modules.
One module implements a single node of automation, second one
implements matching algorithm and build automation (that is graph
of nodes) from other data. Third module provides a higher level
abstractions, representing patterns build from simpler automatons
via boolean operations. Fourth module contains a parser which
converts textual patterns to internal representation, using
operations provided by earlier modules. Together this is 452
wc lines. One may be tempted to do this a single module, but
I think that what I did have better structure: first module
essentially defines data struture (or maybe I should say data
type) and in principle this could be part of the second module.
But having module means that some things are hidden and some
are exported in nicer form. So I do not consider having this
as a separtate module as a big deal, but I think that overall
thanks to this code is a little nicer. Second module implements
core algorithm. IMO is is nice that this code is not mixed
with other parts and also it is potentially reusable in the
future. Third module implements feature that I needed, it
is something that AFAIK is not supported by standard libraries
so I would need it even if I decided to scrap the first two
modules and replace them by FFI calls to some standard library.
The actual syntax of supported patterns is confined to the
fourth module. If I needed different syntax (possibly with
different featurs set) I can provide an alternative parser
module. As you later write those are "friendly" modules
designed to work together. But each of them have reasonably
well specified responsibilities. And since responsiblity
of each module is rather narrow, each of them is simple,
almost trivial. Functionality provided by this collection
of 4 modules is not very impressive, but less trivial than
each of the involved modules.
So let's say I implement this as four modules node.m, match.m,
patterns.m, parser.m.
Since they are really one unit, then anything that needs to be shared between them is marked 'global' to export, but see below.
How they are imported depends on how they are to be used. They could be casually added to the modules of my application. Then I add these lines
to its project info:
module node
module match
module patterns
module parser
I can access its exported names directly without a qualifier as F(), or
I can use mode.F(), parser.F() etc depending on where it lives.
This forms part of my app and will be compiled as part of the
whole-program build.
However this is too casual: there is no real connection between it my
and my own app. I can also see names shared across the four modules
which are meant to be private (and it can access names in /my/ app!).
So probably this would be made into its own subprogram. It will need its
own module info, either added to one designated module, or more usually
in a dedicated lead module, say called rex.m, which contains those same lines:
module node
module match
module patterns
module parser
A further change is that those 'global' attributes need to be changed to 'export' to make them visible outside.
Now, in my app, I add this one line to the project info:
import rex
I can now still call F(), or qualify it as rex.F(); I no longer need to
know where F exists. (However, exported names must be unique; I can't
use both node.F() and match.F().)
'rex' and its modules can no longer see my apps global names. Its source files however will still be compiled into my app.
So that's two approaches to such a library that my scheme allows for.
There is a third one: to put the library into its own DLL.
The start point is the second approach, with rex.m and the four modules.
But now I build it as a separate binary like this:
mm -dll rex # creates rex.dll
In my app, it now needs separate declarations which look like this:
importdll rex =
... FFI declarations for rex's exports
end
This is not project info and can located anywhere. The declarations can
be created in several ways:
* Manually, but then they must keep track of any changes in the library
* If rex was a C library, I can use a tool to do most of the work of creating this import block from a C header.
* If written in my language, then 'mm -dll rex' will also write a
suitable import module containing that 'importdll' block, either called rex_lib.m or rex.q depending on which of my two languages was
configured. Then in my app's project info I can write one of:
module rex_lib # (using rex.m would overwrite the rex.m original)
module rex
That exported function can still called as F(), or as rex_lib.F() or rex.F().
I still build my app as 'mm app'; it will automatically pull in rex.dll.
What it doesn't do at the minute is write docs: collate doc-info from
the exported module and write into a file to act as documentation.
I used to have support for such doc-strings but dropped it due to lack
of use.
To summarise using this example 4-module library:
(1) Add 4 'module' directives to my own app
(2) Put them into rex.m then add 'module rex' to my app
(3) Put them into rex.m, build as DLL, then add 'module rex/rex_lib'
to my app
This last will probably most appeal to you and corresponds most closely
to your discrete interfaces. However it is more chaotic since it needs a separate set of declarations from from the definitions in the 4 modules.
bart <bc@freeuk.com> wrote:[...]
I have a lot of experience of dynamic languages that ran at customer
sites. Such language errors were extremely rare.
It's not that I did extensive testing, but with normal development over
a longish time-frame (eg. 1-2 years), you will uncover a lot of bugs!
I would say that normally it is rare to discover such bugs. Simply
your program happily runs for 20 years and then you suddenly discover
that some strange but valid input causes a crash.
[...]
IIUC in commercial settings in the past there were tendency to
disregard such problem ("if customer can not see a problem, then
software is good enough").
[...]
At some stages I used multiple machines, when one machine was
doing build I was doing something else on other machine.
[...]
[...] But AFAICS in
commercial setting I could not justify time spend on speeding
up build: "present value" of differce between effort and
gain is negative.
On 2026-09-14 22:54, David Brown wrote:
On 14/09/2026 20:21, tTh wrote:
On 9/14/26 18:11, David Brown wrote:
I simply always use braces, regardless of whether or not
the clause contains a single statement or a compound statement.
That's always a safe choice, but some C programmers prefer to use
fewer braces.˙ A compromise is to insist on always using braces if
there is an "else" clause (in both the "if" and "else" parts), or at
the very least, to do so if there are nested "if" statements.
˙˙˙ About braces, I always use them except in one case :
˙˙˙ when the code fragment is on the same line as the if.
˙˙˙ if (retval) fprintf(stderr, "retval is %d\n", retval);
I have the habit to regularly use a line-break and indentation here.
˙˙˙ if (retval)
˙˙˙˙˙˙˙ fprintf(stderr, "retval is %d\n", retval);
˙˙˙ I think it's dangerous, but for some little things
˙˙˙ like my sample, it make things clearer for me.
I wouldn't exactly call it "dangerous". But I think one should apply
any means and habits that avoid the errors that one personally knows
to make.
For collaborative work we therefore had a rule to always use braces.
I do the same, but restrict it to simpler statements.
"Simpler" is a matter of taste and subjective judgement here -
"return;", "break;", "continue;" are all "simple".˙ A short assignment
is "simple".˙ For a longer printf, I'd usually use braces.˙ If the
statement is too long to be comfortable on one line, or may reasonably
become so in future modifications, then I'd have braces.
For specific "simple statements" like early exits I usually even add
an empty line after it;
˙˙˙ if (!precond)
˙˙˙˙˙˙˙ return special;
˙˙˙ regular_process;
For 'if'-cascades with "simple statements" I also omit the line-break, though. As you say it's also about any specific code being comfortably represented.
Being a personal preference one should use a style to minimize problems
in one's own style, or follow the company standards where collaborative
work is expected.
On 14/09/2026 23:56, Janis Papanagnou wrote:
[...]
I have the habit to regularly use a line-break and indentation here.
˙˙˙˙ if (retval)
˙˙˙˙˙˙˙˙ fprintf(stderr, "retval is %d\n", retval);
To my eyes (and I fully appreciate that this kind of thing is highly subjective), that is the worst you can do.
˙That's how you end up with
mistakes like this, after lines are added, removed or changed during
code maintenance :
˙˙˙˙if (...)
˙˙˙˙˙˙˙ goto fail;
˙˙˙˙˙˙˙ goto fail;
[...]
For specific "simple statements" like early exits I usually even add
an empty line after it;
˙˙˙˙ if (!precond)
˙˙˙˙˙˙˙˙ return special;
˙˙˙˙ regular_process;
The empty line here helps, I think, and reduces some risk of error.
On 2026-09-15 09:07, David Brown wrote:
On 14/09/2026 23:56, Janis Papanagnou wrote:
[...]
I have the habit to regularly use a line-break and indentation here.
˙˙˙˙ if (retval)
˙˙˙˙˙˙˙˙ fprintf(stderr, "retval is %d\n", retval);
To my eyes (and I fully appreciate that this kind of thing is highly
subjective), that is the worst you can do.
Yes, you said that before. (But your example below doesn't quite fit.)
˙That's how you end up with mistakes like this, after lines are added,
removed or changed during code maintenance :
Erm, no. - First, I never need to use 'goto' with my programming style.
And second, a 'goto' I'd handle like a 'return' (as seen in my example below); any "severe disruption" of the linear processing I'd indicate
by an empty line.
˙˙˙˙˙if (...)
˙˙˙˙˙˙˙˙ goto fail;
˙˙˙˙˙˙˙˙ goto fail;
[...]
For specific "simple statements" like early exits I usually even add
an empty line after it;
˙˙˙˙ if (!precond)
˙˙˙˙˙˙˙˙ return special;
˙˙˙˙ regular_process;
The empty line here helps, I think, and reduces some risk of error.
It indeed does. (And certainly works for me.)
Janis
On 15/09/2026 09:41, Janis Papanagnou wrote:
On 2026-09-15 09:07, David Brown wrote:
On 14/09/2026 23:56, Janis Papanagnou wrote:
[...]
I have the habit to regularly use a line-break and indentation here.
˙˙˙˙ if (retval)
˙˙˙˙˙˙˙˙ fprintf(stderr, "retval is %d\n", retval);
To my eyes (and I fully appreciate that this kind of thing is highly
subjective), that is the worst you can do.
Yes, you said that before. (But your example below doesn't quite fit.)
˙That's how you end up with mistakes like this, after lines are
added, removed or changed during code maintenance :
Erm, no. - First, I never need to use 'goto' with my programming style.
And second, a 'goto' I'd handle like a 'return' (as seen in my example
below); any "severe disruption" of the linear processing I'd indicate
by an empty line.
The example was not about "goto" itself.
[...] This resulted in one of the biggest security failures seen.
[...]
Now, the mistake also required other failures - failure in code review, failure to test properly, failure to use static error checking (gcc's "- Wmisleading-indent" would have spotted it), and general failure of the
IT world to put enough effort and resources into supporting such a
critical piece of software.
It is always thus when something like this
happens - multiple safeguards must fail.˙ A safe coding style - which
this is not - would have been an additional safeguard.˙ You can, of
course, put different emphasis on different aspects of these safeguards
- maybe you don't need any static error checking if you have good enough testing, and you don't need a good coding style if code reviews are
careful enough.˙ But I believe it always makes sense to make good use of
the easy and cheap guards - basic static error checking and good coding style.
Safe coding styles do not in any sense eliminate bugs or guarantee
correct code, but they reduce the risk of certain classes of code bugs
and code misunderstandings.
Having a style where indentation sometimes
means blocks, and sometimes does not, is a /bad/ idea for code safety because it increases the cognitive load to interpret the code.
bart <bc@freeuk.com> wrote:
I have a lot of experience of dynamic languages that ran at customer
sites. Such language errors were extremely rare.
It's not that I did extensive testing, but with normal development over
a longish time-frame (eg. 1-2 years), you will uncover a lot of bugs!
I would say that normally it is rare to discover such bugs. Simply
your program happily runs for 20 years and then you suddenly discover
that some strange but valid input causes a crash.
Let me mention that one of speed improvements is quite recent.
I spent semething like 2-3 days to shorten real time of parallel
build from about 60s to 45s (that involves more than compilation,
so is longer than just compile time). Comparing the two things
it seems that I will need about 5000 builds to recover time
that I spent on speeding up the build. Given that I am doing
some hundreds of builds per year,
On 2026-09-15 10:22, David Brown wrote:
On 15/09/2026 09:41, Janis Papanagnou wrote:
On 2026-09-15 09:07, David Brown wrote:
On 14/09/2026 23:56, Janis Papanagnou wrote:
[...]
I have the habit to regularly use a line-break and indentation here. >>>>>
˙˙˙˙ if (retval)
˙˙˙˙˙˙˙˙ fprintf(stderr, "retval is %d\n", retval);
To my eyes (and I fully appreciate that this kind of thing is highly
subjective), that is the worst you can do.
Yes, you said that before. (But your example below doesn't quite fit.)
˙That's how you end up with mistakes like this, after lines are
added, removed or changed during code maintenance :
Erm, no. - First, I never need to use 'goto' with my programming style.
And second, a 'goto' I'd handle like a 'return' (as seen in my example
below); any "severe disruption" of the linear processing I'd indicate
by an empty line.
The example was not about "goto" itself.
I'm well aware that your 'goto' example was badly chosen, and that
there are other examples that illustrate your point more accurately.
(But I was also aware what "problems" you actually have in mind; I
know the mindset, there was actually no need to be that verbose. :-)
[...] This resulted in one of the biggest security failures seen.
Obviously a failure in two ways; having insufficient QA measures,
and programmers that had problems with the necessary attention and experience.
(Adding after I read your text below: Or maybe subjective problems
with the "abstract picture" one has about the syntactic elements.)
[...]
Now, the mistake also required other failures - failure in code
review, failure to test properly, failure to use static error checking
(gcc's "- Wmisleading-indent" would have spotted it), and general
failure of the IT world to put enough effort and resources into
supporting such a critical piece of software.
Yes.
It is always thus when something like this happens - multiple
safeguards must fail.˙ A safe coding style - which this is not - would
have been an additional safeguard.˙ You can, of course, put different
emphasis on different aspects of these safeguards - maybe you don't
need any static error checking if you have good enough testing, and
you don't need a good coding style if code reviews are careful
enough.˙ But I believe it always makes sense to make good use of the
easy and cheap guards - basic static error checking and good coding
style.
Right. - But don't forget that "spurious means" to tackle a topic is
as well a source of obfuscating information; I certainly won't judge
whether one or the other is in any (absolute or relative) way "better",
but it certainly reminds me the recurring "if(a=5) vs. if(5=a)" debate
to "ensure" "programming safety".
Safe coding styles do not in any sense eliminate bugs or guarantee
correct code, but they reduce the risk of certain classes of code bugs
and code misunderstandings.
Sure. - The point is; is there an objectively safe style here?
I think there's subjective styles that helps some and annoys others.
I don't think it makes sense to argue about that. (Especially given
that we both have many decades of experience in the area.)
Having a style where indentation sometimes means blocks, and sometimes
does not, is a /bad/ idea for code safety because it increases the
cognitive load to interpret the code.
I disagree. - Your statement makes assumptions about a subjective idea
of two different things. I can agree only insofar as accepting that you
have that picture in mind, and with that picture it seems inconsistent
(or something like that) to you. So I accept it's "cognitive load" for
you. (While spurious syntax elements is "cognitive load" for me.)
On 15/09/2026 02:48, Waldek Hebisch wrote:
bart <bc@freeuk.com> wrote:
I have a lot of experience of dynamic languages that ran at customer
sites. Such language errors were extremely rare.
It's not that I did extensive testing, but with normal development over
a longish time-frame (eg. 1-2 years), you will uncover a lot of bugs!
I would say that normally it is rare to discover such bugs. Simply
your program happily runs for 20 years and then you suddenly discover
that some strange but valid input causes a crash.
Errors in a dynamic program would be trapped and reported, rather than
cause a crash (unless it was a deeper within the implementation).
Then that dynamic module would terminate, but the app was still running
and the user could do something else.
More common were bugs in the main native code app, and with that in
mind, we had an auto-save feature to recover the user's data if those
caused a crash, but they may have lost some minutes' work.
(Funnily enough, one of my scripting language apps, which was a custom
POS system, ran daily for at least 23 years, in an environment with
frequent power cuts).)
Let me mention that one of speed improvements is quite recent.
I spent semething like 2-3 days to shorten real time of parallel
build from about 60s to 45s (that involves more than compilation,
so is longer than just compile time). Comparing the two things
it seems that I will need about 5000 builds to recover time
that I spent on speeding up the build. Given that I am doing
some hundreds of builds per year,
Per year? I could easily do hundreds of builds per day!
Essentially my builds are instant, certainly for my projects of up to
50Kloc where they finish within 0.1s. This is important for
whole-program compilation where you can't choose to compile just one modified module.
I think for me the costs of those language features - overloading
functions and type inference, and what sounds like some kind of
inheritance - would be just too high. I wouldn't have them, or would
make compromises, or see if I could devise my own solutions.
It sounds like you inherited your language.
bart <bc@freeuk.com> wrote:
Technically, with 45s per build I could do few hundreds build a
day.
In the past I was teaching programming in Turbo Pascal. I remember
student pressing "compile" key after typing a few characters.
This made some sense, compilation was essentially immediate and
gave feedback, that is presence or absence of syntax errors. But
I can enter somewhat bigger piece of code without making syntax
error (I make a lot of silly errors, but not so much as to compile
every few characters). And incremental compilation is reasonably
fast. Also syntax error are much faster than succesful compilation.
I think for me the costs of those language features - overloading
functions and type inference, and what sounds like some kind of
inheritance - would be just too high. I wouldn't have them, or would
make compromises, or see if I could devise my own solutions.
Faster compiler probably would speed up my work by few percent. Main
gain probably would be that I could use slower computer. OTOH
I would guesstimate that language features increase productivity
by 50% or more.
On 15/09/2026 15:54, Waldek Hebisch wrote:
bart <bc@freeuk.com> wrote:
But suppose, somehow, a full build of your whole application could be
done in zero time or near enough.
bart <bc@freeuk.com> writes:
On 15/09/2026 15:54, Waldek Hebisch wrote:
bart <bc@freeuk.com> wrote:
But suppose, somehow, a full build of your whole application could be
done in zero time or near enough.
Figure out how to build linux (a C application) in zero time and get back to us.
On 15/09/2026 15:54, Waldek Hebisch wrote:
bart <bc@freeuk.com> wrote:
Technically, with 45s per build I could do few hundreds build a
day.
It would take up half your day!
I think for me the costs of those language features - overloading
functions and type inference, and what sounds like some kind of
inheritance - would be just too high. I wouldn't have them, or would
make compromises, or see if I could devise my own solutions.
Faster compiler probably would speed up my work by few percent. Main
gain probably would be that I could use slower computer. OTOH
I would guesstimate that language features increase productivity
by 50% or more.
So you've adapted to what you have and learned how to work effectively
with it.
But suppose, somehow, a full build of your whole application could be
done in zero time or near enough.
You wouldn't need parallel processing. You wouldn't have to bother with incremental compilation. You wouldn't have to set up isolated tests in
order to have smaller, faster-to-build programs.
Your way of working would change.
This is pretty much how it works with dynamic languages that are run
from source. And some are using JIT methods on static languages
(although tricky language features could still affect the front-end compiler).
I think that is generally considered to be a productive approach.
So you've adapted to what you have and learned how to work effectively
with it.
On 15/09/2026 22:56, bart wrote:
So you've adapted to what you have and learned how to work effectively
with it.
You are forever trying to claim that this is somehow a bad thing.
Most of us regulars here in comp.lang.c are not omnipotent, nor do we
have unlimited time.˙ We prefer to spend our time and effort on
particular focused tasks - usually the tasks we get paid to do, or alternatively the tasks we enjoy doing.
We cannot do /everything/ - there is not the time.˙ I'm sure most of us, deep down, know that we could write a better C compiler than gcc or
clang, and design a better language than C.
But we don't have the time or inclination.˙ We don't have the need.˙ The tools that exist already do the job we need.˙ We find convenient ways to make the whole process more efficient, and get on with the programming
we actually want to do.˙ (And we don't have to look far to find these methods - millions of developers use build systems and decent editors.
We are not teenagers with a ZX Spectrum in our bedrooms, we are professionals who use professional tools.)
What do you really want people here to do?˙ Should we intentionally make
our lives difficult by doing serial clean rebuilds all the time, and use
MS Notepad as an editor, just so that we too can feel the pain and
suffering you feel?˙ Should we stop all our work, give up our jobs, and write our own C compilers?˙ Should we spend have our life whining and moaning in Usenet groups and other online forums about how terrible C is
and how bad compilers are, complaining to people who have no influence
over any of it and can work fine with the language and tools?
Or do you want us to bow down to you and exclaim our undying admiration
for your language and compilers?
I presume you are not interested in hearing that we too would be happyWhat I would like is for somebody to actually admit that there might be
if compilers were faster, or that we too think that C has quirks,
oddities, and aspects that we would prefer were different - if so, you'd have switched the broken record a couple of decades ago.
So what would actually make you /happy/ here, and would let you change
the subject?
On 16/09/2026 08:08, David Brown wrote:
On 15/09/2026 22:56, bart wrote:
So you've adapted to what you have and learned how to work
effectively with it.
You are forever trying to claim that this is somehow a bad thing.
Most of us regulars here in comp.lang.c are not omnipotent, nor do we
have unlimited time.˙ We prefer to spend our time and effort on
particular focused tasks - usually the tasks we get paid to do, or
alternatively the tasks we enjoy doing.
We cannot do /everything/ - there is not the time.˙ I'm sure most of
us, deep down, know that we could write a better C compiler than gcc
or clang, and design a better language than C.
But we don't have the time or inclination.˙ We don't have the need.
The tools that exist already do the job we need.˙ We find convenient
ways to make the whole process more efficient, and get on with the
programming we actually want to do.˙ (And we don't have to look far to
find these methods - millions of developers use build systems and
decent editors. We are not teenagers with a ZX Spectrum in our
bedrooms, we are professionals who use professional tools.)
What do you really want people here to do?˙ Should we intentionally
make our lives difficult by doing serial clean rebuilds all the time,
and use MS Notepad as an editor, just so that we too can feel the pain
and suffering you feel?˙ Should we stop all our work, give up our
jobs, and write our own C compilers?˙ Should we spend have our life
whining and moaning in Usenet groups and other online forums about how
terrible C is and how bad compilers are, complaining to people who
have no influence over any of it and can work fine with the language
and tools?
Or do you want us to bow down to you and exclaim our undying
admiration for your language and compilers?
No. But you don't need actively dislike them either or be so patronising about them.
My language is probably the nearest to C in this class and level of language, while also being very different in look and feel. It would be foolish to just dismiss it.
What I would like is for somebody to actually admit that there might be
I presume you are not interested in hearing that we too would be happy
if compilers were faster, or that we too think that C has quirks,
oddities, and aspects that we would prefer were different - if so,
you'd have switched the broken record a couple of decades ago.
So what would actually make you /happy/ here, and would let you change
the subject?
a problem instead of just brushing it under the carpet.
What I would like is to know that there is somebody out there who is
keeping on top of inefficiencies and checking that a simple task doesn't take an inordinate and disproportionate amount of resources to do.
I'm not saying that /you/ should do it or most who post here. You are
just the users who have to work with what's available, eg. by applying
more hardware resources and more ingenuity.
Even WH has said they have worked at improving the throughput of their
tools (although that was not for C).
The recent example of those SDL3 headers is a good one. Even without
needing to change the C language, or have super-fast compilers for it,
those headers are grossly inefficient.
Maybe you don't think this is interesting or relevant or you think it is
a waste of time. But if someone decided to add this to your favourite compiler I bet you would use it!
In this case, it would reduce header code that needs to be processed /
per module/, by some 99%, not 95%.
Note that this is the same sort of principle as gcc's precompiled
headers. But that doesn't simplify the headers at all; just pre-
tokenises or something. The 3.6MB of SDL3 headers turn into one giant
30MB file. My approach would reduce them to one file of perhaps 0.2MB.
On 16/09/2026 08:08, David Brown wrote:
On 15/09/2026 22:56, bart wrote:
The recent example of those SDL3 headers is a good one. Even without
needing to change the C language, or have super-fast compilers for it,
those headers are grossly inefficient.
That is something that could be partly be tackled by the people who distribute the header files, but more could also be done by those who
create the tools.
For example:
* There are 86 files/82K lines of headers, counted statically, but
nearly 500 dynamic #includes are done, scanning or skipping over half a million lines of declarations
* Yet they contain only about 4000 lines of actual information necessary
to compile a program that uses that library. This is 1% of the lines
that are scanned.
* For a start, half the source is comments. Why are comments even needed
for a header meant to be consumed by machine? There are surely separate docs! If they are for the SDL3 developers, then somebody using the
library *is not the developer*!
* There are thousands of /static/ conditional blocks (and a lot more encountered dynamically) all testing the same invariants over and over again.
For example, once it is established that the compiler is not __MSCVER__,
you don't need to test that (and to skip over blocks only relevant to
that platform) 100 more times.
So this could be done by recognising that a compact, streamlined API, dedicated to a particular platform (and maybe compiler) would be far better.
But because that would mean many versions (more than the number of
DLLs/.sos for different targets for example), this sounds like a
compiler task.
Most compilers already have an -E option to generate preprocessed source code. What is needed is say a -H option which does not discard
information that a compiler still needs, if using an AOT-preprocessed header.
Mostly this will be #defines. So it would not be too difficult. (Just
tricky as SDL3 uses lots of #undefines too.)
Maybe you don't think this is interesting or relevant or you think it is
a waste of time. But if someone decided to add this to your favourite compiler I bet you would use it!
In this case, it would reduce header code that needs to be processed
/per module/, by some 99%, not 95%.
Note that this is the same sort of principle as gcc's precompiled
headers. But that doesn't simplify the headers at all; just
pre-tokenises or something. The 3.6MB of SDL3 headers turn into one
giant 30MB file. My approach would reduce them to one file of perhaps 0.2MB.
On 16/09/2026 12:21, bart wrote:
The recent example of those SDL3 headers is a good one. Even without
needing to change the C language, or have super-fast compilers for it,
those headers are grossly inefficient.
So what?
I did the timings there.˙ The savings achievable from "instant" headers would be tiny fractions of a second.
You are utterly obsessed with something that is utterly irrelevant in
most cases (again, we are talking about C).
bart <bc@freeuk.com> wrote:
On 16/09/2026 08:08, David Brown wrote:
On 15/09/2026 22:56, bart wrote:
The recent example of those SDL3 headers is a good one. Even without
needing to change the C language, or have super-fast compilers for it,
those headers are grossly inefficient.
That is something that could be partly be tackled by the people who
distribute the header files, but more could also be done by those who
create the tools.
For example:
* There are 86 files/82K lines of headers, counted statically, but
nearly 500 dynamic #includes are done, scanning or skipping over half a
million lines of declarations
Do SDL3 use include guards? The expected convention is that header
looks like:
#ifndef XXXXXX
#define XXXXXX
...
#endif
with possibly some trivial variation. That first non-comment thing
in a header is a test and the whole body is inside a conditional.
Assuming that SDL3 is doing this (and if not you should complain to
them), then your compiler could recognize this pattern and skip
the header when it is included second time. For this you need to
recognize when two paths lead to the same file, recognize the test
and check that test is indeed false when doing second include.
Some headers may be intentionally included multiple times, but
with include guards you should be able to include most files just
once. IIUC both GCC and TCC handle this.
* Yet they contain only about 4000 lines of actual information necessary
to compile a program that uses that library. This is 1% of the lines
that are scanned.
* For a start, half the source is comments. Why are comments even needed
for a header meant to be consumed by machine? There are surely separate
docs! If they are for the SDL3 developers, then somebody using the
library *is not the developer*!
If you are developing an application you sometimes need to look
at content of the headers. Comments presumably make it easier to
understand the headers. Concerning documentation, this is derived
thing, which hopefully agrees with the sources, but actual source
is the ultimate truth and looking at source is more reliable (even if
harder) than looking at documentation.
* There are thousands of /static/ conditional blocks (and a lot more
encountered dynamically) all testing the same invariants over and over
again.
For example, once it is established that the compiler is not __MSCVER__,
you don't need to test that (and to skip over blocks only relevant to
that platform) 100 more times.
So this could be done by recognising that a compact, streamlined API,
dedicated to a particular platform (and maybe compiler) would be far better. >>
But because that would mean many versions (more than the number of
DLLs/.sos for different targets for example), this sounds like a
compiler task.
I guess that smart compiler could create streamlined version of headers.
That could be done when istalling the library. Or maybe the compiler
could have a cache of streamline versions and use cached result
when it is newer than library headers. As saying goes, this is
small matter of programming. So somebody needs to implement it.
And take into account that this should work without need of cooperation
of all involved parties. Namely, if one compiler implement needed
features, there is no warranty that other will do the same. And
without support in all compilers library authors normally would
write code for the lowest common denominator, that is assume no
special support (and the same for packagers). You can not expect
special action from users, most of them will just do what they
learned as "standard commands" and "let computer do the rest"
regardless how much CPU time it takes.
Most compilers already have an -E option to generate preprocessed source
code. What is needed is say a -H option which does not discard
information that a compiler still needs, if using an AOT-preprocessed
header.
Mostly this will be #defines. So it would not be too difficult. (Just
tricky as SDL3 uses lots of #undefines too.)
Combine '#undefine' with conditionals unknown at preprocessing time
and the problem becomes more interesting. IIUC developers of major
comilers gave up at this point.
Maybe you don't think this is interesting or relevant or you think it is
a waste of time. But if someone decided to add this to your favourite
compiler I bet you would use it!
In this case, it would reduce header code that needs to be processed
/per module/, by some 99%, not 95%.
Note that this is the same sort of principle as gcc's precompiled
headers. But that doesn't simplify the headers at all; just
pre-tokenises or something. The 3.6MB of SDL3 headers turn into one
giant 30MB file. My approach would reduce them to one file of perhaps 0.2MB.
IIUC GCC precompiled header is simplified quite a lot, for example
all preprocessor conditonals are removed and replaced by resulting
expansion. Size may be just consequence of how this works. IIUC
GCC just dump memory containing internal representation of content
if the header. Given that modern machines have high memory bandwidth, loading it is pretty efficient.
You mentioned 4000 nontivial lines, which probably means 4000 declarations. Internally GCC represents this as tree nodes and rather conservative
estimate is that GCC needs 3 nodes per declaration. GCC tree nodes
need probably about 100 bytes each (they contain several pointers),
so that alone would imply about 1MB.
GCC now prints rather detailed information about includes when printing
error messages, so there must be enough additional information
to track back result of expansion to the sources. And given that
GCC uses memory dump, it is likely to contain some unneded garbage.
At first glance 30 MB looks like a lot, but in advanced compiler
you need a lot of information. And there is always a compromise:
storing info means that it is "immediately" available, recomputing
means that you can avoid memory acceses (which are expensive if
you miss the cache). IIUC a lot of effort of GCC developers went
into recomputing what can be cheaply recomputed, using packed
representations and discarding not needed information. But
a lot needs to be stored to avoid making GCC slower than it is.
And the dump approach was chosen as the fastest one.
On 16/09/2026 12:47, David Brown wrote:
On 16/09/2026 12:21, bart wrote:
The recent example of those SDL3 headers is a good one. Even without
needing to change the C language, or have super-fast compilers for
it, those headers are grossly inefficient.
So what?
I did the timings there.˙ The savings achievable from "instant"
headers would be tiny fractions of a second.
I don't really trust your figures. I've today done a mock-up of a streamlined header for SDL3.
In this form it is a file of just over 6K lines (probably there's stuff
that doesn't need to be there, but it will suffice for this test).
So here are my figures for a single 'hello-world' test for SDL3:
˙˙˙˙˙˙˙˙ sdl.h˙˙˙˙˙˙˙˙˙˙˙ newsdl.h˙˙˙˙˙˙ (normal vs compact)
gcc˙˙˙˙˙ 0.88 seconds˙˙˙˙ 0.34 seconds
gcc˙˙˙˙˙ 0.24 seconds˙˙˙˙ 0.22 seconds˙˙ (using precompiled headers)
bcc˙˙˙˙˙ 0.17 seconds˙˙˙˙ 0.04 seconds
gcc˙˙˙˙˙ 0.4˙ seconds˙˙˙˙ 0.08 seconds˙˙ (Linux/real time)
And this is the test for 50 files each including one of those headers:
˙˙˙˙˙˙˙˙ sdl.h˙˙˙˙˙˙˙˙˙˙ newsdl.h˙˙˙˙˙˙˙ (normal vs compact)
gcc˙˙˙˙˙ 38 seconds˙˙˙˙˙ 6˙˙ seconds˙˙˙˙ (gcc *.c)
bcc˙˙˙˙˙˙ 8 seconds˙˙˙˙˙ 1.7 seconds˙˙˙˙ (bcc needs 50 invocations)
That looks quite worthwhile to me.
Another advantage is that the header
is a single file that is easy to use, copy, bundle etc. You don't need -
I options.
You are utterly obsessed with something that is utterly irrelevant in
most cases (again, we are talking about C).
Let me ask you: how big, bloated and inefficient does such a header need
to be for you to think there is a problem? How much does it need to slow down the build process?
Or would you invest in a server farm first before you will admit there
is a problem? Or is that only before you will admit it to me?
On 16/09/2026 14:16, Waldek Hebisch wrote:
bart <bc@freeuk.com> wrote:
On 16/09/2026 08:08, David Brown wrote:
On 15/09/2026 22:56, bart wrote:
The recent example of those SDL3 headers is a good one. Even without
needing to change the C language, or have super-fast compilers for it,
those headers are grossly inefficient.
That is something that could be partly be tackled by the people who
distribute the header files, but more could also be done by those who
create the tools.
For example:
* There are 86 files/82K lines of headers, counted statically, but
nearly 500 dynamic #includes are done, scanning or skipping over half a
million lines of declarations
Do SDL3 use include guards? The expected convention is that header
looks like:
#ifndef XXXXXX
#define XXXXXX
...
#endif
with possibly some trivial variation. That first non-comment thing
in a header is a test and the whole body is inside a conditional.
Guards are used, but conditional must still be skipped, not that simple
as a closing '#endif' for example must match, or some could be inside comments.
Assuming that SDL3 is doing this (and if not you should complain to
them), then your compiler could recognize this pattern and skip
the header when it is included second time. For this you need to
recognize when two paths lead to the same file, recognize the test
and check that test is indeed false when doing second include.
On 16/09/2026 12:47, David Brown wrote:
On 16/09/2026 12:21, bart wrote:
The recent example of those SDL3 headers is a good one. Even without
needing to change the C language, or have super-fast compilers for it,
those headers are grossly inefficient.
So what?
I did the timings there.˙ The savings achievable from "instant" headers
would be tiny fractions of a second.
I don't really trust your figures. I've today done a mock-up of a >streamlined header for SDL3.
In this form it is a file of just over 6K lines (probably there's stuff
that doesn't need to be there, but it will suffice for this test).
So here are my figures for a single 'hello-world' test for SDL3:
sdl.h newsdl.h (normal vs compact)
gcc 0.88 seconds 0.34 seconds
bart <bc@freeuk.com> wrote:
On 16/09/2026 14:16, Waldek Hebisch wrote:
bart <bc@freeuk.com> wrote:
On 16/09/2026 08:08, David Brown wrote:
On 15/09/2026 22:56, bart wrote:
The recent example of those SDL3 headers is a good one. Even without
needing to change the C language, or have super-fast compilers for it, >>>> those headers are grossly inefficient.
That is something that could be partly be tackled by the people who
distribute the header files, but more could also be done by those who
create the tools.
For example:
* There are 86 files/82K lines of headers, counted statically, but
nearly 500 dynamic #includes are done, scanning or skipping over half a >>>> million lines of declarations
Do SDL3 use include guards? The expected convention is that header
looks like:
#ifndef XXXXXX
#define XXXXXX
...
#endif
with possibly some trivial variation. That first non-comment thing
in a header is a test and the whole body is inside a conditional.
Guards are used, but conditional must still be skipped, not that simple
as a closing '#endif' for example must match, or some could be inside
comments.
Of course you need to parse the file at least one time. But once
you parsed file once and checked that it has correct include guard
Assuming that SDL3 is doing this (and if not you should complain to
them), then your compiler could recognize this pattern and skip
the header when it is included second time. For this you need to
recognize when two paths lead to the same file, recognize the test
and check that test is indeed false when doing second include.
bart <bc@freeuk.com> writes:
On 16/09/2026 12:47, David Brown wrote:
On 16/09/2026 12:21, bart wrote:
The recent example of those SDL3 headers is a good one. Even without
needing to change the C language, or have super-fast compilers for it, >>>> those headers are grossly inefficient.
So what?
I did the timings there.˙ The savings achievable from "instant" headers
would be tiny fractions of a second.
I don't really trust your figures. I've today done a mock-up of a
streamlined header for SDL3.
In this form it is a file of just over 6K lines (probably there's stuff
that doesn't need to be there, but it will suffice for this test).
So here are my figures for a single 'hello-world' test for SDL3:
sdl.h newsdl.h (normal vs compact)
gcc 0.88 seconds 0.34 seconds
That seems to be "tiny fractions of a second" to me. Pointless
optimization for no appreciable return, almost in the noise.
On 16/09/2026 16:58, Waldek Hebisch wrote:<snip>
bart <bc@freeuk.com> wrote:
Every one of those has a guard. So, does that mean that the body of >'SDL_stdinc.h' for example should only ever be encountered once?
On 16/09/2026 18:33, Scott Lurndal wrote:
bart <bc@freeuk.com> writes:
On 16/09/2026 12:47, David Brown wrote:
On 16/09/2026 12:21, bart wrote:
The recent example of those SDL3 headers is a good one. Even without >>>>> needing to change the C language, or have super-fast compilers for it, >>>>> those headers are grossly inefficient.
So what?
I did the timings there.˙ The savings achievable from "instant" headers >>>> would be tiny fractions of a second.
I don't really trust your figures. I've today done a mock-up of a
streamlined header for SDL3.
In this form it is a file of just over 6K lines (probably there's stuff
that doesn't need to be there, but it will suffice for this test).
So here are my figures for a single 'hello-world' test for SDL3:
sdl.h newsdl.h (normal vs compact)
gcc 0.88 seconds 0.34 seconds
That seems to be "tiny fractions of a second" to me. Pointless
optimization for no appreciable return, almost in the noise.
This is for *one* C source file that contains little more than that
header. Typically there are multiple source files containing code of
their own that need compiling, and which might need there own header.
This is spending the best part of a second compiling 1300 function >signatures; this is 1980s machine speed.
You seem to be involved in developing new, higher performance
processors, and yet you're happy to all see all that power wasted
because people who write these bloated messes of code are so fucking lazy.
bart <bc@freeuk.com> writes:
On 16/09/2026 18:33, Scott Lurndal wrote:
bart <bc@freeuk.com> writes:
On 16/09/2026 12:47, David Brown wrote:
On 16/09/2026 12:21, bart wrote:
The recent example of those SDL3 headers is a good one. Even without >>>>>> needing to change the C language, or have super-fast compilers for it, >>>>>> those headers are grossly inefficient.
So what?
I did the timings there.˙ The savings achievable from "instant" headers >>>>> would be tiny fractions of a second.
I don't really trust your figures. I've today done a mock-up of a
streamlined header for SDL3.
In this form it is a file of just over 6K lines (probably there's stuff >>>> that doesn't need to be there, but it will suffice for this test).
So here are my figures for a single 'hello-world' test for SDL3:
sdl.h newsdl.h (normal vs compact)
gcc 0.88 seconds 0.34 seconds
That seems to be "tiny fractions of a second" to me. Pointless
optimization for no appreciable return, almost in the noise.
This is for *one* C source file that contains little more than that
header. Typically there are multiple source files containing code of
their own that need compiling, and which might need there own header.
This is spending the best part of a second compiling 1300 function
signatures; this is 1980s machine speed.
Sure. Pull the other one. Early 80's compilers were often
limited by the speed of the input file (e.g. 300 lines-per-minute
compile speeds with a 300CPM card reader).
You seem to be involved in developing new, higher performance
processors, and yet you're happy to all see all that power wasted
because people who write these bloated messes of code are so fucking lazy.
Actually none of that power is wasted, because 99.999% of the available processor cycles are running compiled application code, not compiling code.
Compiling code is in the noise when considering modern workloads
on PCs or servers.
On 16/09/2026 16:58, Waldek Hebisch wrote:
In any case, my stats show that 400K lines are still part of normal processing, while 150K lines are skipped due to false conditional blocks.
Then I went back to one definition. This was fine, so the guards work.
In that case, what the hell is it spending 400000 lines processing?!
Some more investigation is needed via special tracking info added to my compiler. I will update this later.
On 16/09/2026 19:13, bart wrote:
On 16/09/2026 16:58, Waldek Hebisch wrote:
In any case, my stats show that 400K lines are still part of normal
processing, while 150K lines are skipped due to false conditional blocks.
Then I went back to one definition. This was fine, so the guards work.
In that case, what the hell is it spending 400000 lines processing?!
Some more investigation is needed via special tracking info added to
my compiler. I will update this later.
The problem was block- and line-comments. Their line-count was added to
the total for normal tokenising and not that for skipping over false
blocks, since both share the same comment routines.
And there are a lot of comments, including quite a few outside the
guards. I think 380K lines of comments are processed in all, including repeated passes through skipped blocks.
Anyway the guards work, although it may still be interesting to try your (WH's) suggestion to recognise a primary header guard and abort the file immediately.
On 16/09/2026 16:20, bart wrote:
Another advantage is that the header is a single file that is easy to
use, copy, bundle etc. You don't need - I options.
My test file contained a single line :
˙˙˙˙#include <SDL2/SDL.h>
and compiled with
˙˙˙˙gcc -c test.c
There are no -I options.
Single header files are not particularly exciting for a library like
this.
On 16/09/2026 16:53, David Brown wrote:
On 16/09/2026 16:20, bart wrote:
Another advantage is that the header is a single file that is easyMy test file contained a single line :
to use, copy, bundle etc. You don't need - I options.
˙˙˙˙#include <SDL2/SDL.h>
and compiled with
˙˙˙˙gcc -c test.c
There are no -I options.
Where is your SDL2 folder located relative to the current directory?
Was there some installation process that put the headers in a place
where gcc will look for it without being told? Does it involve using 'pkg-config'?
Mine is in the current directory (that is, ./SDL3 is a folder that
contains the headers). gcc doesn't work without '-I.' on either OS:
bart <bc@freeuk.com> writes:
On 16/09/2026 16:53, David Brown wrote:
On 16/09/2026 16:20, bart wrote:
Another advantage is that the header is a single file that is easyMy test file contained a single line :
to use, copy, bundle etc. You don't need - I options.
˙˙˙˙#include <SDL2/SDL.h>
and compiled with
˙˙˙˙gcc -c test.c
There are no -I options.
Where is your SDL2 folder located relative to the current directory?
On my system (Ubuntu 24.04), it's "/usr/include/SDL2". David's
system is probably similar.
Was there some installation process that put the headers in a place
where gcc will look for it without being told? Does it involve using
'pkg-config'?
Yes, installing the Ubuntu package "libsdl2-dev" created and
populated the /usr/include/SDL2 directory, among other things.
That's a typical approach for Unix-like systems.
pkg-config does know about sdl2, but "#include <SDL2/SDL.h>" appears
to work without invoking pkg-config. There may be more to it than
that, but I don't use SDL so I haven't looked into it.
I have no idea how you'd set it up on Windows, but ...
For this test I wanted the simplest possible set up. If using it forMine is in the current directory (that is, ./SDL3 is a folder that
contains the headers). gcc doesn't work without '-I.' on either OS:
Did you set that up manually? If you had two projects that use SDL,
would you have to create "./SDL3" folders in both of them?
On 17/09/2026 00:59, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
On 16/09/2026 16:53, David Brown wrote:On my system (Ubuntu 24.04), it's "/usr/include/SDL2". David's
On 16/09/2026 16:20, bart wrote:
Another advantage is that the header is a single file that is easyMy test file contained a single line :
to use, copy, bundle etc. You don't need - I options.
˙˙˙˙#include <SDL2/SDL.h>
and compiled with
˙˙˙˙gcc -c test.c
There are no -I options.
Where is your SDL2 folder located relative to the current directory?
system is probably similar.
Was there some installation process that put the headers in a place
where gcc will look for it without being told? Does it involve using
'pkg-config'?
Yes, installing the Ubuntu package "libsdl2-dev" created and
populated the /usr/include/SDL2 directory, among other things.
That's a typical approach for Unix-like systems.
pkg-config does know about sdl2, but "#include <SDL2/SDL.h>" appears
to work without invoking pkg-config. There may be more to it than
that, but I don't use SDL so I haven't looked into it.
I have no idea how you'd set it up on Windows, but ...
And I've no idea where gcc would look for its headers, other than
where it keeps its system headers, or how to set it up to look
permanently in certain places.
Mine is in the current directory (that is, ./SDL3 is a folder that
contains the headers). gcc doesn't work without '-I.' on either OS:
Did you set that up manually? If you had two projects that use SDL,
would you have to create "./SDL3" folders in both of them?
For this test I wanted the simplest possible set up. If using it for
real then I'd have to choose a centralised place to them, and impart
that info to the compiler.
This is where a single compact header can make things very easy:[snip]
On 16/09/2026 20:30, bart wrote:
On 16/09/2026 19:13, bart wrote:
On 16/09/2026 16:58, Waldek Hebisch wrote:
In any case, my stats show that 400K lines are still part of normal
processing, while 150K lines are skipped due to false conditional blocks. >>>
Then I went back to one definition. This was fine, so the guards work.
In that case, what the hell is it spending 400000 lines processing?!
Some more investigation is needed via special tracking info added to
my compiler. I will update this later.
The problem was block- and line-comments. Their line-count was added to
the total for normal tokenising and not that for skipping over false
blocks, since both share the same comment routines.
And there are a lot of comments, including quite a few outside the
guards. I think 380K lines of comments are processed in all, including
repeated passes through skipped blocks.
Anyway the guards work, although it may still be interesting to try your
(WH's) suggestion to recognise a primary header guard and abort the file
immediately.
I did try this via a bodge. It worked enough to eliminate most of the skipped comments. But it only made it (my C compiler) perhaps 20% faster
at processing the full SDL3 headers.
But skipping had already been tested to be not far off TCC, and so was comment scanning after some tweaks.
Using the compact header, made it 4 times as fast.
Conclusion: nothing really. C builds /could/ be made significantly
faster when using large libraries across lots of modules, without
needing to use workarounds, makefiles etc.
But not one person had anything positive to say about it, and two have
been hostile. A nice attitude.
And I've no idea where gcc would look for its headers, other than where
it keeps its system headers, or how to set it up to look permanently in certain places.
On 9/17/26 02:49, bart wrote:
And I've no idea where gcc would look for its headers, other than
where it keeps its system headers, or how to set it up to look
permanently in certain places.
˙˙ You just have to read the fscking manual.
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
˙˙ But as everyone knows, learning new things isn't
˙˙ part of your philosophy...
On 16/09/2026 16:53, David Brown wrote:
On 16/09/2026 16:20, bart wrote:
Another advantage is that the header is a single file that is easy to
use, copy, bundle etc. You don't need - I options.
My test file contained a single line :
˙˙˙˙˙#include <SDL2/SDL.h>
and compiled with
˙˙˙˙˙gcc -c test.c
There are no -I options.
Where is your SDL2 folder located relative to the current directory?
Was there some installation process that put the headers in a place
where gcc will look for it without being told? Does it involve using 'pkg-config'?
Mine is in the current directory (that is, ./SDL3 is a folder that
contains the headers). gcc doesn't work without '-I.' on either OS:
˙ c:\sdl>wsl
˙ root@DESKTOP-11:/mnt/c/sdl# cat s.c
˙ #include <SDL3/SDL.h>
˙ root@DESKTOP-11:/mnt/c/sdl# gcc -c s.c
˙ s.c:1:10: fatal error: SDL3/SDL.h: No such file or directory
˙˙˙˙˙ 1 | #include <SDL3/SDL.h>
˙˙˙˙˙˙˙ |˙˙˙˙˙˙˙˙˙ ^~~~~~~~~~~~
˙ compilation terminated.
˙ c:\sdl>gcc -c s.c
˙ s.c:1:10: fatal error: SDL3/SDL.h: No such file or directory
˙˙˙˙˙ 1 | #include <SDL3/SDL.h>
˙˙˙˙˙˙˙ |˙˙˙˙˙˙˙˙˙ ^~~~~~~~~~~~
˙ compilation terminated.
Single header files are not particularly exciting for a library like
this.
Why not? stb_image works fine as a single header for example (which also contains the implementation). There are even sites that list single-
header libraries.
On 17/09/2026 00:59, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
On 16/09/2026 16:53, David Brown wrote:
On 16/09/2026 16:20, bart wrote:
Another advantage is that the header is a single file that is easyMy test file contained a single line :
to use, copy, bundle etc. You don't need - I options.
˙ ˙˙˙˙#include <SDL2/SDL.h>
and compiled with
˙ ˙˙˙˙gcc -c test.c
There are no -I options.
Where is your SDL2 folder located relative to the current directory?
On my system (Ubuntu 24.04), it's "/usr/include/SDL2".˙ David's
system is probably similar.
Was there some installation process that put the headers in a place
where gcc will look for it without being told? Does it involve using
'pkg-config'?
Yes, installing the Ubuntu package "libsdl2-dev" created and
populated the /usr/include/SDL2 directory, among other things.
That's a typical approach for Unix-like systems.
pkg-config does know about sdl2, but "#include <SDL2/SDL.h>" appears
to work without invoking pkg-config.˙ There may be more to it than
that, but I don't use SDL so I haven't looked into it.
I have no idea how you'd set it up on Windows, but ...
And I've no idea where gcc would look for its headers, other than where
it keeps its system headers, or how to set it up to look permanently in certain places.
For this test I wanted the simplest possible set up. If using it for
Mine is in the current directory (that is, ./SDL3 is a folder that
contains the headers). gcc doesn't work without '-I.' on either OS:
Did you set that up manually?˙ If you had two projects that use SDL,
would you have to create "./SDL3" folders in both of them?
real then I'd have to choose a centralised place to them, and impart
that info to the compiler.
This is where a single compact header can make things very easy:
˙ c:\demo>dir
˙ 16/09/2026˙ 13:57˙˙˙˙˙˙˙˙˙˙ 304,760 newsdl.h
˙ 02/09/2026˙ 17:24˙˙˙˙˙˙˙˙ 5,380,925 SDL3.dll
˙ 08/09/2026˙ 19:25˙˙˙˙˙˙˙˙˙˙˙˙ 2,196 test.c
test.c is my app; SDL3.dll is the library; and newsdl.h is the compacted interface. I could add one more file (bcc.exe) and I would have
everything needed to write some SDL programs.
I could copy them to a memory stick for example, whereas a gcc
installation is big and messy.
On 17/09/2026 01:36, bart wrote:
On 16/09/2026 16:53, David Brown wrote:
On 16/09/2026 16:20, bart wrote:
Another advantage is that the header is a single file that is easy
to use, copy, bundle etc. You don't need - I options.
My test file contained a single line :
˙˙˙˙˙#include <SDL2/SDL.h>
and compiled with
˙˙˙˙˙gcc -c test.c
There are no -I options.
Where is your SDL2 folder located relative to the current directory?
/usr/include/SDL2
Was there some installation process that put the headers in a place
where gcc will look for it without being told? Does it involve using
'pkg-config'?
"apt install libsdl2-dev", as I said.˙ Linux distributions with other package managers will have a very similar method.
Mine is in the current directory (that is, ./SDL3 is a folder that
contains the headers). gcc doesn't work without '-I.' on either OS:
˙˙ c:\sdl>wsl
˙˙ root@DESKTOP-11:/mnt/c/sdl# cat s.c
˙˙ #include <SDL3/SDL.h>
Do you not understand the difference between using <> and "" in #include directives?˙ Roughly speaking (details are implementation-specific),
On 17/09/2026 02:49, bart wrote:
Was there some installation process that put the headers in a place
where gcc will look for it without being told? Does it involve using
'pkg-config'?
Yes, installing the Ubuntu package "libsdl2-dev" created and
populated the /usr/include/SDL2 directory, among other things.
That's a typical approach for Unix-like systems.
pkg-config does know about sdl2, but "#include <SDL2/SDL.h>" appears
to work without invoking pkg-config.˙ There may be more to it than
that, but I don't use SDL so I haven't looked into it.
I have no idea how you'd set it up on Windows, but ...
And I've no idea where gcc would look for its headers, other than
where it keeps its system headers, or how to set it up to look
permanently in certain places.
touch empty.c
gcc -E -v empty.c
That will show you, amongst other things, the default include paths.˙ On
my system, it shows :
#include "..." search starts here:
#include <...> search starts here:
˙/usr/lib/gcc/x86_64-linux-gnu/13/include
˙/usr/local/include
˙/usr/include/x86_64-linux-gnu
˙/usr/include
End of search list.
For this test I wanted the simplest possible set up. If using it for
Mine is in the current directory (that is, ./SDL3 is a folder that
contains the headers). gcc doesn't work without '-I.' on either OS:
Did you set that up manually?˙ If you had two projects that use SDL,
would you have to create "./SDL3" folders in both of them?
real then I'd have to choose a centralised place to them, and impart
that info to the compiler.
This is where a single compact header can make things very easy:
˙˙ c:\demo>dir
˙˙ 16/09/2026˙ 13:57˙˙˙˙˙˙˙˙˙˙ 304,760 newsdl.h
˙˙ 02/09/2026˙ 17:24˙˙˙˙˙˙˙˙ 5,380,925 SDL3.dll
˙˙ 08/09/2026˙ 19:25˙˙˙˙˙˙˙˙˙˙˙˙ 2,196 test.c
It is also where using a decent OS appropriate for the task is even easier.
test.c is my app; SDL3.dll is the library; and newsdl.h is the
compacted interface. I could add one more file (bcc.exe) and I would
have everything needed to write some SDL programs.
I could copy them to a memory stick for example, whereas a gcc
installation is big and messy.
I copy gcc setups between systems (albeit cross-compilation toolchains).
˙It's easy with scp, sshfs, rsync, network shares, or a USB stick.˙ The cheapest USB drives I can find from my usual IT supplier are 32 GB - the biggest toolchain I have is about 1.2 GB for everything.˙ The same
applies to Linux and Windows.
On 17/09/2026 11:36, David Brown wrote:
On 17/09/2026 01:36, bart wrote:
On 16/09/2026 16:53, David Brown wrote:
On 16/09/2026 16:20, bart wrote:
Another advantage is that the header is a single file that is easy
to use, copy, bundle etc. You don't need - I options.
My test file contained a single line :
˙˙˙˙˙#include <SDL2/SDL.h>
and compiled with
˙˙˙˙˙gcc -c test.c
There are no -I options.
Where is your SDL2 folder located relative to the current directory?
/usr/include/SDL2
Was there some installation process that put the headers in a place
where gcc will look for it without being told? Does it involve using
'pkg-config'?
"apt install libsdl2-dev", as I said.˙ Linux distributions with other
package managers will have a very similar method.
My gcc Windows installation (I went back to 14.2 as it includes clang), includes 3000 .h files. They can't all be for the standard library!
And 1200 .a archive files. So the approach there seems to be bundle
headers and binaries for every possible library. But apparently not big
ones like SDL.
So I guess, if I copied the SDL3 folder to the same location it keeps stdio.h, it would also work without "-I".
But only for this compiler, and not ideal when multiple headers are not tidily contained within their own folder.
Mine is in the current directory (that is, ./SDL3 is a folder that
contains the headers). gcc doesn't work without '-I.' on either OS:
˙˙ c:\sdl>wsl
˙˙ root@DESKTOP-11:/mnt/c/sdl# cat s.c
˙˙ #include <SDL3/SDL.h>
Do you not understand the difference between using <> and "" in
#include directives?˙ Roughly speaking (details are implementation-
specific),
Exactly, they are implementation-specific. Which can mean subtle
differences in locating a file when already deep inside a nested header.
My compiler actually treats <> and "" the same. That would normally be troublesome as a rogue "stdio.h" in the current path would override the system header.
But my compiler's system headers are embedded, and it will look there
first for /any/ input files. So that doesn't come up, unless I override that.
On 17/09/2026 11:52, David Brown wrote:
On 17/09/2026 02:49, bart wrote:
Was there some installation process that put the headers in a place
where gcc will look for it without being told? Does it involve using >>>>> 'pkg-config'?
Yes, installing the Ubuntu package "libsdl2-dev" created and
populated the /usr/include/SDL2 directory, among other things.
That's a typical approach for Unix-like systems.
pkg-config does know about sdl2, but "#include <SDL2/SDL.h>" appears
to work without invoking pkg-config.˙ There may be more to it than
that, but I don't use SDL so I haven't looked into it.
I have no idea how you'd set it up on Windows, but ...
And I've no idea where gcc would look for its headers, other than
where it keeps its system headers, or how to set it up to look
permanently in certain places.
touch empty.c
gcc -E -v empty.c
That will show you, amongst other things, the default include paths.
On my system, it shows :
#include "..." search starts here:
#include <...> search starts here:
˙˙/usr/lib/gcc/x86_64-linux-gnu/13/include
˙˙/usr/local/include
˙˙/usr/include/x86_64-linux-gnu
˙˙/usr/include
End of search list.
I got a lot more output than that. Then I noticed you said 'amongst
other things'. So -v does not produce less output than --verbose!
On my C compiler I used to have an option -paths which listed all the include paths it would use.
I'm surprised that gcc, amongst it 1000s of options, doesn't have a dedicated one for this.
I think the approach you and others use now is to manage bloat and complexity, or somehow hide it away under additional layers, rather than
do anything about it.
On 17/09/2026 14:03, bart wrote:
My gcc Windows installation (I went back to 14.2 as it includes
clang), includes 3000 .h files. They can't all be for the standard
library!
As you well know, there is no such thing as a standard "gcc Windows" installation - there are multiple different packagings of gcc with
different choices of libraries and other tools.˙ I am not sure it is
going to be very helpful if you say exactly which Windows gcc
installation you have, but there can be huge variations between them.
Do you not understand the difference between using <> and "" in
#include directives?˙ Roughly speaking (details are implementation-
specific),
Exactly, they are implementation-specific. Which can mean subtle
differences in locating a file when already deep inside a nested header.
It's not /that/ difficult - I explained it in a single sentence.˙ And
while it's "implementation-specific" according to the C standards, the
same simple, basic system is used by virtually all C compilers, and virtually all C code.˙ Use "" for application-specific headers, and <>
for toolchain and system-installed headers.
On 17/09/2026 14:15, bart wrote:
On 17/09/2026 11:52, David Brown wrote:
On 17/09/2026 02:49, bart wrote:
Was there some installation process that put the headers in a place >>>>>> where gcc will look for it without being told? Does it involve using >>>>>> 'pkg-config'?
Yes, installing the Ubuntu package "libsdl2-dev" created and
populated the /usr/include/SDL2 directory, among other things.
That's a typical approach for Unix-like systems.
pkg-config does know about sdl2, but "#include <SDL2/SDL.h>" appears >>>>> to work without invoking pkg-config.˙ There may be more to it than
that, but I don't use SDL so I haven't looked into it.
I have no idea how you'd set it up on Windows, but ...
And I've no idea where gcc would look for its headers, other than
where it keeps its system headers, or how to set it up to look
permanently in certain places.
touch empty.c
gcc -E -v empty.c
That will show you, amongst other things, the default include paths.
On my system, it shows :
#include "..." search starts here:
#include <...> search starts here:
˙˙/usr/lib/gcc/x86_64-linux-gnu/13/include
˙˙/usr/local/include
˙˙/usr/include/x86_64-linux-gnu
˙˙/usr/include
End of search list.
I got a lot more output than that. Then I noticed you said 'amongst
other things'. So -v does not produce less output than --verbose!
Yes.˙ You might think it strange, but I only posted the relevant lines
here.˙ There were a total of 31 lines from that command - it was not difficult to spot the ones relevant to the include paths.
On my C compiler I used to have an option -paths which listed all the
include paths it would use.
I'm surprised that gcc, amongst it 1000s of options, doesn't have a
dedicated one for this.
I've never needed to see the list of paths before - they are all
entirely obvious and standard, and "just work".
˙ Why would a compiler
need to add a specific option for something that is rarely required and where there is a simple and fairly obvious common option ("-v", or "-- verbose") to get the information?
On the other hand, slightly better code optimisation can mean longer
battery life, smaller and cheaper hardware, or more functionality in my program.
˙ A bit more static error checking can mean bugs caught during
development and building, rather than during testing or after
deployment.
˙ Better standards conformance can mean more portable code
and easier testing, support for newer standards and useful extensions
means more expressive, re-usable or maintainable source code, better optimisation, and more static error checking.
I do software development.
˙ I don't spend my days copying compilers to
floppy disks or trying to run tools on systems from last century.˙ I am
not interested in how quickly a compiler can compile an almost-empty
test file, 50 times sequentially.
˙ I don't care if "bcc test.c" runs
faster than "gcc test.c" when "bcc test.c" is no more use to me than
"cat test.c > /dev/null".
On 17/09/2026 14:15, bart wrote:
I got a lot more output than that. Then I noticed you said 'amongst
other things'. So -v does not produce less output than --verbose!
Yes. You might think it strange, but I only posted the relevant lines
here. There were a total of 31 lines from that command - it was not difficult to spot the ones relevant to the include paths.
On my C compiler I used to have an option -paths which listed all the
include paths it would use.
I'm surprised that gcc, amongst it 1000s of options, doesn't have a
dedicated one for this.
I've never needed to see the list of paths before - they are all
entirely obvious and standard, and "just work". Why would a compiler
need to add a specific option for something that is rarely required and where there is a simple and fairly obvious common option ("-v", or "--verbose") to get the information?
On 17/09/2026 14:16, David Brown wrote:
On 17/09/2026 14:15, bart wrote:
On 17/09/2026 11:52, David Brown wrote:
On 17/09/2026 02:49, bart wrote:
Was there some installation process that put the headers in a place >>>>>>> where gcc will look for it without being told? Does it involve using >>>>>>> 'pkg-config'?
Yes, installing the Ubuntu package "libsdl2-dev" created and
populated the /usr/include/SDL2 directory, among other things.
That's a typical approach for Unix-like systems.
pkg-config does know about sdl2, but "#include <SDL2/SDL.h>" appears >>>>>> to work without invoking pkg-config.˙ There may be more to it than >>>>>> that, but I don't use SDL so I haven't looked into it.
I have no idea how you'd set it up on Windows, but ...
And I've no idea where gcc would look for its headers, other than
where it keeps its system headers, or how to set it up to look
permanently in certain places.
touch empty.c
gcc -E -v empty.c
That will show you, amongst other things, the default include paths.
On my system, it shows :
#include "..." search starts here:
#include <...> search starts here:
˙˙/usr/lib/gcc/x86_64-linux-gnu/13/include
˙˙/usr/local/include
˙˙/usr/include/x86_64-linux-gnu
˙˙/usr/include
End of search list.
I got a lot more output than that. Then I noticed you said 'amongst
other things'. So -v does not produce less output than --verbose!
Yes.˙ You might think it strange, but I only posted the relevant lines
here.˙ There were a total of 31 lines from that command - it was not
difficult to spot the ones relevant to the include paths.
Always making excuses for gcc! I get 37 lines from it, but because many
are long and wrap, my screen shows over 85 lines, with 25 of them
scrolling off the top of the window. It looks a mess.
On my C compiler I used to have an option -paths which listed all the
include paths it would use.
I'm surprised that gcc, amongst it 1000s of options, doesn't have a
dedicated one for this.
I've never needed to see the list of paths before - they are all
entirely obvious and standard, and "just work".
Yeah, everything 'just works' for you. But if ever it reports it can't
find some header, you will want to know:
(1) The list of locations that it will be looking
(2) All the locations it's checked (this is not necessarily the
˙˙˙ same list; see my last post)
˙ Why would a compiler need to add a specific option for something
that is rarely required and where there is a simple and fairly obvious
common option ("-v", or "-- verbose") to get the information?
That option is next to useless because it buries what you need in a
mountain of junk.
On the other hand, slightly better code optimisation can mean longer
battery life, smaller and cheaper hardware, or more functionality in
my program.
Maybe you do get it after all. Using smaller, simpler, faster tools
gives all those advantages too.
It's a shame you don't see language tools in the same light as some of
your applications.
David Brown <david.brown@hesbynett.no> wrote:
On 17/09/2026 14:15, bart wrote:
I got a lot more output than that. Then I noticed you said 'amongst
other things'. So -v does not produce less output than --verbose!
Yes. You might think it strange, but I only posted the relevant lines
here. There were a total of 31 lines from that command - it was not
difficult to spot the ones relevant to the include paths.
On my C compiler I used to have an option -paths which listed all the
include paths it would use.
I'm surprised that gcc, amongst it 1000s of options, doesn't have a
dedicated one for this.
I've never needed to see the list of paths before - they are all
entirely obvious and standard, and "just work". Why would a compiler
need to add a specific option for something that is rarely required and
where there is a simple and fairly obvious common option ("-v", or
"--verbose") to get the information?
For the benefit of configure scripts?
And for symmetry?
I find
options like:
-print-search-dirs
-print-multiarch
...
-print-sysroot-headers-suffix
but the last one apparently does not work in normal install (even
for cross compilers), and the other seem to give no info about headers.
On 17/09/2026 16:25, bart wrote:
On 17/09/2026 14:16, David Brown wrote:
On 17/09/2026 14:15, bart wrote:
On 17/09/2026 11:52, David Brown wrote:
On 17/09/2026 02:49, bart wrote:
Was there some installation process that put the headers in a place >>>>>>>> where gcc will look for it without being told? Does it involve >>>>>>>> using
'pkg-config'?
Yes, installing the Ubuntu package "libsdl2-dev" created and
populated the /usr/include/SDL2 directory, among other things.
That's a typical approach for Unix-like systems.
pkg-config does know about sdl2, but "#include <SDL2/SDL.h>" appears >>>>>>> to work without invoking pkg-config.˙ There may be more to it than >>>>>>> that, but I don't use SDL so I haven't looked into it.
I have no idea how you'd set it up on Windows, but ...
And I've no idea where gcc would look for its headers, other than >>>>>> where it keeps its system headers, or how to set it up to look
permanently in certain places.
touch empty.c
gcc -E -v empty.c
That will show you, amongst other things, the default include
paths. On my system, it shows :
#include "..." search starts here:
#include <...> search starts here:
˙˙/usr/lib/gcc/x86_64-linux-gnu/13/include
˙˙/usr/local/include
˙˙/usr/include/x86_64-linux-gnu
˙˙/usr/include
End of search list.
I got a lot more output than that. Then I noticed you said 'amongst
other things'. So -v does not produce less output than --verbose!
Yes.˙ You might think it strange, but I only posted the relevant
lines here.˙ There were a total of 31 lines from that command - it
was not difficult to spot the ones relevant to the include paths.
Always making excuses for gcc! I get 37 lines from it, but because
many are long and wrap, my screen shows over 85 lines, with 25 of them
scrolling off the top of the window. It looks a mess.
If gcc had a flag to show the include paths, and nothing but the include paths, you'd complain that you had to read through piles of
documentation to find it.˙ It does not seem to matter what inane,
pointless task you and you alone think is vital, your life seems to
revolve around saying that gcc is bad in every way.˙ So what's next? gcc
is a terrible tool because you find it harder to type "gcc" than "bcc" ?
Sometimes you have sane points about weaknesses in C, or things that
could be improved in gcc, clang, and other tools - or at least, they
were sane points the first time you raised them rather than the
hundredth time.
Oh, and does your fantastic OS not have scrollbars to see more lines of output?
˙ Are you stuck with terminal windows limited to 80 characters
wide, just like we all used last century?˙ Do you not know how to use
the "less" command? (Oh, wait, "less" is only 42 years old - we could
not expect Windows to have caught up with such basic tools in that time.
˙But you can use "more".)
(1) The list of locations that it will be looking
(2) All the locations it's checked (this is not necessarily the
˙˙˙˙ same list; see my last post)
Learn to use a computer for software development, and stop bleating when
you actually have to lift a finger!˙ Of course I have occasionally had a compile fail because my code references a missing header.˙ When it
happens I either find the header, or fix the typo in my code.˙ We are
not doing brain surgery here.
If you can't program in C, and can't use normal C compilers, that's /
your/ problem.˙ Millions of others manage to use gcc for C programming.
˙Start facing the reality that it is /you/ who is doing something
wrong, not the rest of the world.
˙ Why would a compiler need to add a specific option for something
that is rarely required and where there is a simple and fairly
obvious common option ("-v", or "-- verbose") to get the information?
That option is next to useless because it buries what you need in a
mountain of junk.
Not that you are exaggerating at all.
On 17/09/2026 16:38, Waldek Hebisch wrote:
David Brown <david.brown@hesbynett.no> wrote:
On 17/09/2026 14:15, bart wrote:
I got a lot more output than that. Then I noticed you said 'amongst
other things'. So -v does not produce less output than --verbose!
Yes. You might think it strange, but I only posted the relevant lines
here. There were a total of 31 lines from that command - it was not
difficult to spot the ones relevant to the include paths.
On my C compiler I used to have an option -paths which listed all the
include paths it would use.
I'm surprised that gcc, amongst it 1000s of options, doesn't have a
dedicated one for this.
I've never needed to see the list of paths before - they are all
entirely obvious and standard, and "just work". Why would a compiler
need to add a specific option for something that is rarely required and
where there is a simple and fairly obvious common option ("-v", or
"--verbose") to get the information?
For the benefit of configure scripts?
Some people need to write configure scripts. I don't. I neither know
nor care what people might want in such configure scripts, but I feel confident that if this was actually something that people needed to do
on a regular basis, either such a flag would have been added to gcc, or someone would have published a simple recipe or script for getting the information out of gcc.
What I wrote was that /I/ have never needed such a list of include
paths. And /I/ do not find it difficult to spot them from the output of "gcc -v -E empty.c". Other people's experiences may vary. Bart
apparently regularly needs to get the include paths from his own
compiler, that he wrote, which seems strange to me.
And for symmetry?
Symmetry of what?
I find
options like:
-print-search-dirs
-print-multiarch
...
-print-sysroot-headers-suffix
but the last one apparently does not work in normal install (even
for cross compilers), and the other seem to give no info about headers.
<https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html>
These options are about the way the compiler was configured when it was built. The manual page is "primarily of interest to GCC developers".
It might look like these options are for showing include directory
paths, but they are not.
On 17/09/2026 16:05, David Brown wrote:
On 17/09/2026 16:25, bart wrote:
On 17/09/2026 14:16, David Brown wrote:
On 17/09/2026 14:15, bart wrote:
On 17/09/2026 11:52, David Brown wrote:
On 17/09/2026 02:49, bart wrote:
Was there some installation process that put the headers in a >>>>>>>>> place
where gcc will look for it without being told? Does it involve >>>>>>>>> using
'pkg-config'?
Yes, installing the Ubuntu package "libsdl2-dev" created and
populated the /usr/include/SDL2 directory, among other things. >>>>>>>> That's a typical approach for Unix-like systems.
pkg-config does know about sdl2, but "#include <SDL2/SDL.h>"
appears
to work without invoking pkg-config.˙ There may be more to it than >>>>>>>> that, but I don't use SDL so I haven't looked into it.
I have no idea how you'd set it up on Windows, but ...
And I've no idea where gcc would look for its headers, other than >>>>>>> where it keeps its system headers, or how to set it up to look
permanently in certain places.
touch empty.c
gcc -E -v empty.c
That will show you, amongst other things, the default include
paths. On my system, it shows :
#include "..." search starts here:
#include <...> search starts here:
˙˙/usr/lib/gcc/x86_64-linux-gnu/13/include
˙˙/usr/local/include
˙˙/usr/include/x86_64-linux-gnu
˙˙/usr/include
End of search list.
I got a lot more output than that. Then I noticed you said 'amongst >>>>> other things'. So -v does not produce less output than --verbose!
Yes.˙ You might think it strange, but I only posted the relevant
lines here.˙ There were a total of 31 lines from that command - it
was not difficult to spot the ones relevant to the include paths.
Always making excuses for gcc! I get 37 lines from it, but because
many are long and wrap, my screen shows over 85 lines, with 25 of
them scrolling off the top of the window. It looks a mess.
If gcc had a flag to show the include paths, and nothing but the
include paths, you'd complain that you had to read through piles of
documentation to find it.˙ It does not seem to matter what inane,
pointless task you and you alone think is vital, your life seems to
revolve around saying that gcc is bad in every way.˙ So what's next?
gcc is a terrible tool because you find it harder to type "gcc" than
"bcc" ?
Sometimes you have sane points about weaknesses in C, or things that
could be improved in gcc, clang, and other tools - or at least, they
were sane points the first time you raised them rather than the
hundredth time.
Because I get bitten for the hundredth time.
Oh, and does your fantastic OS not have scrollbars to see more lines
of output?
More mitigation. Do you ever stop giving excuses for poor software?
Somebody needs some a few lines of info from a program, but the tool
buries it in 1000 lines of output, and your suggestion is to just to
scroll up and down trying to find it?
Anything but fix the problem!
˙ Are you stuck with terminal windows limited to 80 characters wide,
just like we all used last century?˙ Do you not know how to use the
"less" command? (Oh, wait, "less" is only 42 years old - we could not
expect Windows to have caught up with such basic tools in that time.
˙˙But you can use "more".)
I mentioned in another post about Clang choosing to write error
messages /in the same colour/ as my console background.
David Brown <david.brown@hesbynett.no> wrote:
<https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html>
These options are about the way the compiler was configured when it was
built. The manual page is "primarily of interest to GCC developers".
It might look like these options are for showing include directory
paths, but they are not.
That is my point.
On 17/09/2026 17:46, bart wrote:
On 17/09/2026 16:05, David Brown wrote:
On 17/09/2026 16:25, bart wrote:
On 17/09/2026 14:16, David Brown wrote:
On 17/09/2026 14:15, bart wrote:
On 17/09/2026 11:52, David Brown wrote:
On 17/09/2026 02:49, bart wrote:
Was there some installation process that put the headers in a >>>>>>>>>> place
where gcc will look for it without being told? Does it involve >>>>>>>>>> using
'pkg-config'?
Yes, installing the Ubuntu package "libsdl2-dev" created and >>>>>>>>> populated the /usr/include/SDL2 directory, among other things. >>>>>>>>> That's a typical approach for Unix-like systems.
pkg-config does know about sdl2, but "#include <SDL2/SDL.h>" >>>>>>>>> appears
to work without invoking pkg-config.˙ There may be more to it than >>>>>>>>> that, but I don't use SDL so I haven't looked into it.
I have no idea how you'd set it up on Windows, but ...
And I've no idea where gcc would look for its headers, other
than where it keeps its system headers, or how to set it up to >>>>>>>> look permanently in certain places.
touch empty.c
gcc -E -v empty.c
That will show you, amongst other things, the default include
paths. On my system, it shows :
#include "..." search starts here:
#include <...> search starts here:
˙˙/usr/lib/gcc/x86_64-linux-gnu/13/include
˙˙/usr/local/include
˙˙/usr/include/x86_64-linux-gnu
˙˙/usr/include
End of search list.
I got a lot more output than that. Then I noticed you said
'amongst other things'. So -v does not produce less output than -- >>>>>> verbose!
Yes.˙ You might think it strange, but I only posted the relevant
lines here.˙ There were a total of 31 lines from that command - it
was not difficult to spot the ones relevant to the include paths.
Always making excuses for gcc! I get 37 lines from it, but because
many are long and wrap, my screen shows over 85 lines, with 25 of
them scrolling off the top of the window. It looks a mess.
If gcc had a flag to show the include paths, and nothing but the
include paths, you'd complain that you had to read through piles of
documentation to find it.˙ It does not seem to matter what inane,
pointless task you and you alone think is vital, your life seems to
revolve around saying that gcc is bad in every way.˙ So what's next?
gcc is a terrible tool because you find it harder to type "gcc" than
"bcc" ?
Sometimes you have sane points about weaknesses in C, or things that
could be improved in gcc, clang, and other tools - or at least, they
were sane points the first time you raised them rather than the
hundredth time.
Because I get bitten for the hundredth time.
Oh, and does your fantastic OS not have scrollbars to see more lines
of output?
More mitigation. Do you ever stop giving excuses for poor software?
Somebody needs some a few lines of info from a program, but the tool
buries it in 1000 lines of output, and your suggestion is to just to
scroll up and down trying to find it?
Anything but fix the problem!
What ****ing problem?˙ You are talking about something that virtually no
C programmer ever bothers doing, and anyone who needs to ask their
compiler about the include paths only ever needs to do so /once/.˙ There were 31 lines - not a 1000
- and the relevant lines are blindingly
obvious in the output.˙ If it took you more than a second or two to spot them, you should get a better screen or a better pair of glasses.
˙ Are you stuck with terminal windows limited to 80 characters wide,
just like we all used last century?˙ Do you not know how to use the
"less" command? (Oh, wait, "less" is only 42 years old - we could not
expect Windows to have caught up with such basic tools in that time.
˙˙But you can use "more".)
I mentioned in another post about Clang choosing to write error
messages /in the same colour/ as my console background.
If only there were a simple way to change these for people who don't
like the defaults (which were probably picked to fit the extremely
common choice of black background in terminal windows).˙ If only there
were a simple way to change the background colour of your console.˙ If
only there were a simple website that could help you find out how to
change these colours by typing in a question, and copying out the
answers it gives you.˙ But no, you don't want answers, or help - you
want to cry about how tools that are fine for countless other developers
are not fine-tuned exactly to your personal preferences.
And yes, I am being patronising - stop acting like a spoiled child, and
I will stop being patronising.
If only there were a simple way to change the background colour
want to cry about how tools that are fine for countless other developers
Somebody needs some a few lines of info from a program, but the tool
buries it in 1000 lines of output, and your suggestion is to just to
scroll up and down trying to find it?
Anything but fix the problem!
I mentioned in another post about Clang choosing to write error
messages /in the same colour/ as my console background.
On 9/17/26 17:46, bart wrote:
Somebody needs some a few lines of info from a program, but the tool
buries it in 1000 lines of output, and your suggestion is to just to
scroll up and down trying to find it?
Anything but fix the problem!
˙˙ May be you can code a patch who fix the^Wyour problem, and
˙˙ send it to the Gcc team ? Any positive contribution is
˙˙ benefit to all of us.
And what's with the super-long lines that are guaranteed to wrap? The
two longest lines are 1700-1800 characters.
On 9/17/26 17:46, bart wrote:
I mentioned in another post about Clang choosing to write error
messages /in the same colour/ as my console background.
˙˙ $ some_command_who_change_color | cat
˙˙˙˙˙˙˙˙˙˙˙˙˙ problem solved.
bart <bc@freeuk.com> writes:
On 16/09/2026 16:53, David Brown wrote:
On 16/09/2026 16:20, bart wrote:
Another advantage is that the header is a single file that is easyMy test file contained a single line :
to use, copy, bundle etc. You don't need - I options.
˙˙˙˙#include <SDL2/SDL.h>
and compiled with
˙˙˙˙gcc -c test.c
There are no -I options.
Where is your SDL2 folder located relative to the current directory?
On my system (Ubuntu 24.04), it's "/usr/include/SDL2". David's
system is probably similar.
Was there some installation process that put the headers in a place
where gcc will look for it without being told? Does it involve using
'pkg-config'?
Yes, installing the Ubuntu package "libsdl2-dev" created and
populated the /usr/include/SDL2 directory, among other things.
That's a typical approach for Unix-like systems.
pkg-config does know about sdl2, but "#include <SDL2/SDL.h>" appears
to work without invoking pkg-config. There may be more to it than
that, but I don't use SDL so I haven't looked into it.
I have no idea how you'd set it up on Windows, but ...
Mine is in the current directory (that is, ./SDL3 is a folder that
contains the headers). gcc doesn't work without '-I.' on either OS:
Did you set that up manually? If you had two projects that use SDL,
would you have to create "./SDL3" folders in both of them?
[...]
On 17/09/2026 08:24, tTh wrote:
On 9/17/26 02:49, bart wrote:
And I've no idea where gcc would look for its headers, other than˙˙ You just have to read the fscking manual.
where it keeps its system headers, or how to set it up to look
permanently in certain places.
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
Nobody uses environment variables any more.
In any case, none of those
listed are set. So I still don't know how gcc even manages to find its
own system headers. But I don't care.
gcc on Windows is poor at this anyway: if I have two gcc versions
installed, then they clash, and gcc.exe doesn't appear to use paths
relative to itself to find its dependent binaries.
˙˙ But as everyone knows, learning new things isn't
˙˙ part of your philosophy...
I don't care about individual compilers, especially gcc which is a
PITA in working differently from other C compilers, apart from those
which slavishly copy all it behaviours. Examples:
So you can keep your stinkin' compiler.
On 17/09/2026 13:51, David Brown wrote:
On 17/09/2026 14:03, bart wrote:
My gcc Windows installation (I went back to 14.2 as it includesAs you well know, there is no such thing as a standard "gcc Windows"
clang), includes 3000 .h files. They can't all be for the standard
library!
installation - there are multiple different packagings of gcc with
different choices of libraries and other tools.˙ I am not sure it is
going to be very helpful if you say exactly which Windows gcc
installation you have, but there can be huge variations between
them.
If interested it was from winlibs.com. (The site looks like something
from the 1990s but it has versions up 16.2.0.)
My gcc Windows installation (I went back to 14.2 as it includes
clang), includes 3000 .h files.
They can't all be for the standard
library!
And 1200 .a archive files. So the approach there seems to be bundle
headers and binaries for every possible library. But apparently not
big ones like SDL.
I'm not interested in gcc.
On 17/09/2026 19:22, David Brown wrote:
On 17/09/2026 17:46, bart wrote:
On 17/09/2026 16:05, David Brown wrote:
On 17/09/2026 16:25, bart wrote:
On 17/09/2026 14:16, David Brown wrote:
On 17/09/2026 14:15, bart wrote:
On 17/09/2026 11:52, David Brown wrote:
On 17/09/2026 02:49, bart wrote:
Was there some installation process that put the headers in a >>>>>>>>>>> place
where gcc will look for it without being told? Does it involve >>>>>>>>>>> using
'pkg-config'?
Yes, installing the Ubuntu package "libsdl2-dev" created and >>>>>>>>>> populated the /usr/include/SDL2 directory, among other things. >>>>>>>>>> That's a typical approach for Unix-like systems.
pkg-config does know about sdl2, but "#include <SDL2/SDL.h>" >>>>>>>>>> appears
to work without invoking pkg-config.˙ There may be more to it than >>>>>>>>>> that, but I don't use SDL so I haven't looked into it.
I have no idea how you'd set it up on Windows, but ...
And I've no idea where gcc would look for its headers, other >>>>>>>>> than where it keeps its system headers, or how to set it up to >>>>>>>>> look permanently in certain places.
touch empty.c
gcc -E -v empty.c
That will show you, amongst other things, the default include >>>>>>>> paths. On my system, it shows :
#include "..." search starts here:
#include <...> search starts here:
˙˙/usr/lib/gcc/x86_64-linux-gnu/13/include
˙˙/usr/local/include
˙˙/usr/include/x86_64-linux-gnu
˙˙/usr/include
End of search list.
I got a lot more output than that. Then I noticed you said
'amongst other things'. So -v does not produce less output than -- >>>>>>> verbose!
Yes.˙ You might think it strange, but I only posted the relevant
lines here.˙ There were a total of 31 lines from that command - it >>>>>> was not difficult to spot the ones relevant to the include paths.
Always making excuses for gcc! I get 37 lines from it, but because
many are long and wrap, my screen shows over 85 lines, with 25 of
them scrolling off the top of the window. It looks a mess.
If gcc had a flag to show the include paths, and nothing but the
include paths, you'd complain that you had to read through piles of
documentation to find it.˙ It does not seem to matter what inane,
pointless task you and you alone think is vital, your life seems to
revolve around saying that gcc is bad in every way.˙ So what's next?
gcc is a terrible tool because you find it harder to type "gcc" than
"bcc" ?
Sometimes you have sane points about weaknesses in C, or things that
could be improved in gcc, clang, and other tools - or at least, they
were sane points the first time you raised them rather than the
hundredth time.
Because I get bitten for the hundredth time.
Oh, and does your fantastic OS not have scrollbars to see more lines
of output?
More mitigation. Do you ever stop giving excuses for poor software?
Somebody needs some a few lines of info from a program, but the tool
buries it in 1000 lines of output, and your suggestion is to just to
scroll up and down trying to find it?
Anything but fix the problem!
What ****ing problem?˙ You are talking about something that virtually no
C programmer ever bothers doing, and anyone who needs to ask their
compiler about the include paths only ever needs to do so /once/.˙ There
were 31 lines - not a 1000
There were 85 lines that scrolled up the screen.
But if it was 1000, then so what: your suggestion to use the scrollbar
would still work, yes?
On 17/09/2026 20:31, tTh wrote:
On 9/17/26 17:46, bart wrote:
Somebody needs some a few lines of info from a program, but the tool
buries it in 1000 lines of output, and your suggestion is to just to
scroll up and down trying to find it?
Anything but fix the problem!
˙˙ May be you can code a patch who fix the^Wyour problem, and
˙˙ send it to the Gcc team ? Any positive contribution is
˙˙ benefit to all of us.
I'm not interested in gcc. I have my own solutions.
Most command-line compilers give you version and help info when no parameters follow. But at least it says something; try this:
c:\c\as
and it apparently hangs (it's waiting for you type an assembly program
from the console!)
On Thu, 17 Sep 2026 20:54:35 +0100, bart wrote:
Most command-line compilers give you version and help info when no
parameters follow. But at least it says something; try this:
c:\c\as
and it apparently hangs (it's waiting for you type an assembly program
from the console!)
Most people read (or at least skim) the documentation
that comes with the software they use.
% man as
If you give 'as' no file names it attempts to read one
input file from the 'as' standard input, which is normally
your terminal. You may have to type ctl-D to tell 'as'
there is no more program to assemble.
HTH
On 18/09/2026 01:04, Steven G. Kargl wrote:[...]
Most people read (or at least skim) the documentation
that comes with the software they use.
Most people probably don't. They will try running such programs
without input, as often that gives usage info.
bart <bc@freeuk.com> writes:
On 17/09/2026 08:24, tTh wrote:
On 9/17/26 02:49, bart wrote:
And I've no idea where gcc would look for its headers, other than˙˙ You just have to read the fscking manual.
where it keeps its system headers, or how to set it up to look
permanently in certain places.
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
Nobody uses environment variables any more.
Obviously untrue.
gcc on Windows is poor at this anyway: if I have two gcc versions
installed, then they clash, and gcc.exe doesn't appear to use paths
relative to itself to find its dependent binaries.
I doubt that gcc is at fault for that, assuming it's true.
gcc on Windows is typically installed as part of a larger package
(since a compiler by itself can't generate executables).
It's the> responsibility of the gcc+FOO and gcc+BAR installers to arrange
for their respecive gcc's to avoid conflicting with each other.
Packaging gcc for Windows is more difficult than packaging gcc
for Unix-like systems.
˙˙ But as everyone knows, learning new things isn't
˙˙ part of your philosophy...
I don't care about individual compilers, especially gcc which is a
PITA in working differently from other C compilers, apart from those
which slavishly copy all it behaviours. Examples:
You say you don't care about gcc. I don't think that's what you mean,
given how much you talk about it.
So you can keep your stinkin' compiler.
OK. Are we done?
[116 lines deleted]
On 17/09/2026 23:06, Keith Thompson wrote:[...]
You say you don't care about gcc. I don't think that's what you
mean, given how much you talk about it.
I don't care about having to give special treatment to different compilers.
So, no comment on the fact that it can take three goes before gcc gets[...]
the DLL extension right?
Keith Thompson pisze:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
(Please, for the sake of the people that haven't killfiled you, use an
online-translator to create comprehensible texts! - In case that your
native language *is* English I suggest to translate your text to some
other language and then back to English; the translators are obviously
good enough to fix your language or writing problems in that process.)
The above was addressed to "fir".˙ As I recall, his native language
is Polish.
"fir" has been posting here for a long time.˙ Here's something our own
David Brown wrote about him in 2015.˙ I can't directly vouch for its
accuracy, but it seems plausible.
˙˙˙˙ He does not have dyslexia.˙ English is a second language for him,
˙˙˙˙ but he is capable of writing much better than he does (I have seen
˙˙˙˙ him do so) - he /intentionally/ writes in this manner because he
˙˙˙˙ considers himself too much of a grand thinker and philosopher to
˙˙˙˙ lower himself to our mere "commoner" language.˙ As far as I
˙˙˙˙ understand it, he writes in a similar manner in his own language.
˙˙˙˙ Many of us have tried to suggest he changes his manner for his own
˙˙˙˙ good as well as ours - but to no avail.
Reference:
˙˙˙˙ Subject: Re: Recursion or loop, design questions
˙˙˙˙ Date: Wed, 05 Aug 2015 08:45:25 +0200
˙˙˙˙ Message-ID: <mpsbb5$3s9$1@dont-email.me>
I suggest that one more attempt to get fir to write clearly is
unlikely to be effective.˙ I've solved the problem for myself by
adding him to my killfile.
funny, honestly i dont know why i write such way as i write
i suspect its in big extent becouse if i think on c language ideas im
kina highly focused and 'turning' to think on all this letters is on
kinda different plane so it annoys me, its hard to be focused on
thinking on higher c topics and on editing sentences, translating text
in google or chat gpt..its robably possible but so wearing that the
oryginal thoughts would sufer too much
i may say hovver i got some friends on some irc i used for years and
they never complained for some reason..though i wrote in polish there
and on chat you look on text much more than when you write messages on usenet
Lane W <cactus_DAC@yahoo.com> writes:
fir wrote:[...]
in fact i was talking about quite other and more theoretical
problem,
not how rewrite tis pice of code (as to revrite i think the ones
˙with
˙char* a= "";˙ if(d<0.3) a ="barely" ; if(d>.9) a= "hardly";
slog("siunsusn %s", a);
is best)
My concern here is that Keith Thompson is going to crucify you here
because you assigned a new value to 'a' after the previous one, which
offends his exceedingly gentle sensibilities. How will you continue to
write C if you are nailed to one of Keith Thompson's crosses?
Please refrain from mentioning my name in any future posts. I have
no interest in watching you embarrass yourself.
I intend to add you to my killfile (technically, my Gnus scorefile),
with the result that I will never see any of your posts here.
If your embarrassing behavior improves in the next few days,
I'll consider not doing so. To be clear, this is not a threat.
It's simply something I intend to do to make my own experience here
a little better, by giving me a view of comp.lang.c that does not
include you. Others will do as they wish.
On 18/09/2026 01:04, Steven G. Kargl wrote:
On Thu, 17 Sep 2026 20:54:35 +0100, bart wrote:
Most command-line compilers give you version and help info when no
parameters follow. But at least it says something; try this:
c:\c\as
and it apparently hangs (it's waiting for you type an assembly program
from the console!)
Most people read (or at least skim) the documentation
that comes with the software they use.
Most people probably don't.
They will try running such programs without
input, as often that gives usage info.
'as' is more peculiar than most assemblers:
* It takes input from stdin as default
* The output, even on Windows, is a file called a.out
* If given two or more input files, these are literally concatenated
into one ASM file. More typically there is one object file produced per file
% man as
'man' doesn't exist on Windows.
Using 'as --help' gives lots of
complicated options that will mean little to some who has not used this before and simply wants to turn file.s into file.o.
This is my assembler for example when I type its name:
c:\c>aa
AA7 Assembler 29-Aug-2026
Usage:
aa filename[.asm] # Assemble filename.asm to filename.exe
aa -help # Show other options
Simple, yes?
On Fri, 18 Sep 2026 01:34:12 +0100, bart wrote:
On 18/09/2026 01:04, Steven G. Kargl wrote:
On Thu, 17 Sep 2026 20:54:35 +0100, bart wrote:
Most command-line compilers give you version and help info when no
parameters follow. But at least it says something; try this:
c:\c\as
and it apparently hangs (it's waiting for you type an assembly program >>>> from the console!)
Most people read (or at least skim) the documentation
that comes with the software they use.
Most people probably don't.
Touche. As a gfortran contributor, I'm well-aware of
the fact that users lack reading abilities.
They will try running such programs without
input, as often that gives usage info.
Not on a Unix(-like) system. Many tools will fall-back to accepting
stdin for input. It's essentially how pipes on a command line
work. May Microsoft doesn't know how to use pipes?
'as' is more peculiar than most assemblers:
* It takes input from stdin as default
* The output, even on Windows, is a file called a.out
* If given two or more input files, these are literally concatenated
into one ASM file. More typically there is one object file produced per file >>
% man as
'man' doesn't exist on Windows.
Well, this is your problem. Why are you using Window? :-)
(and, no, linux is not the answer.)
If 'man' doesn't exist on windows, google 'GNU as manual'.
You might learn how to use the tool should work.
Using 'as --help' gives lots of
complicated options that will mean little to some who has not used this
before and simply wants to turn file.s into file.o.
This is my assembler for example when I type its name:
c:\c>aa
AA7 Assembler 29-Aug-2026
Usage:
aa filename[.asm] # Assemble filename.asm to filename.exe
aa -help # Show other options
Simple, yes?
I suppose it's simply if one doesn't want to enter
an assembly program at the command line.
% as
.text;
.p2align 4,0x90;
.globl sqrt;
.type sqrt,@function;
sqrt:;
.cfi_startproc
fldl 4(%esp)
fsqrt
ret
.size sqrt, . - sqrt; .cfi_endproc
.section .note.GNU-stack,"",%progbits
% nm a.out
0000000000000000 T sqrt
or one can do
% cat z.s
.text;
.p2align 4,0x90;
.globl sqrt;
.type sqrt,@function;
sqrt:;
.cfi_startproc
fldl 4(%esp)
fsqrt
ret
.size sqrt, . - sqrt; .cfi_endproc
.section .note.GNU-stack,"",%progbits
% cat z.s | as
% nm a.out
0000000000000000 T sqrt
bart <bc@freeuk.com> writes:
[...]
My gcc Windows installation (I went back to 14.2 as it includes
clang), includes 3000 .h files.
No it doesn't. As explained downthread, most of them are from
MinGW-w64, which is packaged along with gcc by WinLibs (winlibs.com).
They can't all be for the standard
library!
They aren't -- and gcc doesn't provide (most of) the standard library
anyway. The "gcc" package does provide some .h files, some for internal
use and some like stddef.h that are more closely tied to the compiler
than to the library implementation.
On 15/09/2026 11:51, Janis Papanagnou wrote:[...]
Right. - But don't forget that "spurious means" to tackle a topic is
as well a source of obfuscating information; I certainly won't judge
whether one or the other is in any (absolute or relative) way "better",
but it certainly reminds me the recurring "if(a=5) vs. if(5=a)" debate
to "ensure" "programming safety".
[...]
And we all know we should be writing "if (a == 5)", with decent spacing :-)
Far more effective than any one developer changing their coding style
would be having more warnings enabled by default in common compilers.
(clang warns about "if (a = 5)" by default, while gcc needs "-Wall".
Both warn about the misleading indentation only when warnings are enabled.)
Sure. - The point is; is there an objectively safe style here?
I think there's subjective styles that helps some and annoys others.
I have no statistics or reports to back up anything I say, so I can only
say that I would /expect/ to see a small but measurable reduction in
code errors if "indent without braces" conditionals are not allowed in
code, if one were to compare code samples that had not used appropriate static checks.˙ That is, I /believe/ there is a objective difference
here.˙ But I certainly can't claim to /know/ that there is.˙ And even if statistics bear me out here (maybe some PhD student has done the
research), that would still not contradict your statement.˙ It is
entirely reasonable to suppose that the style choices here would reduce risks for some programmers while making no difference to others - and no
one likes being told to change their style without good reason.
I don't think it makes sense to argue about that. (Especially given
that we both have many decades of experience in the area.)
This also makes it difficult to judge.˙ I am confident that any choice
of style here would make no difference to the risk of errors in either
your code or my code - we both know how to use "-Wall" and pay attention
to the warnings, so if we /did/ make a mistake, our tools would tell us.
[...]
On 9/10/2026 7:00 AM, fir wrote:
Keith Thompson pisze:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
(Please, for the sake of the people that haven't killfiled you, use an >>>> online-translator to create comprehensible texts! - In case that your
native language *is* English I suggest to translate your text to some
other language and then back to English; the translators are obviously >>>> good enough to fix your language or writing problems in that process.)
The above was addressed to "fir".˙ As I recall, his native language
is Polish.
"fir" has been posting here for a long time.˙ Here's something our own
David Brown wrote about him in 2015.˙ I can't directly vouch for its
accuracy, but it seems plausible.
˙˙˙˙ He does not have dyslexia.˙ English is a second language for him,
˙˙˙˙ but he is capable of writing much better than he does (I have seen
˙˙˙˙ him do so) - he /intentionally/ writes in this manner because he
˙˙˙˙ considers himself too much of a grand thinker and philosopher to
˙˙˙˙ lower himself to our mere "commoner" language.˙ As far as I
˙˙˙˙ understand it, he writes in a similar manner in his own language.
˙˙˙˙ Many of us have tried to suggest he changes his manner for his own
˙˙˙˙ good as well as ours - but to no avail.
Reference:
˙˙˙˙ Subject: Re: Recursion or loop, design questions
˙˙˙˙ Date: Wed, 05 Aug 2015 08:45:25 +0200
˙˙˙˙ Message-ID: <mpsbb5$3s9$1@dont-email.me>
I suggest that one more attempt to get fir to write clearly is
unlikely to be effective.˙ I've solved the problem for myself by
adding him to my killfile.
funny, honestly i dont know why i write such way as i write
i suspect its in big extent becouse if i think on c language ideas im
kina highly focused and 'turning' to think on all this letters is on
kinda different plane so it annoys me, its hard to be focused on
thinking on higher c topics and on editing sentences, translating text
in google or chat gpt..its robably possible but so wearing that the
oryginal thoughts would sufer too much
i may say hovver i got some friends on some irc i used for years and
they never complained for some reason..though i wrote in polish there
and on chat you look on text much more than when you write messages on
usenet
I also find it funny, that when I write /clearly/ here in comp.lang.c,
I get accused of being an L.L.M.˙ This is apparently special for comp. lang.c, because I've received no such accusation in other Usenet groups.
Also, I.R.C. users are probably more used to idiosyncratic text mess-
ages, and therefore have no reason to /killfile/ you, just because they
don't have enough reading comprehension to read what they decide is "bad English."
At least, I have no problem understanding you.
Best wishes, and happy forking C!
On 09/09/2026 8:37 PM, fir wrote:
fir pisze:
Johann 'Myrkraverk' Oskarsson pisze:besides he is partally right - he has a bit rigid definitions who
On 09/09/2026 4:18 PM, fir wrote:
Johann 'Myrkraverk' Oskarsson pisze:Yeah, I don't worry about Keith and trolls like him, and discuss what I >>>> want in comp.lang.c.˙ Including meta discussions like this one, about
On 08/09/2026 7:52 AM, Keith Thompson wrote:
Lane W <cactus_DAC@yahoo.com> writes:
[128 lines deleted]
One of the things I avoid in C# is a nasty makefile, and generally >>>>>>>> having to tool around in Unix. That is all taken care of by the C# >>>>>>>> compiler included in the suite I use to generate my programs.
OK, I think we've established that you like C# better than C
(or C++).
This is comp.lang.c.˙ Complaints about C are topical here, even
though some of the ones that introduced this thread are silly.
But if you want to discuss C#, please do so elsewhere.
Oh, don't mind Keith.˙ He likes to butt in on other people's
discussions
and behave like he's some owner of comp.lang.c.˙ He's not.˙ There >>>>>> isn't
even a comp.lang.csharp group to direct people towards.˙ I guess
Keith
will just have to start a discussion in news.groups.proposals
about it.
I've added microsoft.public.dotnet.csharp.general to this discussion, >>>>>> but I have no idea if Eternal September subscribes to it, which I be- >>>>>> lieve is what most techies use to access usenet.˙ And the last on- >>>>>> topic
post in microsoft.public.dotnet.csharp.general seems to have been >>>>>> six-
teen years ago.
That's a long time for nobody to get comp.lang.csharp running.
So please feel free to complain in comp.lang.c -- and let the # be >>>>>> si-
lent -- until someone gets irritated enough to make a proposal that >>>>>> sticks!
Best wishes, and happy coding in C#!
this is probably not god taking on this ...the offtopics imo
depending on amount (yet quality)..if group has some focus it
should be focus on
c realted things with some offtopics possible not focus on c not
realted
offtopics with slight amount of c related...
so i find some sense in what keith t says though i personally cant
agree
with his inner idea this group is only for discussing
1) c standards
not
2) c ideas
or
3) c programming
what should and shouldn't be discussed in comp.lang.c.
Plus, it's fairly clear none of the usual trolls code anything in C, as >>>> I demonstrated when I gave you some book recommendations.
Best wishes, and happy C coding!
keith probably used to call me a troll (oz i not stick to his own
rigid rules)
so i could eventuall call him back a troll but as i once said if i
noticed
it is better to value regular users of this group becouse if not hem
the group culd not exist and i would have no place to talk at all
so i dont call him a troll, becouse he is okay user overally i just
disagree in some things
troll is - but this is kinda complex matter becouse depending on
definitions i may be a troll according to one, he may be atroll
according to another
and so on..and which definitions are good and for what reason is a
complex thing - not sure if this is resolvable...
generally i find whats good to improve some focus and knowledge here
as godo and whats the oposite makin brainless spam is bad etc
Indeed.˙ And for that reason, I still hope you'll read /Patterns in C/
one of these days.˙ Or if I -- or someone else -- comes across a better reference, to share it with you.
There is a lot of C knowledge out there, and the language standard isn't
the end game of being a C wizard.
On 18/09/2026 00:24, Keith Thompson wrote:[...]
They aren't -- and gcc doesn't provide (most of) the standard library
anyway. The "gcc" package does provide some .h files, some for
internal use and some like stddef.h that are more closely tied to the
compiler than to the library implementation.
While gcc does not provide a C standard library (as has been explained
to Bart endlessly), the gcc team /do/ provide a C++ standard
library. It is not part of the C compiler, but it is almost certainly
also included in the "winlibs" package. And while the user-facing
headers in the C++ standard library are mostly without extension, most
of the internal headers are ".h" files. Thus a not insignificant part
of those ".h" files he has were provided by gcc rather than third
parties, but are not part of the C standard library.
On Fri, 18 Sep 2026 01:34:12 +0100, bart wrote:
This is my assembler for example when I type its name:
c:\c>aa
AA7 Assembler 29-Aug-2026
Usage:
aa filename[.asm] # Assemble filename.asm to filename.exe
aa -help # Show other options
Simple, yes?
I suppose it's simply if one doesn't want to enter
an assembly program at the command line.
% as
.text;
.p2align 4,0x90;
.globl sqrt;
.type sqrt,@function;
sqrt:;
.cfi_startproc
fldl 4(%esp)
fsqrt
ret
.size sqrt, . - sqrt; .cfi_endproc
.section .note.GNU-stack,"",%progbits
On 17/09/2026 23:06, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
On 17/09/2026 08:24, tTh wrote:
On 9/17/26 02:49, bart wrote:
And I've no idea where gcc would look for its headers, other than˙ ˙˙ You just have to read the fscking manual.
where it keeps its system headers, or how to set it up to look
permanently in certain places.
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
Nobody uses environment variables any more.
Obviously untrue.
Let's say they're out of fashion.
gcc on Windows is poor at this anyway: if I have two gcc versions
installed, then they clash, and gcc.exe doesn't appear to use paths
relative to itself to find its dependent binaries.
I doubt that gcc is at fault for that, assuming it's true.
gcc on Windows is typically installed as part of a larger package
(since a compiler by itself can't generate executables).
I think the problem was that gcc runs support programs such as cc1.exe
by relying on Windows to search the default paths.
But if you have two versions A and B, and both their paths are listed in
the PATH variable, then when B's gcc tries to run cc1.exe, it will be
A's version, as A's path is listed first.
It's the> responsibility of the gcc+FOO and gcc+BAR installers toarrange
for their respecive gcc's to avoid conflicting with each other.
Packaging gcc for Windows is more difficult than packaging gcc
for Unix-like systems.
It's not hard; it should really have used a path relative to B's gcc.exe.
It would still pick A's gcc.exe if typing an unqualified 'gcc' by
itself, but how does Linux solve this problem when you have two gcc's to choose from?
On 2026-09-15 12:53, David Brown wrote:
On 15/09/2026 11:51, Janis Papanagnou wrote:[...]
Right. - But don't forget that "spurious means" to tackle a topic is
as well a source of obfuscating information; I certainly won't judge
whether one or the other is in any (absolute or relative) way "better",
but it certainly reminds me the recurring "if(a=5) vs. if(5=a)" debate
to "ensure" "programming safety".
[...]
And we all know we should be writing "if (a == 5)", with decent
spacing :-)
Sure. Above was just a deliberate terse form for inline reference.
Usually I'm using probably more spacing inline and between lines
and chapters than the average programmer would find tolerable. ;-)
Far more effective than any one developer changing their coding style
would be having more warnings enabled by default in common compilers.
(clang warns about "if (a = 5)" by default, while gcc needs "-Wall".
Both warn about the misleading indentation only when warnings are
enabled.)
Yes, things have gotten much better since the dates back then when
I did my professional programming in C/C++.
Sure. - The point is; is there an objectively safe style here?
I think there's subjective styles that helps some and annoys others.
I have no statistics or reports to back up anything I say, so I can
only say that I would /expect/ to see a small but measurable reduction
in code errors if "indent without braces" conditionals are not allowed
in code, if one were to compare code samples that had not used
appropriate static checks.˙ That is, I /believe/ there is a objective
difference here.˙ But I certainly can't claim to /know/ that there
is.˙ And even if statistics bear me out here (maybe some PhD student
has done the research), that would still not contradict your
statement.˙ It is entirely reasonable to suppose that the style
choices here would reduce risks for some programmers while making no
difference to others - and no one likes being told to change their
style without good reason.
Actually, we established coding standards, and not following these required(!) - by those same standards - any deviation to be explained.
(BTW, I authored, co-authored, and reviewed coding standard for three different programming languages; one of the rules - and contrary to my
own convenience - was to always use braces also in the cases discussed!
Just note that I haven't formulated it because one would be safer than
the other; but we had to choose one option, and the rule to "always use braces" is just simpler (more practicable and easier to memorize) than
an also sensible but very differentiated rule option - remember these
simple 'if' cascades.)
I don't think it makes sense to argue about that. (Especially given
that we both have many decades of experience in the area.)
This also makes it difficult to judge.˙ I am confident that any choice
of style here would make no difference to the risk of errors in either
your code or my code - we both know how to use "-Wall" and pay
attention to the warnings, so if we /did/ make a mistake, our tools
would tell us.
You might be astonished but I don't recall to have needed any explicit warnings setting; our policy was a zero-warning approach (by the default warnings of our compilers), and where we identified any needs beyond we communicated with the build-management to make it the company default.
Having good programmers, providing trainings and courses, helped also.
Johann 'Myrkraverk' Oskarsson pisze:
On 09/09/2026 8:37 PM, fir wrote:
fir pisze:
Johann 'Myrkraverk' Oskarsson pisze:besides he is partally right - he has a bit rigid definitions who
On 09/09/2026 4:18 PM, fir wrote:
Johann 'Myrkraverk' Oskarsson pisze:Yeah, I don't worry about Keith and trolls like him, and discuss
On 08/09/2026 7:52 AM, Keith Thompson wrote:
Lane W <cactus_DAC@yahoo.com> writes:
[128 lines deleted]
One of the things I avoid in C# is a nasty makefile, and generally >>>>>>>>> having to tool around in Unix. That is all taken care of by the C# >>>>>>>>> compiler included in the suite I use to generate my programs. >>>>>>>>OK, I think we've established that you like C# better than C
(or C++).
This is comp.lang.c.˙ Complaints about C are topical here, even >>>>>>>> though some of the ones that introduced this thread are silly. >>>>>>>> But if you want to discuss C#, please do so elsewhere.
Oh, don't mind Keith.˙ He likes to butt in on other people's
discussions
and behave like he's some owner of comp.lang.c.˙ He's not.˙ There >>>>>>> isn't
even a comp.lang.csharp group to direct people towards.˙ I guess >>>>>>> Keith
will just have to start a discussion in news.groups.proposals
about it.
I've added microsoft.public.dotnet.csharp.general to this
discussion,
but I have no idea if Eternal September subscribes to it, which I >>>>>>> be-
lieve is what most techies use to access usenet.˙ And the last
on- topic
post in microsoft.public.dotnet.csharp.general seems to have been >>>>>>> six-
teen years ago.
That's a long time for nobody to get comp.lang.csharp running.
So please feel free to complain in comp.lang.c -- and let the # >>>>>>> be si-
lent -- until someone gets irritated enough to make a proposal that >>>>>>> sticks!
Best wishes, and happy coding in C#!
this is probably not god taking on this ...the offtopics imo
depending on amount (yet quality)..if group has some focus it
should be focus on
c realted things with some offtopics possible not focus on c not
realted
offtopics with slight amount of c related...
so i find some sense in what keith t says though i personally cant >>>>>> agree
with his inner idea this group is only for discussing
1) c standards
not
2) c ideas
or
3) c programming
what I
want in comp.lang.c.˙ Including meta discussions like this one, about >>>>> what should and shouldn't be discussed in comp.lang.c.
Plus, it's fairly clear none of the usual trolls code anything in
C, as
I demonstrated when I gave you some book recommendations.
Best wishes, and happy C coding!
keith probably used to call me a troll (oz i not stick to his own
rigid rules)
so i could eventuall call him back a troll but as i once said if i
noticed
it is better to value regular users of this group becouse if not hem
the group culd not exist and i would have no place to talk at all
so i dont call him a troll, becouse he is okay user overally i just
disagree in some things
troll is - but this is kinda complex matter becouse depending on
definitions i may be a troll according to one, he may be atroll
according to another
and so on..and which definitions are good and for what reason is a
complex thing - not sure if this is resolvable...
generally i find whats good to improve some focus and knowledge here
as godo and whats the oposite makin brainless spam is bad etc
Indeed.˙ And for that reason, I still hope you'll read /Patterns in C/
one of these days.˙ Or if I -- or someone else -- comes across a better
reference, to share it with you.
There is a lot of C knowledge out there, and the language standard isn't
the end game of being a C wizard.
if those patterns are typical like by this insane oop crowd im not interesyed, im interested in more algebraical concise˙ solutions only
David Brown <david.brown@hesbynett.no> writes:
I've said a number of times that "gcc" is a compiler, not a full C implementation. It's worth pointing out that the software package
called "gcc" (downloadable in source form from gcc.gnu.org) does
include some other software in addition to the compiler, including
a small part of the library implementation for C and a much larger
part of the library implementation for C++.
OS-specific installers can and often do break this up into multiple installable packages. For example, on Ubuntu and related systems,
the GNU compilers for various languages (C, C++, Fortran, Cobol,
Ada, et al) are in separate packages, as are the headers and code.
I have oversimplified this in the past.
Having said all that, it is absolutely not the case that the bulk
of the C standard library implementation is part of "gcc", however
much a certain poster here pretends to believe that it is.
But I /can/ tell you exactly how my own C implementation for Windows
works.
bart <bc@freeuk.com> writes:
[...]
But I /can/ tell you exactly how my own C implementation for Windows
works.
But I don't care.
On 18/09/2026 03:04, bart wrote:
But if you have two versions A and B, and both their paths are listed
in the PATH variable, then when B's gcc tries to run cc1.exe, it will
be A's version, as A's path is listed first.
It is conceivable that the folks behind this "winlib" packaging are
idiots.˙ But assuming they are not, then "cc1.exe" will not be in your
path.˙ The gcc driver program finds the additional parts in a path
dependent on the way it was configured when built.
On 17/09/2026 20:31, tTh wrote:
On 9/17/26 17:46, bart wrote:
Somebody needs some a few lines of info from a program, but the tool
buries it in 1000 lines of output, and your suggestion is to just to
scroll up and down trying to find it?
Anything but fix the problem!
˙˙˙ May be you can code a patch who fix the^Wyour problem, and
˙˙˙ send it to the Gcc team ? Any positive contribution is
˙˙˙ benefit to all of us.
I'm not interested in gcc. I have my own solutions.
This is just one more annoying thing about that program. The issue here
is that nobody is daring to criticise its crass behaviours, while trying
to deflect issues onto users.
Its crassness starts here:
˙ c:\c>gcc
˙ gcc: fatal error: no input files
˙ compilation terminated.
Most command-line compilers give you version and help info when no parameters follow.
But at least it says something; try this:
˙ c:\c\as
and it apparently hangs (it's waiting for you type an assembly program
from the console!)
How did programs which work like some student's crude first console app
ever make it into the wild?
On 18/09/2026 10:27, David Brown wrote:
On 18/09/2026 03:04, bart wrote:
But if you have two versions A and B, and both their paths are listed
in the PATH variable, then when B's gcc tries to run cc1.exe, it will
be A's version, as A's path is listed first.
It is conceivable that the folks behind this "winlib" packaging are
idiots.˙ But assuming they are not, then "cc1.exe" will not be in your
path.˙ The gcc driver program finds the additional parts in a path
dependent on the way it was configured when built.
I've just tried two WINLIBS gcc versions, and now they work fine, if you
use an explicit path to their respective gcc.exe files.
The issue may have been with TDM distributions that I used to use. But WINLIBS has newer gcc versions.
On 17/09/2026 23:06, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
On 17/09/2026 08:24, tTh wrote:
On 9/17/26 02:49, bart wrote:
And I've no idea where gcc would look for its headers, other than˙˙ You just have to read the fscking manual.
where it keeps its system headers, or how to set it up to look
permanently in certain places.
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
Nobody uses environment variables any more.
Obviously untrue.
Let's say they're out of fashion.
On 17/09/2026 21:54, bart wrote:
On 17/09/2026 20:31, tTh wrote:
On 9/17/26 17:46, bart wrote:
Somebody needs some a few lines of info from a program, but the tool
buries it in 1000 lines of output, and your suggestion is to just to
scroll up and down trying to find it?
Anything but fix the problem!
˙˙˙ May be you can code a patch who fix the^Wyour problem, and
˙˙˙ send it to the Gcc team ? Any positive contribution is
˙˙˙ benefit to all of us.
I'm not interested in gcc. I have my own solutions.
This is just one more annoying thing about that program. The issue
here is that nobody is daring to criticise its crass behaviours, while
trying to deflect issues onto users.
Its crassness starts here:
˙˙ c:\c>gcc
˙˙ gcc: fatal error: no input files
˙˙ compilation terminated.
Simple, clear, and to-the-point.
Most command-line compilers give you version and help info when no
parameters follow.
Some do, some do not.
Most command-line tools - gcc included - give you version information if
you write "gcc --version", and help if you give "gcc --help".
But at least it says something; try this:
˙˙ c:\c\as
and it apparently hangs (it's waiting for you type an assembly program
from the console!)
Many programs can work as pipes.˙ It is waiting for input from stdin,
not particularly from the console.˙ Programs that often get their input directly from other programs work this way.
How did programs which work like some student's crude first console
app ever make it into the wild?
Perhaps it is because the developers know how to write programs designed
to do useful jobs in a way that is convenient and efficient for the
tasks they actually have to do?˙ Maybe the developers of "as" expected
users to have a clue about what they are doing?
bart <bc@freeuk.com> writes:
On 18/09/2026 01:04, Steven G. Kargl wrote:[...]
Most people read (or at least skim) the documentation
that comes with the software they use.
Most people probably don't. They will try running such programs
without input, as often that gives usage info.
[...]
You've seen how that approach fails.
There are valid reasons for the way "as" behaves.
Your assumptions
about how you think it *should* behave have led you astray.
I suggest that it is your approach, not "as", that needs to change.
Quick summary: You are trying to use tools that were originally
designed to be used in a Unix-like environment, and expecting them
to behave like native Windows tools.
I'll explain further if you ask, but only if you convince me that
you're actually interested in learning.
In article <118i2mc$q9l1$1@dont-email.me>, bart <bc@freeuk.com>
wrote:
On 17/09/2026 23:06, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
On 17/09/2026 08:24, tTh wrote:
On 9/17/26 02:49, bart wrote:
And I've no idea where gcc would look for its headers, other˙˙ You just have to read the fscking manual.
than where it keeps its system headers, or how to set it up to
look permanently in certain places.
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
Nobody uses environment variables any more.
Obviously untrue.
Let's say they're out of fashion.
Why would you say such a thing? While they may not be the most
elegant solution to a number of problems, they're very much in
use, and "in fashion", at least on Unix-derived systems.
- Dan C.
On 18/09/2026 12:11, David Brown wrote:
On 17/09/2026 21:54, bart wrote:
On 17/09/2026 20:31, tTh wrote:
On 9/17/26 17:46, bart wrote:
Somebody needs some a few lines of info from a program, but the
tool buries it in 1000 lines of output, and your suggestion is to
just to scroll up and down trying to find it?
Anything but fix the problem!
˙˙˙ May be you can code a patch who fix the^Wyour problem, and
˙˙˙ send it to the Gcc team ? Any positive contribution is
˙˙˙ benefit to all of us.
I'm not interested in gcc. I have my own solutions.
This is just one more annoying thing about that program. The issue
here is that nobody is daring to criticise its crass behaviours,
while trying to deflect issues onto users.
Its crassness starts here:
˙˙ c:\c>gcc
˙˙ gcc: fatal error: no input files
˙˙ compilation terminated.
Simple, clear, and to-the-point.
Most command-line compilers give you version and help info when no
parameters follow.
Some do, some do not.
Most command-line tools - gcc included - give you version information
if you write "gcc --version", and help if you give "gcc --help".
But at least it says something; try this:
˙˙ c:\c\as
and it apparently hangs (it's waiting for you type an assembly
program from the console!)
Many programs can work as pipes.˙ It is waiting for input from stdin,
not particularly from the console.˙ Programs that often get their
input directly from other programs work this way.
How did programs which work like some student's crude first console
app ever make it into the wild?
Perhaps it is because the developers know how to write programs
designed to do useful jobs in a way that is convenient and efficient
for the tasks they actually have to do?˙ Maybe the developers of "as"
expected users to have a clue about what they are doing?
Both are at odds with how similar command line tools work. gcc and as
are even at odds with each other:
- gcc complains about the missing input file (in a manner that treats it
˙ as a compilation error)
- as defaults to reading content from stdin
- Given two files, gcc compiles them independently; as assembles them
˙ after effectively combining them (imagine if gcc concatenated all the
˙ .c files you give it; it would be ludicrous).
So I repeat that this is not how you would sensibly write such tools.
I
mean, is it unreasonable to expect '-shared' on Windows to result in a
file ending with .dll rather than .exe?
But gcc and as are given a pass because ... that's how the original
crude versions worked and for some reason it was never practical to
change it?
In that case say so, rather than pretending that those quirks are really desirable features.
I mean, you do 'gcc prog1.c', wait some time for it to produce 'a.exe'.
Now you do 'gcc prog2.c', and it promptly overwrites the 'a.exe' from
the last compile! That is quite laughable.
At the moment, compiling my bignum library on Windows looks like this:
˙ gcc -shared -s bignum.c -o bignum.dll˙˙˙ # .dll is 101KB
˙ bcc -dll bignum˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ # .dll is 16KB
Yes, I know, you never use gcc directly; invocations are hidden within makefiles, IDEs, and shell scripts.
But I'm discussing their merits /as/ command-line tools that you use hands-on.
On 18/09/2026 01:04, Steven G. Kargl wrote:
On Thu, 17 Sep 2026 20:54:35 +0100, bart wrote:
Most command-line compilers give you version and help info when no
parameters follow. But at least it says something; try this:
c:\c\as
and it apparently hangs (it's waiting for you type an assembly program
from the console!)
Most people read (or at least skim) the documentation
that comes with the software they use.
Most people probably don't. They will try running such programs without >input, as often that gives usage info.
'man' doesn't exist on Windows.
On Thu, 17 Sep 2026 17:50:57 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
bart <bc@freeuk.com> writes:
On 18/09/2026 01:04, Steven G. Kargl wrote:[...]
Most people read (or at least skim) the documentation
that comes with the software they use.
Most people probably don't. They will try running such programs
without input, as often that gives usage info.
[...]
You've seen how that approach fails.
There are valid reasons for the way "as" behaves.
Well, if you consider compatibility with weird notion of "user
interface" of its original creator as a valid reason, then yes.
Even I accept it as valid.
Which does not make it less bad in the absolute sense.
Desire to give to user an option to accept an input from standard
input by itself is not unreasonable, bit it should be an option rather
than default.
On 2026-09-10, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
On 9/9/2026 5:43 AM, David Brown wrote:
[...]
Just defining the symbol is fine - for use as a pure header guard,
where the check is with "#ifndef" or "#ifdef", defining it to a
value has no added value. Adding the "1" in that example was done
without thinking.
________
#ifndef __NUMBER_GENERATOR_H__
#define __NUMBER_GENERATOR_H__ 1
________
Is that __* non conformant? Does it breach the impl name prefix
space?
No matter what you name anything in C, you are playing roulette.
Vendor extensions and new standard features introduce identifiers
into namespaces that have not been hitherto reserved.
It's like a traffic code. If you intrude into a namespace, it's
like running a stop sign. Nothing bad might happen, but if it
does, it is on you.
However, C naming is like a residential neighborhood full of
unguarded intersections, with only a few stop signs.
There isn't anything reasonable you can do to 100% ensure you will
never have a clash with anything in your C programming. (By
"reasonable", I do not intend to introduce moving goalposts:
specifically, I mean, not subjecting yourself to some horribly
inconvenient naming scheme in every single namespace which makes
it vanishingly improbable of ever seeing a clash).
bart <bc@freeuk.com> writes:So how do they tell whether a program is hanging, or is waiting for input?
On 18/09/2026 01:04, Steven G. Kargl wrote:
On Thu, 17 Sep 2026 20:54:35 +0100, bart wrote:
Most command-line compilers give you version and help info when no
parameters follow. But at least it says something; try this:
c:\c\as
and it apparently hangs (it's waiting for you type an assembly program >>>> from the console!)
Most people read (or at least skim) the documentation
that comes with the software they use.
Most people probably don't. They will try running such programs without
input, as often that gives usage info.
Please try to speak for yourself.
Those familiar with unix would understand implicitly, as many
commands will read from stdin if no filename is specified.
Michael S <already5chosen@yahoo.com> writes:
On Thu, 17 Sep 2026 17:50:57 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
bart <bc@freeuk.com> writes:
On 18/09/2026 01:04, Steven G. Kargl wrote:[...]
Most people read (or at least skim) the documentation
that comes with the software they use.
Most people probably don't. They will try running such programs
without input, as often that gives usage info.
[...]
You've seen how that approach fails.
There are valid reasons for the way "as" behaves.
Well, if you consider compatibility with weird notion of "user
interface" of its original creator as a valid reason, then yes.
Even I accept it as valid.
Which does not make it less bad in the absolute sense.
Desire to give to user an option to accept an input from standard
input by itself is not unreasonable, bit it should be an option
rather than default.
That's your opinion. That's not the unix philosophy. Many
unix commands default to stdin if no file name is specified
(specifically to support streaming the output of one command
to the input of another).
By convention a single dash character may be specified
in place of a filename to specify stdin.
On 17/09/2026 23:06, Keith Thompson wrote:
But if you have two versions A and B, and both their paths are listed in
the PATH variable, then when B's gcc tries to run cc1.exe, it will be
A's version, as A's path is listed first.
It's the> responsibility of the gcc+FOO and gcc+BAR installers to arrange
for their respecive gcc's to avoid conflicting with each other.
Packaging gcc for Windows is more difficult than packaging gcc
for Unix-like systems.
It's not hard; it should really have used a path relative to B's gcc.exe.
It would still pick A's gcc.exe if typing an unqualified 'gcc' by
itself, but how does Linux solve this problem when you have two gcc's to >choose from?
So, no comment on the fact that it can take three goes before gcc gets
the DLL extension right?
On 18/09/2026 03:04, bart wrote:
On 17/09/2026 23:06, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
On 17/09/2026 08:24, tTh wrote:
On 9/17/26 02:49, bart wrote:
And I've no idea where gcc would look for its headers, other than˙ ˙˙ You just have to read the fscking manual.
where it keeps its system headers, or how to set it up to look
permanently in certain places.
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
Nobody uses environment variables any more.
Obviously untrue.
Let's say they're out of fashion.
Let's not. Lots of people use them for various purposes.
On Fri, 18 Sep 2026 12:55:11 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
In article <118i2mc$q9l1$1@dont-email.me>, bart <bc@freeuk.com>
wrote:
On 17/09/2026 23:06, Keith Thompson wrote: =20=20
bart <bc@freeuk.com> writes: =20
On 17/09/2026 08:24, tTh wrote: =20=20
On 9/17/26 02:49, bart wrote: =20
And I've no idea where gcc would look for its headers, other=C2=A0=C2=A0 You just have to read the fscking manual.
than where it keeps its system headers, or how to set it up to
look permanently in certain places. =20
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html =20
Nobody uses environment variables any more. =20
Obviously untrue. =20
Let's say they're out of fashion. =20
Why would you say such a thing? While they may not be the most
elegant solution to a number of problems, they're very much in
use, and "in fashion", at least on Unix-derived systems.
=20
- Dan C.
=20
Would you design a new program which behavior can be modified by
environment variables? I don't mean standard environment variables, like >locale (although that is also less than great) but environment
variables specific to your program?
On Fri, 18 Sep 2026 15:28:21 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Michael S <already5chosen@yahoo.com> writes:
On Thu, 17 Sep 2026 17:50:57 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
bart <bc@freeuk.com> writes:
On 18/09/2026 01:04, Steven G. Kargl wrote:[...]
Most people read (or at least skim) the documentation
that comes with the software they use.
Most people probably don't. They will try running such programs
without input, as often that gives usage info.
[...]
You've seen how that approach fails.
There are valid reasons for the way "as" behaves.
Well, if you consider compatibility with weird notion of "user
interface" of its original creator as a valid reason, then yes.
Even I accept it as valid.
Which does not make it less bad in the absolute sense.
Desire to give to user an option to accept an input from standard
input by itself is not unreasonable, bit it should be an option
rather than default.
That's your opinion. That's not the unix philosophy. Many
unix commands default to stdin if no file name is specified
(specifically to support streaming the output of one command
to the input of another).
There is big difference between utilities like grep or sort and
something like as. Blindly treating them as the same is wrong.
By convention a single dash character may be specified
in place of a filename to specify stdin.
The latter is reasonable. What as does is not.
[...]On 17/09/2026 21:54, bart wrote:
[...]I'm not interested in gcc. [...]
The program "gcc" is a driver program, written by the GCC folks, and
run directly by developers. "as" is an assembler, written by the
binutils folks, that is very rarely used directly by developers.
Were I writing a new assembler for Linux, I would probably not make it
work as a pipe by default - and require a dash or two, or another command-line option. Running "my-new-assembler" with no options or
files would exit immediately, perhaps with a "no input files" error or perhaps with a "use --help for help" message. (Or perhaps with no
output at all, which I think would also be a reasonable choice.) So
while I think "act as a pipe" is a reasonable choice for "as" with no
input files, I think there are other choices that are at least
somewhat better.
On 18/09/2026 16:24, Scott Lurndal wrote:[...]
Those familiar with unix would understand implicitly, as manySo how do they tell whether a program is hanging, or is waiting for input?
commands will read from stdin if no filename is specified.
FFS would it hurt to print a message showing what is expected?
It is exasperating that people defend such poor UIs.
bart <bc@freeuk.com> writes:[...]
On 17/09/2026 23:06, Keith Thompson wrote:
But if you have two versions A and B, and both their paths are listed in >>the PATH variable, then when B's gcc tries to run cc1.exe, it will be
A's version, as A's path is listed first.
It's the> responsibility of the gcc+FOO and gcc+BAR installers to arrange >>> for their respecive gcc's to avoid conflicting with each other.
Packaging gcc for Windows is more difficult than packaging gcc
for Unix-like systems.
It's not hard; it should really have used a path relative to B's gcc.exe.
It would still pick A's gcc.exe if typing an unqualified 'gcc' by
itself, but how does Linux solve this problem when you have two gcc's to >>choose from?
One can use modules:
$ module use --append /nfs/Software/module/my-common/modulefiles[...]
$ module load gcc/11.3
On 18/09/2026 15:03, bart wrote:
different ways, written by completely separate groups of people.˙ The
fact that they have different defaults is hardly surprising - a compiler will rarely be used with piped input from outside, whereas for "as",
that is by far the most common mode of operation.
- Given two files, gcc compiles them independently; as assembles them
˙˙ after effectively combining them (imagine if gcc concatenated all the
˙˙ .c files you give it; it would be ludicrous).
They are different kinds of programs, doing different things.˙ Assembly files can reasonably be concatenated, C files cannot.
"gcc" is a driver
program, not a C compiler - it also deals with lots of different file
types.
˙ (I did not know that "as" combines
multiple assembly files as you describe.˙ But it is not a driver program
- it simply takes its input, and assembles it.)
to work.˙ But we have already established that your opinions on such
matters do not often match those of many others.
I mean, is it unreasonable to expect '-shared' on Windows to result in
a file ending with .dll rather than .exe?
As I understand it, the format for dll and exe files is the same on
Windows (as is the format for various other files), and both can contain directly executable code and resources that can be used by other
programs.
Still, it is unreasonable to expect people to specify the name they want
for a program or shared library?
˙ It is normal for a program (or shared
library) to consist of multiple files - I think it would be highly
unusual to want to turn a single "x.c" file into a dll "x.dll".
I am sure that it makes sense that "gcc -shared x.c" could generate
"x.dll" on Windows.˙ I am far from sure that failing to use "x.dll" as
the default name is a bother to anyone else.˙ Other than a quick test of
how gcc works, it's hard to imagine a use-case.
And of course, remember that gcc (and as) are native to an OS where the
type of a file is determined by the file, not by part of its name.
I mean, you do 'gcc prog1.c', wait some time for it to produce
'a.exe'. Now you do 'gcc prog2.c', and it promptly overwrites the
'a.exe' from the last compile! That is quite laughable.
So don't do that.
If you don't like the way gcc (or any other tools) work, and you feel
that your own tools are better for your uses, then use your own tools.
Or if you feel that you /have/ to use gcc, and that you can't cope with writing all these nasty, awkward switches and arguments, and think that build tools are just crutches for those that don't want to spend all day doing manual project management, then write a batch file:
gcc-dll.bat :
@echo off
gcc -shared -s %1.c -o %1.dll
gcc-exe.bat :
@echo off
gcc %1.c -o %1.exe
There.
After decades of gnashing your teeth and pulling out your hair,
I've given you the solution.˙ I can't imagine you will use it, but there
it is.
bart <bc@freeuk.com> writes:
On 18/09/2026 16:24, Scott Lurndal wrote:[...]
Those familiar with unix would understand implicitly, as manySo how do they tell whether a program is hanging, or is waiting for input?
commands will read from stdin if no filename is specified.
By typing Control-D.
FFS would it hurt to print a message showing what is expected?
Yes, it would. I won't offer an explanation because you would not care
about it or admit that you understand it.
But if either seriously expect source code to be entered 'live', then
they should show a prompt; how hard would that be?
On 18/09/2026 19:29, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
On 18/09/2026 16:24, Scott Lurndal wrote:[...]
Those familiar with unix would understand implicitly, as manySo how do they tell whether a program is hanging, or is waiting for input? >> By typing Control-D.
commands will read from stdin if no filename is specified.
How would they know without a message?
But suppose they did that, what happens, the program stops? What if it
was just busy; wouldn't Ctrl-D screw it up?
FFS would it hurt to print a message showing what is expected?Yes, it would. I won't offer an explanation because you would not
care about it or admit that you understand it.
Try me.
(In my last post I showed an example of my C compiler taking input
from stdin (requested, not as default!) and it displays a message. The
world is still turning.
On 2026-09-09 10:38, David Brown wrote:
On 09/09/2026 10:13, Janis Papanagnou wrote:
On 2026-09-08 13:47, bart wrote:
On 08/09/2026 01:02, Waldek Hebisch wrote:
[...]
[...]
Still, modern languages tend to have a module scheme, suggesting
the 'flexible' C approach (I'd use the term 'prehistoric') wasn't
quite enough.
A necessary consequence of the growing systems and software
architectures. But even some legacy languages had already
modularization concepts back then! So it's not an excuse to
provide only a primitive #include mechanism. But I wouldn't
be so critical given the time when "C" had been designed.
You should take into account C's design-principles and also
when it came out and sort them in, in comparison to other
language schools; compare (for example) the release dates
of Pascal -> Modula (and what these two provided here).
AFAIK, Pascal originally did not have any kind of "unit" system (its
module equivalent) - you used textual inclusion files. But you then
compiled everything as one big Pascal file rather than having
separate compilation. (This may have varied between Pascal
implementations.)
Yes, exactly. - Original Pascal didn't have anything, then came "C"
timely - providing something that Pascal didn't have! - and Wirth's
next language Modula then had a concept.
On Fri, 18 Sep 2026 15:28:21 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Michael S <already5chosen@yahoo.com> writes:
On Thu, 17 Sep 2026 17:50:57 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
bart <bc@freeuk.com> writes:
On 18/09/2026 01:04, Steven G. Kargl wrote:[...]
Most people read (or at least skim) the documentation
that comes with the software they use.
Most people probably don't. They will try running such programs
without input, as often that gives usage info.
[...]
You've seen how that approach fails.
There are valid reasons for the way "as" behaves.
Well, if you consider compatibility with weird notion of "user
interface" of its original creator as a valid reason, then yes.
Even I accept it as valid.
Which does not make it less bad in the absolute sense.
Desire to give to user an option to accept an input from standard
input by itself is not unreasonable, bit it should be an option
rather than default.
That's your opinion. That's not the unix philosophy. Many
unix commands default to stdin if no file name is specified
(specifically to support streaming the output of one command
to the input of another).
There is big difference between utilities like grep or sort and
something like as. Blindly treating them as the same is wrong.
David Brown <david.brown@hesbynett.no> writes:
[...]
Were I writing a new assembler for Linux, I would probably not make it
work as a pipe by default - and require a dash or two, or another
command-line option. Running "my-new-assembler" with no options or
files would exit immediately, perhaps with a "no input files" error or
perhaps with a "use --help for help" message. (Or perhaps with no
output at all, which I think would also be a reasonable choice.) So
while I think "act as a pipe" is a reasonable choice for "as" with no
input files, I think there are other choices that are at least
somewhat better.
If your new assembler were intended to be a drop-in replacement for
"as", are certain that this behavior would not break existing tools?
How sure are you that gcc, or clang, or some other tool, doesn't send
input to the assembler in a pipe? And why shouldn't they do so?
bart <bc@freeuk.com> writes:
[...]
But if either seriously expect source code to be entered 'live', then
they should show a prompt; how hard would that be?
There is no serious expectation that "as" will be read its input
from a keyboard.
You are complaining about things you clearly do
not understand and do not want to understand.
On 18/09/2026 19:29, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
On 18/09/2026 16:24, Scott Lurndal wrote:[...]
By typing Control-D.Those familiar with unix would understand implicitly, as manySo how do they tell whether a program is hanging, or is waiting for input? >>
commands will read from stdin if no filename is specified.
How would they know without a message?
On Fri, 18 Sep 2026 20:14:29 +0100, bart wrote:In the case of 'as', that is 2,500 lines of text.
On 18/09/2026 19:29, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
On 18/09/2026 16:24, Scott Lurndal wrote:[...]
By typing Control-D.Those familiar with unix would understand implicitly, as manySo how do they tell whether a program is hanging, or is waiting for input? >>>
commands will read from stdin if no filename is specified.
How would they know without a message?
<Rinse>
By reading the friendly documentation that comes with the tool.
Look, just admit these ancient applications have a shitty interface[...]
that no one has been able to improve or hasn't been allowed to.
Why pretend that how they work is actually desirable?
On 19/09/2026 01:19, Steven G. Kargl wrote:
On Fri, 18 Sep 2026 20:14:29 +0100, bart wrote:In the case of 'as', that is 2,500 lines of text.
On 18/09/2026 19:29, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
On 18/09/2026 16:24, Scott Lurndal wrote:[...]
Those familiar with unix would understand implicitly, as manySo how do they tell whether a program is hanging, or is waiting for input?
commands will read from stdin if no filename is specified.
By typing Control-D.
How would they know without a message?
<Rinse>
By reading the friendly documentation that comes with the tool.
On 18/09/2026 09:10, Janis Papanagnou wrote:
On 2026-09-15 12:53, David Brown wrote:
On 15/09/2026 11:51, Janis Papanagnou wrote:[...]
And we all know we should be writing "if (a == 5)", with decent
spacing :-)
Sure. Above was just a deliberate terse form for inline reference.
Usually I'm using probably more spacing inline and between lines
and chapters than the average programmer would find tolerable. ;-)
I like space - it aids legibility.˙ There's a reason the biggest key on
the keyboard is the spacebar, and the second biggest is the return key.
Yes, things have gotten much better since the dates back then when
I did my professional programming in C/C++.
Tools have certainly got better, but the default warnings in compilers progress much too slowly IMHO.˙ (Of course I can enable all the warning flags I like for my own use - but I'd prefer if everyone else used them more!)
You might be astonished but I don't recall to have needed any explicit
warnings setting; our policy was a zero-warning approach (by the default
warnings of our compilers), and where we identified any needs beyond we
communicated with the build-management to make it the company default.
Having good programmers, providing trainings and courses, helped also.
If the default warnings for your compiler matched something like "-Wall"
in gcc, then that could be a good starting point.
I don't know what compiler(s) you used,
but for many IME the default warnings are pretty
feeble.˙ But it can certainly be impractical to insist on a specific
list of different warning options, especially when a project includes third-party code that might have different conventions.
David Brown <david.brown@hesbynett.no> writes:
On 18/09/2026 03:04, bart wrote:
On 17/09/2026 23:06, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
On 17/09/2026 08:24, tTh wrote:
On 9/17/26 02:49, bart wrote:
And I've no idea where gcc would look for its headers, other than >>>>>>> where it keeps its system headers, or how to set it up to look˙ ˙˙ You just have to read the fscking manual.
permanently in certain places.
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
Nobody uses environment variables any more.
Obviously untrue.
Let's say they're out of fashion.
Let's not. Lots of people use them for various purposes.
Indeed, they're ubiquitous. Cf. $PATH, $HOME, $LANG (and $LC_*), $TERM
are used extensively.
On 18/09/2026 17:34, Michael S wrote:[...]
On Fri, 18 Sep 2026 15:28:21 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
[snip]
By convention a single dash character may be specified
in place of a filename to specify stdin.
The latter is reasonable. What as does is not.
From the manual page of "as" :
The primary use of "as" is for assembling the output of "gcc".˙ I think
it would have been fine if "as" had required one or two dashes, or
another option, to indicated using stdin as the input - but I don't see
it as unreasonable that by default it works according to the stated
primary use of the program.
A common way to handle assembly files on Linux is to use "gcc file.s",
with whatever additional options you want, not "as file.s", just as it
is common to use "gcc" for linking rather than running "ld" directly.
Were I writing a new assembler for Linux, I would probably not make it
work as a pipe by default - and require a dash or two, or another command-line option.˙ Running "my-new-assembler" with no options or
files would exit immediately, perhaps with a "no input files" error or perhaps with a "use --help for help" message.˙ (Or perhaps with no
output at all, which I think would also be a reasonable choice.)˙ So
while I think "act as a pipe" is a reasonable choice for "as" with no
input files, I think there are other choices that are at least somewhat better.
However, where is any of this actually likely to cause an issue in the
real world?˙ No one would expect "as" to do anything useful without any input, or an option like "--version" or "--help".˙ The only people
likely to be confused are those who have no idea what the program is,
and try to figure it out by typing "as".˙ The flaw, IMHO, is not that
"as" works as a pipe by default, but its name is too short and generic. "gas" or "gasm" would have been better.
[...]
bart <bc@freeuk.com> writes:
On 18/09/2026 01:04, Steven G. Kargl wrote:
On Thu, 17 Sep 2026 20:54:35 +0100, bart wrote:
Most command-line compilers give you version and help info when no
parameters follow. But at least it says something; try this:
c:\c\as
and it apparently hangs (it's waiting for you type an assembly program >>>> from the console!)
Most people read (or at least skim) the documentation
that comes with the software they use.
Most people probably don't. They will try running such programs without
input, as often that gives usage info.
Please try to speak for yourself.
Those familiar with unix would understand implicitly, as many
commands will read from stdin if no filename is specified.
[...]
On Sat, 19 Sep 2026 02:06:09 +0100, bart wrote:
[...]
Again, why would you use a tool without actually learn how
the tool works?
On Sat, 19 Sep 2026 02:06:09 +0100, bart wrote:
By reading the friendly documentation that comes with the tool.In the case of 'as', that is 2,500 lines of text.
The info is in the 5th paragraph of the Description section.
This is the 20 and 21st lines of material that you has a user
should have at least skimmed. The first two sections are
simply an abbreviated enumeration of options and supported
targets.
Again, why would you use a tool without actually learn how
the tool works?
On 2026-09-19 05:26, Steven G. Kargl wrote:Regarding assemblers, usually that is the very least of the problems
On Sat, 19 Sep 2026 02:06:09 +0100, bart wrote:
[...]
Again, why would you use a tool without actually learn how
the tool works?
Inherent (and incurable) mental inabilities?
On 2026-09-18 11:37, David Brown wrote:
On 18/09/2026 09:10, Janis Papanagnou wrote:
On 2026-09-15 12:53, David Brown wrote:
On 15/09/2026 11:51, Janis Papanagnou wrote:[...]
And we all know we should be writing "if (a == 5)", with decent
spacing :-)
Sure. Above was just a deliberate terse form for inline reference.
Usually I'm using probably more spacing inline and between lines
and chapters than the average programmer would find tolerable. ;-)
I like space - it aids legibility.˙ There's a reason the biggest key
on the keyboard is the spacebar, and the second biggest is the return
key.
And the third biggest the Backspace key to quickly erase all this
ugly code we wrote? ;-)
Yes, things have gotten much better since the dates back then when
I did my professional programming in C/C++.
Tools have certainly got better, but the default warnings in compilers
progress much too slowly IMHO.˙ (Of course I can enable all the
warning flags I like for my own use - but I'd prefer if everyone else
used them more!)
Well, I cannot really tell about the more recent behaviors. All I
noticed was that I've got (or could enable) more diagnostics than
in earlier days, and that the information got better (in content
and in display representation) - it would certainly be bad if it
were otherwise.
David Brown <david.brown@hesbynett.no> writes:
[...]
Were I writing a new assembler for Linux, I would probably not make it
work as a pipe by default - and require a dash or two, or another
command-line option. Running "my-new-assembler" with no options or
files would exit immediately, perhaps with a "no input files" error or
perhaps with a "use --help for help" message. (Or perhaps with no
output at all, which I think would also be a reasonable choice.) So
while I think "act as a pipe" is a reasonable choice for "as" with no
input files, I think there are other choices that are at least
somewhat better.
If your new assembler were intended to be a drop-in replacement for
"as", are certain that this behavior would not break existing tools?
How sure are you that gcc, or clang, or some other tool, doesn't send
input to the assembler in a pipe? And why shouldn't they do so?
In any case, it's quite possible to invoke some of these inadvertently
by mistyping. Oh, I forgot, you are a perfect typist too!
On 18/09/2026 20:26, Keith Thompson wrote:
David Brown <david.brown@hesbynett.no> writes:
[...]
Were I writing a new assembler for Linux, I would probably not make it
work as a pipe by default - and require a dash or two, or another
command-line option.˙ Running "my-new-assembler" with no options or
files would exit immediately, perhaps with a "no input files" error or
perhaps with a "use --help for help" message.˙ (Or perhaps with no
output at all, which I think would also be a reasonable choice.)˙ So
while I think "act as a pipe" is a reasonable choice for "as" with no
input files, I think there are other choices that are at least
somewhat better.
If your new assembler were intended to be a drop-in replacement for
"as", are certain that this behavior would not break existing tools?
No.˙ I had not said my hypothetical new assembler would be a drop-in replacement for "as" - if it were, then obviously I'd follow the
behaviour of "as" here.˙ It is unlikely that there is much to be gained
in replacing "as" directly - it does all that is needed for a companion
to a compiler.˙ The only point, I would say, of writing a new assembler
for Linux would be for additional features or capabilities.˙ (Or it
could be done for fun!)
How sure are you that gcc, or clang, or some other tool, doesn't send
input to the assembler in a pipe?˙ And why shouldn't they do so?
gcc certainly sends its output to as using a pipe if you specify the "- pipe" option.˙ Otherwise, it uses temporary files (on Linux, this is
pretty much the same efficiency as the temporary files are normally
never actually saved to the filesystem.˙ Maybe Bart could tell us if
giving gcc the "-pipe" option affects the speed on his Windows gcc toolchain).
Are you really interested in learning something? Your history here does
not suggest that, but if you've changed your mind about that, I'm
willing to try to explain it. (Though I'm not sure I can explain
anything that hasn't already been explained in this thread.)
(In my last post I showed an example of my C compiler taking input
from stdin (requested, not as default!) and it displays a message. The
world is still turning.
Some programs read input from stdin if they don't receive any file name arguments. Others do not. Both approaches are valid. Apparently your
C compiler is an example of the latter.
One particular program, "as", can read its input from stdin. Have you somehow inferred from that that we all think your compiler should do the same?
in most cases i think it may be understood but sometimes if i read my
post some words i dont understand
this is becouse of unfortunate typos, but i write a big amounts of
posts and if iwould carefully read it all before osting i couldnt focus
(so its eventually better to write is as a stream of thought and then
post errata to it)
On 19/09/2026 01:19, Steven G. Kargl wrote:
On Fri, 18 Sep 2026 20:14:29 +0100, bart wrote:
bart <bc@freeuk.com> writes:
On 19/09/2026 01:19, Steven G. Kargl wrote:
On Fri, 18 Sep 2026 20:14:29 +0100, bart wrote:
<snip> a bunch of irrelevent text that boils down to a single acronym:
RTFM
On 2026-09-18, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
Are you really interested in learning something? Your history here does
not suggest that, but if you've changed your mind about that, I'm
willing to try to explain it. (Though I'm not sure I can explain
anything that hasn't already been explained in this thread.)
(In my last post I showed an example of my C compiler taking input
from stdin (requested, not as default!) and it displays a message. The
world is still turning.
Some programs read input from stdin if they don't receive any file name
arguments. Others do not. Both approaches are valid. Apparently your
C compiler is an example of the latter.
One particular program, "as", can read its input from stdin. Have you
somehow inferred from that that we all think your compiler should do the
same?
Some fish have spent their lives living in a very small pool and know it
very well, and then they go for a trip in the sea and it is very
frightening! It contains environments and objects that they have no comprehension off, and if the fish is old and set in his or her ways
the wider world will always be a mystery!
On 18/09/2026 16:24, David Brown wrote:
On 18/09/2026 15:03, bart wrote:
˙So "gcc" and "as" are wildly different tools that are used in wildly
different ways, written by completely separate groups of people.˙ The
fact that they have different defaults is hardly surprising - a
compiler will rarely be used with piped input from outside, whereas
for "as", that is by far the most common mode of operation.
Actually, gcc on Windows seems to generate temporary .s files that are submitted to 'as'. Piping isn't used.
Both gcc and 'as' take inputs which are one or more files (sequences of bytes) and write outputs that are one or more files.
You probably can't get any simpler than that in a computer program.
Neither of them are really intended for interactive use either: that is, interaction while they run, beyond invoking them.
But if either seriously expect source code to be entered 'live', then
they should show a prompt; how hard would that be?
- Given two files, gcc compiles them independently; as assembles them
˙˙ after effectively combining them (imagine if gcc concatenated all the >>> ˙˙ .c files you give it; it would be ludicrous).
They are different kinds of programs, doing different things.
Assembly files can reasonably be concatenated, C files cannot.
That is nonsense. ASM can contain local, non-exported symbols just like HLLs. For example two people might be writing two ASM files and they shouldn't need to ensure that their choices of labels do not clash.
"gcc" is a driver program, not a C compiler - it also deals with lots
of different file types.
So what's the name of the actual C compiler then, cc1.exe? That doesn't appear usable by itself:
So what's the name of the assembler proper? It seems everything comes
under the 'gcc' umbrella, out of necessity rather than convenience,
since the different components - cc1, as, ld - are pretty much unusable
by themselves.
to work.˙ But we have already established that your opinions on such
matters do not often match those of many others.
OK. For some irrational reason, you are defending some behaviours
determined decades ago, which were clearly wrong, ludicrous, unsafe, or inconsistent.
You know, it would cost you nothing to say, Bart, you're right. But for historical and other reasons we're stuck with them and need to make the
best of a bad job.
I mean, is it unreasonable to expect '-shared' on Windows to result
in a file ending with .dll rather than .exe?
As I understand it, the format for dll and exe files is the same on
Windows (as is the format for various other files), and both can
contain directly executable code and resources that can be used by
other programs.
They have the same format, but files used as DLLs have extra stuff:
˙ * Base relocation tables
˙ * Must have relocatable code
˙ * I think there is an extra segment
˙ * An export table
˙ * Different flags are set in the header
The .dll extension is normally used for these. Experiments trying to
load a DLL via LoadLibrary (ie. dlopen on Linux) suggest that an
extension other than .dll would be troublesome.
LoadLibrary Arg˙˙˙˙ lib.dll˙˙˙˙˙ lib.exe (actual name of DLL)
"lib"˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ Yes˙˙˙˙˙˙˙˙ No
"lib.dll"˙˙˙˙˙˙˙˙˙˙˙ Yes˙˙˙˙˙˙˙˙ No
"lib.exe"˙˙˙˙˙˙˙˙˙˙˙ No˙˙˙˙˙˙˙˙˙ Yes
So it makes sense to use "lib" or "lib.dll" as the argument, and for
DLLs to use ".dll".
In any case, using .exe for DLLs would be confusing.
Still, it is unreasonable to expect people to specify the name they
want for a program or shared library?
I was mildly surprised that gcc on Windows allows "-o prog" and gcc will generate the file "prog.exe" without needing the extension.
This could reasonably lead people to think that with "-shared", it would write a .dll file. They would be wrong.
˙ It is normal for a program (or shared library) to consist of
multiple files - I think it would be highly unusual to want to turn a
single "x.c" file into a dll "x.dll".
C compilers that don't follow gcc (clang follows gcc, and tcc follows it
on Linux only), tend to take the name of the first submitted C file as
the default name of the output, when there is one output.
(-c -S options generate multiple files.)
I am sure that it makes sense that "gcc -shared x.c" could generate
"x.dll" on Windows.˙ I am far from sure that failing to use "x.dll" as
the default name is a bother to anyone else.˙ Other than a quick test
of how gcc works, it's hard to imagine a use-case.
It's just wrong. A million people will use gcc and some of those will encounter some issue like this which at best wastes their time.
And of course, remember that gcc (and as) are native to an OS where
the type of a file is determined by the file, not by part of its name.
Fine. In that case don't bother with the extension if the extension is a lie.
But for DLLs, the extensions is important to make it visible, and there
will of course be further checks that are done.
I mean, you do 'gcc prog1.c', wait some time for it to produce
'a.exe'. Now you do 'gcc prog2.c', and it promptly overwrites the
'a.exe' from the last compile! That is quite laughable.
So don't do that.
Something else which is just plain wrong, and can waste a lot of time.
When you have to do twice the work of specifying an input, or you may
have to repeat a lengthy compile if you need to run an earlier, now overwritten, a.exe again.
If you don't like the way gcc (or any other tools) work, and you feel
that your own tools are better for your uses, then use your own tools.
That's exactly what I do. But gcc came up in this thread.
Or if you feel that you /have/ to use gcc, and that you can't cope
with writing all these nasty, awkward switches and arguments, and
think that build tools are just crutches for those that don't want to
spend all day doing manual project management, then write a batch file:
gcc-dll.bat :
@echo off
gcc -shared -s %1.c -o %1.dll
gcc-exe.bat :
@echo off
gcc %1.c -o %1.exe
There.
I do that too. It is a small C program called gc used like this:
˙ gc prog
˙ gc prog opt
It generates prog.exe and also adds the long-winded options needed for
my generated C code.
But it's not flexible enough for ad hoc needs. Then I have to use gcc
and it's a nuisance because of its quirks.
After decades of gnashing your teeth and pulling out your hair, I've
given you the solution.˙ I can't imagine you will use it, but there it
is.
It's a workaround. gcc is what, 85,000 source files, but I still have to write scripts to make it usable?!
On 19/09/2026 12:10, David Brown wrote:
On 18/09/2026 20:26, Keith Thompson wrote:
David Brown <david.brown@hesbynett.no> writes:
[...]
Were I writing a new assembler for Linux, I would probably not make it >>>> work as a pipe by default - and require a dash or two, or another
command-line option.˙ Running "my-new-assembler" with no options or
files would exit immediately, perhaps with a "no input files" error or >>>> perhaps with a "use --help for help" message.˙ (Or perhaps with no
output at all, which I think would also be a reasonable choice.)˙ So
while I think "act as a pipe" is a reasonable choice for "as" with no
input files, I think there are other choices that are at least
somewhat better.
If your new assembler were intended to be a drop-in replacement for
"as", are certain that this behavior would not break existing tools?
No.˙ I had not said my hypothetical new assembler would be a drop-in
replacement for "as" - if it were, then obviously I'd follow the
behaviour of "as" here.˙ It is unlikely that there is much to be
gained in replacing "as" directly - it does all that is needed for a
companion to a compiler.˙ The only point, I would say, of writing a
new assembler for Linux would be for additional features or
capabilities.˙ (Or it could be done for fun!)
How sure are you that gcc, or clang, or some other tool, doesn't send
input to the assembler in a pipe?˙ And why shouldn't they do so?
gcc certainly sends its output to as using a pipe if you specify the
"- pipe" option.˙ Otherwise, it uses temporary files (on Linux, this
is pretty much the same efficiency as the temporary files are normally
never actually saved to the filesystem.˙ Maybe Bart could tell us if
giving gcc the "-pipe" option affects the speed on his Windows gcc
toolchain).
For building sql.c, then using -pipe consistently gave compile-times of around 7.25 seconds vs 7.5 or so without it. About 4% faster, but this
at -O0.
Using -O3, then it was 50.1 seconds vs 52.5 seconds (tested once only).
I expected the difference to be still around 0.25 seconds (the EXE sizes won't be that different), but then I also forgot to do -s.
On 18/09/2026 17:34, Michael S wrote:
On Fri, 18 Sep 2026 15:28:21 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Michael S <already5chosen@yahoo.com> writes:
On Thu, 17 Sep 2026 17:50:57 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
bart <bc@freeuk.com> writes:
On 18/09/2026 01:04, Steven G. Kargl wrote:[...]
Most people read (or at least skim) the documentation
that comes with the software they use.
Most people probably don't. They will try running such programs
without input, as often that gives usage info.
[...]
You've seen how that approach fails.
There are valid reasons for the way "as" behaves.
Well, if you consider compatibility with weird notion of "user
interface" of its original creator as a valid reason, then yes.
Even I accept it as valid.
Which does not make it less bad in the absolute sense.
Desire to give to user an option to accept an input from standard
input by itself is not unreasonable, bit it should be an option
rather than default.
That's your opinion. That's not the unix philosophy. Many
unix commands default to stdin if no file name is specified
(specifically to support streaming the output of one command
to the input of another).
There is big difference between utilities like grep or sort and
something like as. Blindly treating them as the same is wrong.
By convention a single dash character may be specified
in place of a filename to specify stdin.
The latter is reasonable. What as does is not.
From the manual page of "as" :
"""
as is primarily intended to assemble the output of the GNU C compiler
"gcc" for use by the linker "ld". Nevertheless, we've tried to make
as assemble correctly everything that other assemblers for the same
machine would assemble. Any exceptions are documented explicitly.
This doesn't mean as always uses the same syntax as another assembler
for the same architecture; for example, we know of several
incompatible versions of 680x0 assembly language syntax.
Each time you run as it assembles exactly one source program. The
source program is made up of one or more files. (The standard input
is also a file.)
You give as a command line that has zero or more input file names.
The input files are read (from left file name to right). A
command-line argument (in any position) that has no special meaning
is taken to be an input file name.
If you give as no file names it attempts to read one input file from
the as standard input, which is normally your terminal. You may have
to type ctl-D to tell as there is no more program to assemble.
Use -- if you need to explicitly name the standard input file in your command line.
"""
The primary use of "as" is for assembling the output of "gcc". I
think it would have been fine if "as" had required one or two dashes,
or another option, to indicated using stdin as the input - but I
don't see it as unreasonable that by default it works according to
the stated primary use of the program.
A common way to handle assembly files on Linux is to use "gcc
file.s", with whatever additional options you want, not "as file.s",
just as it is common to use "gcc" for linking rather than running
"ld" directly.
Were I writing a new assembler for Linux, I would probably not make
it work as a pipe by default - and require a dash or two, or another command-line option. Running "my-new-assembler" with no options or
files would exit immediately, perhaps with a "no input files" error
or perhaps with a "use --help for help" message. (Or perhaps with no
output at all, which I think would also be a reasonable choice.) So
while I think "act as a pipe" is a reasonable choice for "as" with no
input files, I think there are other choices that are at least
somewhat better.
However, where is any of this actually likely to cause an issue in
the real world? No one would expect "as" to do anything useful
without any input, or an option like "--version" or "--help". The
only people likely to be confused are those who have no idea what the
program is, and try to figure it out by typing "as".
The flaw, IMHO,
is not that "as" works as a pipe by default, but its name is too
short and generic. "gas" or "gasm" would have been better.
On the other hand, I have a number of times run a "grep" command and wondered why it was taking so long - because I'd forgotten to give it
the files to search! (That's my fault, not grep's.)
Michael S <already5chosen@yahoo.com> writes:
On Fri, 18 Sep 2026 12:55:11 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
In article <118i2mc$q9l1$1@dont-email.me>, bart <bc@freeuk.com>
wrote:
On 17/09/2026 23:06, Keith Thompson wrote: =20=20
bart <bc@freeuk.com> writes: =20
On 17/09/2026 08:24, tTh wrote: =20=20
On 9/17/26 02:49, bart wrote: =20
And I've no idea where gcc would look for its headers, other=C2=A0=C2=A0 You just have to read the fscking manual.
than where it keeps its system headers, or how to set it up
to look permanently in certain places. =20
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
=20
Nobody uses environment variables any more. =20
Obviously untrue. =20
Let's say they're out of fashion. =20
Why would you say such a thing? While they may not be the most
elegant solution to a number of problems, they're very much in
use, and "in fashion", at least on Unix-derived systems.
=20
- Dan C.
=20
Would you design a new program which behavior can be modified by >environment variables? I don't mean standard environment variables,
like locale (although that is also less than great) but environment >variables specific to your program?
Absolutely.
And they would be well documented in the manual page for the program.
LD_DEBUG, for example, is quite useful in certain usage cases and
effectively impossible to handle with a command line option flag.
On the other hand, I have a number of times run a "grep" command and wondered why it was taking so long - because I'd forgotten to give it
the files to search! (That's my fault, not grep's.)
On 18/09/2026 21:07, bart wrote:
On 18/09/2026 16:24, David Brown wrote:
On 18/09/2026 15:03, bart wrote:
˙˙So "gcc" and "as" are wildly different tools that are used in wildly
different ways, written by completely separate groups of people.˙ The
fact that they have different defaults is hardly surprising - a
compiler will rarely be used with piped input from outside, whereas
for "as", that is by far the most common mode of operation.
Actually, gcc on Windows seems to generate temporary .s files that are
submitted to 'as'. Piping isn't used.
Piping is an option that is used on some systems, and not on others, and
it can be enabled with "gcc -pipe".˙ Whether you are using a pipe or a temporary file, the prime use of "as" is not as a program run by a user,
but as a program run by "gcc".
Both gcc and 'as' take inputs which are one or more files (sequences
of bytes) and write outputs that are one or more files.
You probably can't get any simpler than that in a computer program.
So now gcc is a simple program?
But if either seriously expect source code to be entered 'live', then
they should show a prompt; how hard would that be?
That's a meaningless question, as the pre-condition is clearly false.
I accept that it is fine for a program to print a quick help message
when run with incomplete or incorrect arguments.˙ But it is also fine
for it to give an error message.˙ And for some programs, it can be appropriate to show nothing when given no arguments, or to wait for
input from stdin.˙ All options are reasonable for some kinds of
programs.˙ In some programs you wrote, you picked one method, in some programs other people have written, they picked a different solution.
Your personal opinions do not form the requirements for all the world's software.
So let me be more nuanced - /sometimes/ it is reasonable to concatenate assembly files, and assembly files may be written with that in mind.˙ It
is almost never reasonable to concatenate C source files.
For an assembler designed with direct use as a primary aim, you could reasonably pick a different handling of multiple source files - maybe
they would be assembled independently to generate multiple object files,
or maybe they would be rejected as invalid use of the assembler (with a nice, friendly help message if you don't like error messages).
˙ For an
assembler designed primarily to be called from a compiler driver
program,
None of us here wrote any of the tools under discussion.
There are reasonable uses of files as both executables and libraries.
Very often in my Python coding, I will have a Python file that is
intended for use as a "library" (i.e., to be imported from other
modules, scripts or Python shells) but which can also be run directly
for test purposes or as simple command-line programs.
˙ For large enough
programs, it is normal to separate the dll's from the exe's, but
combining them in one file would surely suit your preference for minimum number of files.
This could reasonably lead people to think that with "-shared", it
would write a .dll file. They would be wrong.
So they have to learn how to use their tools.
C compilers that don't follow gcc (clang follows gcc, and tcc follows
it on Linux only), tend to take the name of the first submitted C file
as the default name of the output, when there is one output.
That seems reasonable for compilation - compiling "file.c" to "file.o".
gcc does that - "gcc -c file.c" produces "file.o".
Generating an exe file, or a shared library, is very likely to involveNaming it after the first or only file is a more reasonable default than a.out. Since this sequence:
more than one file.˙ Naming the output after one file is therefore not helpful.˙ Naming it "a.out" is not particularly helpful either, but
that's the tradition.
Something else which is just plain wrong, and can waste a lot of time.
When you have to do twice the work of specifying an input, or you may
have to repeat a lengthy compile if you need to run an earlier, now
overwritten, a.exe again.
Again, when you see this as an issue, it is because you are doing things wrong.
Remember, you are not doing software development here, or doing any programming.˙ You are not writing code and producing executables or libraries.
Now, I realise that the way I use my tools and the setups I have is not necessarily typical of anyone else.˙ But a quick check of the command
line used for each individual compile in my current project shows 111 arguments ( over about 2300 characters.˙ That includes all the include directory flags (blame idiot microcontroller manufacturer SDKs for their necessity, not me or gcc),
optimisation flags, a dozen flags for details of the exact target
processor features, lots and lots of warning flags, and one argument specifying the output file name and directory.˙ For the linking call to
gcc - the one you are most upset about - there are about 760 arguments
over 60,000 characters due to the 729 object file names and their directories.
˙ (These are all automatically generated by my makefiles.)
That's a /real/ project for a /real/ program.
˙ Do you honestly think
that having a better (IYHO) default choice of output filename would make
a difference?
On Fri, 18 Sep 2026 18:08:38 +0200
David Brown <david.brown@hesbynett.no> wrote:
On 18/09/2026 17:34, Michael S wrote:
On Fri, 18 Sep 2026 15:28:21 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Michael S <already5chosen@yahoo.com> writes:
On Thu, 17 Sep 2026 17:50:57 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
bart <bc@freeuk.com> writes:
On 18/09/2026 01:04, Steven G. Kargl wrote:[...]
Most people read (or at least skim) the documentation
that comes with the software they use.
Most people probably don't. They will try running such programs
without input, as often that gives usage info.
[...]
You've seen how that approach fails.
There are valid reasons for the way "as" behaves.
Well, if you consider compatibility with weird notion of "user
interface" of its original creator as a valid reason, then yes.
Even I accept it as valid.
Which does not make it less bad in the absolute sense.
Desire to give to user an option to accept an input from standard
input by itself is not unreasonable, bit it should be an option
rather than default.
That's your opinion. That's not the unix philosophy. Many
unix commands default to stdin if no file name is specified
(specifically to support streaming the output of one command
to the input of another).
There is big difference between utilities like grep or sort and
something like as. Blindly treating them as the same is wrong.
By convention a single dash character may be specified
in place of a filename to specify stdin.
The latter is reasonable. What as does is not.
From the manual page of "as" :
"""
as is primarily intended to assemble the output of the GNU C compiler
"gcc" for use by the linker "ld". Nevertheless, we've tried to make
as assemble correctly everything that other assemblers for the same
machine would assemble. Any exceptions are documented explicitly.
This doesn't mean as always uses the same syntax as another assembler
for the same architecture; for example, we know of several
incompatible versions of 680x0 assembly language syntax.
I don't know when this paragraph was written.
Today's gnu as is pretty reasonable tool for assembler develpment.
Decent macro capabilities etc... Likely, not on par with
macro-assemblers of IBM mainframes or of VAX/VMS, but rather similar in capabilities to Microsoft's Masm or with nasm.
Certainly it is far more complete tool than what would be neeaded to
process gcc output into objects.
On the other hand, I have a number of times run a "grep" command and
wondered why it was taking so long - because I'd forgotten to give it
the files to search! (That's my fault, not grep's.)
If grep required additional option for acception of input from stadard
input that would be [mildly] annoying.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 8 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 14:42:48 |
| Calls: | 220 |
| Files: | 21,513 |
| Messages: | 83,058 |
