Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2023-12-31, Bart <bc@freeuk.cm> wrote:
[...]
>> How do you get it to look inside header files, or do those have to be
>> submitted manually?
>
> ctags -R will process a tree recursively, including any C header files.
> However, things that are only declared and not defined in header files,
> like function declarations, are not indexed.

The exuberant-ctags version I have on Ubuntu and Cygwin doesn't seem to
have an option to process a tree recursively, or to deal with
directories at all. (I find that a little surprising; it would be
useful functionality.) The -R option is documented as follows:

-R, --no-regex
Don't do any more regexp matching on the following files. May
be freely intermixed with filenames and the --regex option.

I haven't used ctags a lot, but I think that something like:
ctags **/*.[ch]
if your shell supports the "**" recursive wildcard, or:
find . -type f -name '*.[ch]' | xargs ctags -a
where "-a" tells it to append to the tags file.

If in doubt, consult the documentation for the version of ctags you're
using.

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

On 12/31/2023 3:46 PM, Lawrence D'Oliveiro wrote:
> On Sun, 31 Dec 2023 02:18:25 +0000, Bart wrote:
>
>> This somes my experience of software originating in Linux. This is why
>> Windows had to acquire CYGWIN then MSYS then WSL. You can't build the
>> simplest program without involving half of Linux.
>
> On Linux, we have package managers that only pull in the needed
> dependencies. Windows just seems actively hostile to that kind of
> infrastructure management. If you meant “you can’t build the simplest
> program *on Windows* without involving half of Linux” ... well, that’s
> just a reflection on the deficiencies of Windows. On Linux, you already
> have the *whole* of Linux to start with.

Check this out:

https://vcpkg.io/en/

;^)

On 01.01.2024 04:18, Keith Thompson wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> On 2023-12-31, Bart <bc@freeuk.cm> wrote:
> [...]
>>> How do you get it to look inside header files, or do those have to be
>>> submitted manually?
>>
>> ctags -R will process a tree recursively, including any C header files.
>> However, things that are only declared and not defined in header files,
>> like function declarations, are not indexed.
>
> The exuberant-ctags version I have on Ubuntu and Cygwin doesn't seem to
> have an option to process a tree recursively, or to deal with
> directories at all. (I find that a little surprising; it would be
> useful functionality.) The -R option is documented as follows:
>
> -R, --no-regex
> Don't do any more regexp matching on the following files. May
> be freely intermixed with filenames and the --regex option.

Does it have a '--recurse' option?

My Ubuntu version says

-R Equivalent to --recurse.

(version Exuberant Ctags 5.9~svn20110310)

Janis

> [...]

On Sun, 31 Dec 2023 20:06:38 -0800, Chris M. Thomasson wrote:

> On 12/31/2023 3:46 PM, Lawrence D'Oliveiro wrote:
>
>> On Linux, we have package managers that only pull in the needed
>> dependencies. Windows just seems actively hostile to that kind of
>> infrastructure management. If you meant “you can’t build the simplest
>> program *on Windows* without involving half of Linux” ... well, that’s
>> just a reflection on the deficiencies of Windows. On Linux, you already
>> have the *whole* of Linux to start with.
>
> Check this out:
>
> https://vcpkg.io/en/

How wonderful. From Microsoft, yet it is only for C/C++? Not even
supporting Microsoft’s flagship language, C#?

On 01.01.2024 01:07, Tim Rentsch wrote:
> [...]

Thanks for your post and suggestions.

Some have already been addressed (and some also answered) in
this thread, but that could have easily been overlooked since
the thread (unexpectedly) grew so large (and partly even OT).
Some discussions got a bit heated; but it's not worth. Peace
to all of you for the new year! :-)

Janis

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 01.01.2024 04:18, Keith Thompson wrote:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>> On 2023-12-31, Bart <bc@freeuk.cm> wrote:
>> [...]
>>>> How do you get it to look inside header files, or do those have to be
>>>> submitted manually?
>>>
>>> ctags -R will process a tree recursively, including any C header files.
>>> However, things that are only declared and not defined in header files,
>>> like function declarations, are not indexed.
>>
>> The exuberant-ctags version I have on Ubuntu and Cygwin doesn't seem to
>> have an option to process a tree recursively, or to deal with
>> directories at all. (I find that a little surprising; it would be
>> useful functionality.) The -R option is documented as follows:
>>
>> -R, --no-regex
>> Don't do any more regexp matching on the following files. May
>> be freely intermixed with filenames and the --regex option.

*** I was wrong about this. ***

> Does it have a '--recurse' option?
>
> My Ubuntu version says
>
> -R Equivalent to --recurse.
>
> (version Exuberant Ctags 5.9~svn20110310)
>
> Janis
>
>> [...]

There are actually (at least?) two different versions of ctags available
on Ubuntu. One is provided by the "emacs-bin-common" package (and has
no option for recursion), and one by the "exuberant-ctags" package (and
has "--recurse" and "-R" as you describe).

(The reason for my mistake is that I had built emacs from source and
ended up with an emacs-bin-common version of ctags in my $PATH ahead of
/usr/bin.)

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

On 12/31/2023 4:12 PM, Lawrence D'Oliveiro wrote:
> On Sun, 31 Dec 2023 13:51:28 -0800, Chris M. Thomasson wrote:
>
>> On 12/31/2023 1:44 PM, Lawrence D'Oliveiro wrote:
>>>
>>> If you want to see the right way to do macros, look at LISP, where they
>>> are token-based, and much more robust as as result. I think they even
>>> manage to apply scoping rules to macro definitions as well.
>>
>> Fwiw, check this out:
>>
>> [dead project with spam link omitted]

Spam? How?

>
> Looks long defunct, which is just as well.

The chaos pp lib? It was just an example of some fairly hard core macro
magic. Food for though. That's all. Did Boost stop using it? I never
really got into boost at all.

>
> I really did give string-based macros a try. I thought it was just down to
> deficiencies in the C/C++ preprocessor. So I did some work with GNU M4,
> which is about as powerful a string macro processor as you could want. And
> instead of being better, it was just as troublesome and fragile.
>
> The watchword now is “homoiconicity”. This means that the program has an
> AST representation in terms of objects in the language itself. LISP has
> this very naturally. And all your macro-type manipulations are done on
> this intermediate representation, not on the original program source.
>
> I found a way to do it Python, too, which I used for this project
> <https://gitlab.com/ldo/seaskirt> to generate both synchronous and
> asynchronous versions of the same API classes from common code.

On 12/31/2023 8:56 PM, Janis Papanagnou wrote:
> On 01.01.2024 01:07, Tim Rentsch wrote:
>> [...]
>
> Thanks for your post and suggestions.
>
> Some have already been addressed (and some also answered) in
> this thread, but that could have easily been overlooked since
> the thread (unexpectedly) grew so large (and partly even OT).
> Some discussions got a bit heated; but it's not worth. Peace
> to all of you for the new year! :-)

Happy New Year! :^)

On 12/31/2023 8:48 PM, Lawrence D'Oliveiro wrote:
> On Sun, 31 Dec 2023 20:06:38 -0800, Chris M. Thomasson wrote:
>
>> On 12/31/2023 3:46 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Linux, we have package managers that only pull in the needed
>>> dependencies. Windows just seems actively hostile to that kind of
>>> infrastructure management. If you meant “you can’t build the simplest
>>> program *on Windows* without involving half of Linux” ... well, that’s
>>> just a reflection on the deficiencies of Windows. On Linux, you already
>>> have the *whole* of Linux to start with.
>>
>> Check this out:
>>
>> https://vcpkg.io/en/
>
> How wonderful. From Microsoft, yet it is only for C/C++? Not even
> supporting Microsoft’s flagship language, C#?

I don't think it supports C# at all, highly doubt it. Fwiw, have you
heard of Q#? lol!

https://en.wikipedia.org/wiki/Q_Sharp

On Sun, 31 Dec 2023 22:57:12 -0800, Chris M. Thomasson wrote:

> It was just an example of some fairly hard core macro
> magic.

String-based macros aren’t “magic”, they’re just sad.

On 12/31/2023 8:48 PM, Lawrence D'Oliveiro wrote:
> On Sun, 31 Dec 2023 20:06:38 -0800, Chris M. Thomasson wrote:
>
>> On 12/31/2023 3:46 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Linux, we have package managers that only pull in the needed
>>> dependencies. Windows just seems actively hostile to that kind of
>>> infrastructure management. If you meant “you can’t build the simplest
>>> program *on Windows* without involving half of Linux” ... well, that’s
>>> just a reflection on the deficiencies of Windows. On Linux, you already
>>> have the *whole* of Linux to start with.
>>
>> Check this out:
>>
>> https://vcpkg.io/en/
>
> How wonderful. From Microsoft, yet it is only for C/C++? Not even
> supporting Microsoft’s flagship language, C#?

Btw, C# can burn in hell for all I care.

On 12/31/2023 11:00 PM, Lawrence D'Oliveiro wrote:
> On Sun, 31 Dec 2023 22:57:12 -0800, Chris M. Thomasson wrote:
>
>> It was just an example of some fairly hard core macro
>> magic.
>
> String-based macros aren’t “magic”, they’re just sad.

Fair enough. ;^) Happy new year.

Btw, the chaos pp had some fairly neat tricks.

On 12/31/2023 11:00 PM, Lawrence D'Oliveiro wrote:
> On Sun, 31 Dec 2023 22:57:12 -0800, Chris M. Thomasson wrote:
>
>> It was just an example of some fairly hard core macro
>> magic.
>
> String-based macros aren’t “magic”, they’re just sad.

BTW:
________________
#include <stdio.h>

#define A "Happy"
#define B "New"
#define C "Year"

int
main()
{ printf(A " " B " " C "!\n");

return 0;
} ________________

:^D

On 2024-01-01, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> On 2023-12-31, Bart <bc@freeuk.cm> wrote:
> [...]
>>> How do you get it to look inside header files, or do those have to be
>>> submitted manually?
>>
>> ctags -R will process a tree recursively, including any C header files.
>> However, things that are only declared and not defined in header files,
>> like function declarations, are not indexed.
>
> The exuberant-ctags version I have on Ubuntu and Cygwin doesn't seem to
> have an option to process a tree recursively, or to deal with
> directories at all. (I find that a little surprising; it would be
> useful functionality.) The -R option is documented as follows:
>
> -R, --no-regex
> Don't do any more regexp matching on the following files. May
> be freely intermixed with filenames and the --regex option.

That's verbatim out of the etags documentation (a tags generator
associated with Emacs), not Exuberant ctags.

Etags provides two commands: etags and ctags. (I'm guessing, because the
Emacs tag format is different from the ctags one, and the two programs
generate different formats?)

Thus what "ctags" refers to on a Debian-like system such as Ubuntu
will be decided by the "alternatives" system.

It may be that Emacs pulls in etags, and so you get a ctags command
referring to that.

In turn, I'm surprised to find that there is a ctags documented by POSIX.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ctags.html

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2024-01-01, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 31 Dec 2023 22:57:12 -0800, Chris M. Thomasson wrote:
>
>> It was just an example of some fairly hard core macro
>> magic.
>
> String-based macros aren’t “magic”, they’re just sad.

Half the problem of C macros comes from the C language.

The C language has too much syntax, which causes friction
when you use the C preprocessor.

This really hit home for me when I developed the cppawk
project.

cppawk is a shell program that wraps C preprocessing around awk.

Awk has a C-inspired syntax, but there is a lot less of it;
for instance, no type declarations, and semicolons mandatory.
This simplicity makes preprocessing a lot smoother.

In cppawk, I was able to develop an iteration macro which
supports a vocabulary of clauses. Furthermore, the vocabulary
is application-extensible, very easily.
There are two variants: loop and loop_nest for parallel
and cross-product iteration. In loop_nest you can use
the parallel() combinator to combine certain clauses
to go in parallel with each other.

Here are test cases for the loop macro:

https://www.kylheku.com/cgit/cppawk/tree/testcases-iter#n67

Some of the test cases exercise user-defined clauses,
like a "first_then_until" clause which initializes
a variable with an arbitrary expression, and steps
it with another arbitrary expression, until a certain
condition:

#include <iter.h>

#define __init_first_then_until(var, first, then, until) (var = (first))
#define __test_first_then_until(var, first, then, until) (!(until))
#define __prep_first_then_until(var, first, then, until) 1
#define __fini_first_then_until(var, first, then, until) 1
#define __step_first_then_until(var, first, then, until) (var = (then))

BEGIN {
loop (first_then_until(i, 1, i * 2, i >= 60),
first_then_until(s, "x", s s, 0))
{
print i, s
}
}

Output:

1 x
2 xx
4 xxxx
8 xxxxxxxx
16 xxxxxxxxxxxxxxxx
32 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

By defining five macros: __init_X, __test_X, __prep_X, __fini_X
and __step_X, you define a new clause X. The man page details how.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 01/01/2024 02:00, Lawrence D'Oliveiro wrote:
> On Mon, 1 Jan 2024 01:33:38 +0000, Bart wrote:
>
>> On 31/12/2023 23:46, Lawrence D'Oliveiro wrote:
>>>
>>> If you meant “you can’t build the simplest
>>> program *on Windows* without involving half of Linux” ... well, that’s
>>> just a reflection on the deficiencies of Windows. On Linux, you already
>>> have the *whole* of Linux to start with.
>>
>> And developers feel it necessary to USE everything that it provides!
>
> It’s called “code reuse”. A well-designed package-management system just
> makes it so much easier to do.
>
>> I've never managed to build the GMP library on Windows for example (it
>> only comes as source code), because it requires that 30,000-line bash
>> script which in turn needs sed and m4 and all the rest.
>>
>> Why? It's a numeric library. Why should it be dependent on OS?
>
> Those are just standard file-manipulation tools that any decent OS should
> provide.

What's that got to do with building able to build programs easily?

I have an interpreter app 'qc' which is 37 modules and 39Kloc. It's not
in C, and I usually build it on Windows like this:

c:\qx>mm qc

It takes 0.1 seconds. I don't support Linux directly, but I can port it
by transpiling to C first, which takes 90ms:

c:\qc>mc -c -linux qc

Now I can build it under WSL:

root@xxx:/mnt/c/qx# gcc qc.c -oqc -fno-builtin -lm -ldl

And run it, but it needs the '-nosys' option as its std libraries make
use of WinAPI:

root@xxx:/mnt/c/qx# ./qc -nosys hello
Hello, World! 1-Jan-2024 11:43:54

Here is the demo program it runs:

root@xxx:/mnt/c/qx# cat hello.q
println "Hello, World!", $date, $time

And these are the specs for those files:

c:\qx>dir qc.c qc
01/01/2024 11:40 1,392,581 qc.c
01/01/2024 11:42 846,488 qc

Quite a substantial program that can be built effortlessly on either
Windows or Linux. Using Tiny C, it apparently compiles it in 75ms.

Try the same exercise with any equivalentally-sized program originating
on Linux. That is end, end up with only a C file (even multiple C files)
that I can build with a bare compiler.

That seems to be beyond most Linux developers.

>
>> Or maybe Linux developers NEED all that hand-holding and have no idea
>> how to build using a bare compiler.
>
> If only you could do that on Windows ... but no. Look at all the C runtime
> stuff needed just to build a simple “Hello World” program ... because
> Windows automatically assumes that every program must have a GUI.

It sounds like you've either never used Windows or had one bad
experience, as this is incorrect.

If I do this on Windows:

mcc hello.c

it produces a file hello.exe which is 2.5KB. (Tcc manages it in 2.0KB!)

So what's the fuss?

>
>> Remember that end-users building
>> such projects are only doing a one-time build to get a working binary.
>
> They find it easier to do “apt-get install”, or a GUI wrapper around same,
> like Synaptic.

Windows applications have for long been a ready-to-run binary.

On 31/12/2023 18:43, James Kuyper wrote:
> On 12/31/23 08:40, David Brown wrote:
> ...
>> In C, the "inline" qualifier is pretty much a message from the
>> programmer saying "I think the resulting code would be more efficient
>> if this is inlined by the optimiser".
>
> Actually, what the C standard says is "Making a function an
> inline function suggests that calls to the function be as fast as
> possible". The standard does not specify how this is to be achieved, it
> merely imposes some requirements that constrain how it could be
> achieved. Inlining a function call is just one way to do that.
>

Yes, that's what the standard says. The choice of "inline" as the
keyword is copied from C++, rather than meaning specifically that the
function should be inlined by the optimiser.

But most C programmers don't read the standards, and I think many will
assume they are asking for "inlining", rather than more generically "as
fast as possible". Usually - but not always - "as fast as possible"
will imply inlining optimisations anyway.

On 31/12/2023 19:33, Scott Lurndal wrote:
> Bart <bc@freeuk.cm> writes:
>> On 31/12/2023 01:36, Lawrence D'Oliveiro wrote:
>>> On Sat, 30 Dec 2023 01:58:53 +0000, Bart wrote:
>>>
>>>> So, why don't the vendors of the library do that exercise?
>>>
>>> Maybe because most of the “vendors” of proprietary libraries have gone
>>> extinct. What we have now is “developers” and “contributors” to open-
>>> source projects. And if you have a bright idea for how they can do things
>>> better, you are free to contribute it.
>>
>> I have plenty of ideas, but people are generally not interested.
>
> Perhaps they are not very good ideas, then....
>
> Frankly, your obsession with header files is puzzling. 99.9%
> percent of C/C++ programmers don't care.

Bart needs to care about the library header files when he is working on
his C implementation, and it is understandable that he finds existing
headers frustrating when he is trying to turn them into something his C
implementation can use. But you are absolutely correct that the huge
majority of C programmers don't care what is in these headers. So as I
see it, the strange thing about Bart's view of library headers is not
that /he/ is obsessed with them or frustrated by them, but that he
apparently feels other people should also be bothered by them.

The glibc (and other C library) developers have a responsibility to make
headers that work correctly for C programmers, according to the C
standards and their own documentation of extensions, and without
significant measurable unnecessary inefficiency - beyond that, they can
organise things in whatever way suits them and whatever way they find
easiest. They have no responsibility to make life easier for people
making libraries, headers or compilers other than those they choose to
work with. Bart is right to think they /could/ have made it vastly
easier to use their headers with other tools, such as his compiler - but
wrong to think they /should/ have done so, and wrong to think that more
than a tiny proportion of C programmers are bothered about it.

C++ programmers (and C++ compiler writers) /do/ care a bit more about
headers, though not the ones from the C standard library. C++ headers
are often very big and are a significant part of compile and build
times. Thus compilers often support pre-compiled headers, and one of
the prime motivations of C++ modules in newer C++ standards is to be
more efficient and cleaner than header files.

On 31/12/2023 18:33, Scott Lurndal wrote:
> Bart <bc@freeuk.cm> writes:
>> On 31/12/2023 01:36, Lawrence D'Oliveiro wrote:
>>> On Sat, 30 Dec 2023 01:58:53 +0000, Bart wrote:
>>>
>>>> So, why don't the vendors of the library do that exercise?
>>>
>>> Maybe because most of the “vendors” of proprietary libraries have gone
>>> extinct. What we have now is “developers” and “contributors” to open-
>>> source projects. And if you have a bright idea for how they can do things
>>> better, you are free to contribute it.
>>
>> I have plenty of ideas, but people are generally not interested.
>
> Perhaps they are not very good ideas, then....
>
> Frankly, your obsession with header files is puzzling. 99.9%
> percent of C/C++ programmers don't care.

Well, they should care more.

Even considering only C, using libraries like SDL2, Windows, GTK looks
simple enough; you just write #include <header.h>, but behind that
header could be 100s of nested header files and 100s of 1000s of lines
of code.

I recently had to build a C program of 34 modules, which only totalled
8Kloc (with an executable of 150KB), but it took even my compiler 1.5
seconds. What was going on?

It turned out each module was processing the headers for SDL2, and many
of those headers were including other SDL headers. In all, 7-8000
#includes were being processed, and SDL2 is one of the smaller such
libraries.

The information in those SDL headers could be summarised in one header
file of 3000 lines. Why on earth would all those sub-headers need to be
exposed to a user-program anyway?

And here I've only looked at the impact on compilation times. Not on
creating bindings for other languages.

Instead of looking at this problem and coming to a conclusion like mine,
people prefer to solve by piling on more complexity, or using faster
machines, or multiple cores, or creating clever build processes to try
and avoid compiling, or invent 'precompiled headers', or any number of
fanciful ideas rather than tackling the elephant in the room.

On 31/12/2023 16:45, Bart wrote:
> On 31/12/2023 15:25, David Brown wrote:
>> On 29/12/2023 23:40, Bart wrote:
>>> On 29/12/2023 20:23, Kaz Kylheku wrote:
>>>> On 2023-12-29, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> A useful tool that someone might like to write for this particular
>>>>>> situation would be a partial C preprocessor, letting you choose what
>>>>>> gets handled.  You could choose to expand the code here for, say,
>>>>>> _GNU_SOURCE and _BSD_SOURCE - any use of these in #ifdef's and
>>>>>> conditional compilation would be expanded according to whether you
>>>>>> have defined the symbols or not, leaving an output that is easier to
>>>>>> understand while keeping most of the pre-processor stuff unchanged
>>>>>> (so
>>>>>> not affecting #includes, and leaving #define'd macros and constants
>>>>>> untouched and therefore more readable).
>>>>>
>>>>> The unifdef tool does some of this.  (I haven't used it much.)
>>>>
>>>> GNU cpp has an option which is something like this: -fdirectives-only.
>>>> It causes it not to expand macros.
>>>
>>> It flattens include files, processes conditionals, and keeps #defines
>>> unchanged.
>>>
>>> However, it turns gcc's sys/stat.h from 300 lines into 3000 lines.
>>>
>>> If I apply it to my stat.h (also my stddef.h which it includes),
>>> which are 110 lines together, it produces 900 lines. Most of that
>>> consists of lots of built-in #defines with __ prefixes (each complete
>>> with a line saying it is built-in).
>>>
>>> When I use my own conversion tool (designed to turn C headers that
>>> define APIs into declarations in my language), the output is 65 lines.
>>>
>>> The gcc option does not expand typedefs or macros. So if there is a
>>> declaration using a type which uses both, that is unchanged, which is
>>> not helpful. (At least not if trying to create bindings for your FFI.)
>>>
>>> gcc with just -E will expand macros but still keep typedefs.
>>>
>>
>> Note that typedefs are part of the core C language, not the
>> preprocessor, so there could not possibly be a cpp option to do
>> anything with typedefs (the phrase "expand typedefs" is entirely wrong).
>>
>> I realise that you (and possibly others) might find it useful for a
>> tool to replace typedef identifiers with their definitions, but it
>> could only be done for some cases, and is not as simple as macro
>> substitution.
>
> Take this program, which uses two nested typedefs and one macro:
>
>    typedef short T;
>    typedef T U;
>    #define V U
>
>    typedef struct R {
>        V a, b, c;
>    } S;
>
> Passed through 'gcc -E', it manages to expand the V in the struct with
> U. (-fdirectives-only doesn't even do that).

V is a macro, so it is expanded by the preprocessor.
"-fdirectives-only" instructs cpp that it should not expand macros. So
far, this is all obvious and correct.

>
> So what are the types of 'a, b, c'? Across 1000s of line of code, they
> may need tracking down. At least, for someone not using your super-duper
> tools.

As I said, I appreciate that it could be useful for you to have a tool
that "unpacks" typedefs. But that would not be related to a
preprocessor, and it could not be done by textual substitution (as
macros are handled by the C preprocessor).

In particular, you could replace all uses of "T" with "short", once you
have taken scoping into account (something not needed for preprocessor
macros). And you could replace "U" with "short". But you could /not/
replace "S" with "struct R { short a, b, c; }" without changing the
meaning of the code.

typedef's of function types and function pointer types get complicated
in other ways - handling these is not at all like macro expansion.

>
> If I use my compiler with 'mcc -mheaders', I get an output file that
> includes this:
>
>     record R = $caligned
>         i16 a
>         i16 b
>         i16 c
>     end
>
> It gives all the information I might need. Including the fact that it
> uses default C alignment rules.
>
> Notice however the name of the record is R not S; here it needs a
> struct-tag to avoid an anonymous name. The typedef name is harder to use
> as it is replaced early on in compilation.
>
> Here, I'm effectively expanding a typedef. The output could just as
> equally have been C source code.
>

On 31/12/2023 22:44, Lawrence D'Oliveiro wrote:
> On Sun, 31 Dec 2023 16:25:08 +0100, David Brown wrote:
>
>> I realise that you (and possibly others) might find it useful for a tool
>> to replace typedef identifiers with their definitions, but it could only
>> be done for some cases, and is not as simple as macro substitution.
>
> String-based macros are nothing but trouble.

What a strange thing to say.

Macros based on textual substitution have their advantages and their
disadvantages. It is a reasonable generalisation to say you should
prefer alternatives when available, such as inline functions, const
objects, enum constants, typedefs, etc., rather than macro equivalents.
But there are plenty of situations where C's pre-processor macros are
extremely useful in writing good, clear and maintainable code.

> Typedefs are scoped, string
> macros are not.

True. Sometimes that is an advantage, sometimes a disadvantage.

Like any powerful tool, macros can be abused or misused, leading to
poorer results - but that does not mean they are "nothing but trouble".

Other programming languages might have different ways of doing things,
again with advantages and disadvantages.

Lawrence D'Oliveiro wrote:

> On Mon, 1 Jan 2024 01:33:38 +0000, Bart wrote:
>> I've never managed to build the GMP library on Windows for example (it
>> only comes as source code), because it requires that 30,000-line bash
>> script which in turn needs sed and m4 and all the rest.
>>
>> Why? It's a numeric library. Why should it be dependent on OS?
>
> Those are just standard file-manipulation tools that any decent OS
> should provide.

The phrase “all the rest” is ambiguous, and if a C program requires more
than the CPP (which is more powerful than people give it credit for…),
chances are that something's already gone pretty wrong.

--
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Now hiring waiter. Must be expert in railway salvage operations.

On 01/01/2024 14:44, David Brown wrote:
> On 31/12/2023 22:44, Lawrence D'Oliveiro wrote:
>> On Sun, 31 Dec 2023 16:25:08 +0100, David Brown wrote:
>>
>>> I realise that you (and possibly others) might find it useful for a tool
>>> to replace typedef identifiers with their definitions, but it could only
>>> be done for some cases, and is not as simple as macro substitution.
>>
>> String-based macros are nothing but trouble.
>
> What a strange thing to say.
>
> Macros based on textual substitution have their advantages and their
> disadvantages.  It is a reasonable generalisation to say you should
> prefer alternatives when available, such as inline functions, const
> objects, enum constants, typedefs, etc., rather than macro equivalents.
> But there are plenty of situations where C's pre-processor macros are
> extremely useful in writing good, clear and maintainable code.

The cases where macros are used sensibly would be better replaced by apt
language features (D does this for example as it is no preprocessor).

But I tend to come across the ones where macros are overused or abused.
Some people seem to delight in doing so.

When working the Lua sources a few months ago, that makes heavy uses of
macros defined in lower case which look just like functions calls.

One complex expression that my compiler had trouble with, when expanded,
resulted in a line hundreds of character long, and using 11 levels of
nested parentheses, the most I've ever come across.

I really doubt that the authors would have written code that convoluted
if macros had not been available.

>> Typedefs are scoped, string
>> macros are not.
>
> True.  Sometimes that is an advantage, sometimes a disadvantage.

When it is an advantage?

My systems language only acquired macros with parameters a year or two
ago. They can only be used to expand to well-formed terms of
expressions, and are used very sparingly.

They have normal scoping, so can be shadowed or have distinct versions
in different scopes and functions can define their own macros; they can
be imported or exported just like functions and variables.

The sorts of macros that C has seem stone age by comparison. And crude,
in being able to define random bits of syntax, or synthesise tokens from
multiple parts.

Some people will obviously love that, but imagine trying to search for
some token with a text editor, but it won't find it because it only
exists after preprocessing.

> Like any powerful tool, macros can be abused or misused, leading to
> poorer results - but that does not mean they are "nothing but trouble".

I wouldn't use the work 'powerful'; 'dangerous' and 'crazy' might be
more apt.

Imagine a CPP that could also map one letter another; more 'powerful',
or just more 'crazy'?

On 1/1/2024 5:56 AM, Bart wrote:
> On 01/01/2024 02:00, Lawrence D'Oliveiro wrote:
>> On Mon, 1 Jan 2024 01:33:38 +0000, Bart wrote:
>>
>>> On 31/12/2023 23:46, Lawrence D'Oliveiro wrote:
>>>>
>>>> If you meant “you can’t build the simplest
>>>> program *on Windows* without involving half of Linux” ... well, that’s
>>>> just a reflection on the deficiencies of Windows. On Linux, you already
>>>> have the *whole* of Linux to start with.
>>>
>>> And developers feel it necessary to USE everything that it provides!
>>
>> It’s called “code reuse”. A well-designed package-management system just
>> makes it so much easier to do.
>>
>>> I've never managed to build the GMP library on Windows for example (it
>>> only comes as source code), because it requires that 30,000-line bash
>>> script which in turn needs sed and m4 and all the rest.
>>>
>>> Why? It's a numeric library. Why should it be dependent on OS?
>>
>> Those are just standard file-manipulation tools that any decent OS should
>> provide.
>
> What's that got to do with building able to build programs easily?
>
> I have an interpreter app 'qc' which is 37 modules and 39Kloc. It's not
> in C, and I usually build it on Windows like this:
>
>     c:\qx>mm qc
>
> It takes 0.1 seconds. I don't support Linux directly, but I can port it
> by transpiling to C first, which takes 90ms:
>
>     c:\qc>mc -c -linux qc
>
> Now I can build it under WSL:
>
>     root@xxx:/mnt/c/qx# gcc qc.c -oqc -fno-builtin -lm -ldl
>
> And run it, but it needs the '-nosys' option as its std libraries make
> use of WinAPI:
>
>     root@xxx:/mnt/c/qx# ./qc -nosys hello
>     Hello, World! 1-Jan-2024 11:43:54
>
> Here is the demo program it runs:
>
>     root@xxx:/mnt/c/qx# cat hello.q
>     println "Hello, World!", $date, $time
>
> And these are the specs for those files:
>
>     c:\qx>dir qc.c qc
>     01/01/2024  11:40         1,392,581 qc.c
>     01/01/2024  11:42           846,488 qc
>
> Quite a substantial program that can be built effortlessly on either
> Windows or Linux. Using Tiny C, it apparently compiles it in 75ms.
>
> Try the same exercise with any equivalentally-sized program originating
> on Linux. That is end, end up with only a C file (even multiple C files)
> that I can build with a bare compiler.
>
> That seems to be beyond most Linux developers.
>

For a lot of stuff, it is surprising what one can get done with a
one-liner shell script or batch file:
gcc -o prog_name sources... options...
Or:
cl /Feprog_name sources... options...

And, then 'make' is still plenty usable.

The more complex build systems often don't really help, they often make
the problem worse, and are needlessly overkill for most programs.

Also usually makes sense to be conservative for what one uses, trying to
avoid dependencies on things that aren't actually needed for a given
program (or may not be available on the various targets).

>>
>>> Or maybe Linux developers NEED all that hand-holding and have no idea
>>> how to build using a bare compiler.
>>
>> If only you could do that on Windows ... but no. Look at all the C
>> runtime
>> stuff needed just to build a simple “Hello World” program ... because
>> Windows automatically assumes that every program must have a GUI.
>
> It sounds like you've either never used Windows or had one bad
> experience, as this is incorrect.
>
> If I do this on Windows:
>
>     mcc hello.c
>
> it produces a file hello.exe which is 2.5KB. (Tcc manages it in 2.0KB!)
>
> So what's the fuss?
>

Yeah, and if one does a console program, the code is basically identical
either way:
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("Hello World\n");
return(0);
}

If building it from the command line with MSVC:
cl helloworld.c

Not a big issue...

GUI is a pain, but this is true regardless of OS.

Would be good though if there were a "good" portable way to do cross
platform GUI programs, but alas.

A common strategy is for a program does all the UI drawing itself, can
avoid need for platform-specific window-management code by using SDL or
similar.

Theoretically, GTK exists, but tends to be borderline unusable on
Windows (and then, it usually ends up needing to be built via Cygwin or
similar, which has the drawback that any GUI programs that use it will
also end up spawning a console window in the background).

One other drawback of GTK is that it doesn't really separate the API
from the implementation, so GTK only really exists as "the library" and
not as an API that may have multiple underlying implementations (which
would be the more preferable strategy IMO). But, at the same time, the
API design for GTK is not itself particularly friendly to this sort of
approach (it is better to have an API design where the libraries'
implementation details are almost entirely opaque to the client program;
which isn't really the case with GTK).

For programs that may use OpenGL, it ends up common to use OpenGL for
all the UI stuff as well.

Though, at this point, if one does make a cross-platform widget library,
also good if it can also play well with OpenGL (and would prefer if
OpenGL stays around, as Vulkan is not really a good "general purpose"
replacement IMHO).

For a lot of "general use" stuff (namely, for stuff that is not high-end
3D games), something like OpenGL 1.3 to 2.1 seems "nearly ideal" (GL3.x
deprecates a lot of stuff that is useful for these "lower end"
use-cases). In newer OpenGL versions, this variant was renamed to being
the "Compatibility Profile".

In my project's OpenGL implementation, it is mostly limited to 1.x style
functionality, as I have yet to implement a GLSL compiler (also the
hardware rasterizer module only does fixed function, so any shaders
would effectively end up being run on the CPU anyways). But, granted, I
was originally using software rasterization, so it isn't that much
different, apart from a question of how to compile GLSL in a way that
wont "totally suck" for performance.

One advantage also of GL1.x and fixed-function is that it is at least a
viable option to implement for targets which don't have a GPU.

Granted, one could argue that OpenGL is still a heavyweight option for
GUI if one doesn't need any fancy graphical features (and could have
just drawn the UI into a bitmap buffer).
Would be nice if the widget toolkit could work either way:
Using raw bitmap graphics if this is all that is needed;
Using OpenGL or a hybrid option if GL is in use.

Hybrid, eg: drawing into a bitmap and then using glDrawPixels or similar
to overlay the GUI widgets on top of the parts drawn via GL.

Maybe could also make sense to have a Unicode font expressed in SDF form
and similar (possibly with multiple mip levels to improve glyph quality).

....

>>
>>> Remember that end-users building
>>> such projects are only doing a one-time build to get a working binary.
>>
>> They find it easier to do “apt-get install”, or a GUI wrapper around
>> same,
>> like Synaptic.
>
> Windows applications have for long been a ready-to-run binary.

Yeah, and for the most part, pretty much any program compiled within the
past 25 years or so is going to work without issue using the original
binaries (much past this, the main problem cases being programs
targeting MS-DOS or Win16).

We don't need OS repos, because program installers can be casually
downloaded off the internet.

I guess, technically there is now the "Microsoft Store" (which is sort
of like "Google Play" on Android), but haven't really used it for much.

On 01/01/2024 19:06, BGB wrote:
> On 1/1/2024 5:56 AM, Bart wrote:

>> Quite a substantial program that can be built effortlessly on either
>> Windows or Linux. Using Tiny C, it apparently compiles it in 75ms.
>>
>> Try the same exercise with any equivalentally-sized program
>> originating on Linux. That is end, end up with only a C file (even
>> multiple C files) that I can build with a bare compiler.
>>
>> That seems to be beyond most Linux developers.
>>
>
> For a lot of stuff, it is surprising what one can get done with a
> one-liner shell script or batch file:
>   gcc -o prog_name sources... options...
> Or:
>   cl /Feprog_name sources... options...
>

The approaches I use are mainly:

1 Submit all the files, libraries and options on one line like
your example. Using up/down keys to recall commands.

2 Put the command line in (1) into a shell script

3 Put the same information, usually on multiple lines into an
'@' file, then build using 'gcc @file' for example.

The above are fine as instructions for someoneelse to do a one-off build
of your project. But what I normally use for development:

4 I use my 60KB console IDE and a project file descripting the modules
similar to the @ file. Now I can browse/edit/compile individual
files, and link and run the lot.

The problem with 1/2/3 when using a slow compiler like gcc is that you
have to compile everything. With (4) I can compile only what's relevant.
Since I will be very familiar with the project, I will know the main
dependencies and will know when I need to build everything.

> And, then 'make' is still plenty usable.

If you understand make, that's fine. I generally prefer my option (4),
which I've used, in various forms, for decades.

I wouldn't however inflict a makefile-based build on someone; I might
supply (3) and a one-line build instruction. Unless it's a generated C
then it will be one file anyway, or it might even be just *.c.

> The more complex build systems often don't really help, they often make
> the problem worse, and are needlessly overkill for most programs.

They very often don't work, especially outside their comfort zone of Linux.

> Yeah, and if one does a console program, the code is basically identical
> either way:
>   #include <stdio.h>
>   int main(int argc, char *argv[])
>   {
>      printf("Hello World\n");
>      return(0);
>   }
>
> If building it from the command line with MSVC:
>   cl helloworld.c
>
> Not a big issue...

> GUI is a pain, but this is true regardless of OS.
>
>
> Would be good though if there were a "good" portable way to do cross
> platform GUI programs, but alas.
>
> A common strategy is for a program does all the UI drawing itself, can
> avoid need for platform-specific window-management code by using SDL or
> similar.

I've given up on GUI from a compiled language. I use it only from my
interpreted code using library that works on top of WinAPI. It was
supposed to be adaptable to X11, but I never got around to it, and that
looks as terrible as WinAPI anyway.

However SDL seems a reasonable compromise. It's a LOT smaller than GTK
(which is really a collection of libraries; I think it comprises 50
different DLLs). There are smaller ones around, but it general it's too
much of a pain. You're also never going to produce something as flashy
as even the tackiest Android app.

> One other drawback of GTK is that ...

.... it's a monster.

(When I did try to test my compiler on it a few years ago - the API and
DLLs, not the source codes; the headers are complicated enough - I found
that one of its structs used bitfields, which are
implementation-dependent, in a public API.

That means the size of the struct, which is critical, depended on how
the compiler dealt with bitfields. I think it mainly works by luck since
most use gcc or compatible, that matches what was used to build the
library.)

> We don't need OS repos, because program installers can be casually
> downloaded off the internet.
>
> I guess, technically there is now the "Microsoft Store" (which is sort
> of like "Google Play" on Android), but haven't really used it for much.

Good luck in getting your app into one of those stores.

It's getting harder to provide binaries to Windows users, first because
your machine now needs to be unlocked to run arbitrary EXE files (even
MS apps like command.exe are otherwise banned!).

But also because a random EXE will tricker AV warnings or even
quarantine your program.

I don't know how programs such as C compilers that you download get
around such checks.