Glad you like it! Not sure what separator you would pick between the name(args)=expansion stuff. I could imagine some generic files/modules might have enough or long enough params that people might want to backslash line continue. So, maybe '@' or '`' { depending on if you want many or few pixels ;-) } ?

    #include "file.c" _(_x)=myNamePrefix ## _x `\
                      KEY=charPtr VAL=int `\
                      ....

By doing that kind of namespacing, you actually can write a generic module which allows client code manual instantiators a lot of control to select "verb noun" instead of "noun verb" kinds of schemes like "add_word" instead of "word_add" and potentially even change snake_case to camelCase with some _capwords.h file that does `#define _get Get` like moves, though of course name collisions can bite. That bst/ thing I linked to does not have full examples of all the optionality. E.g., to support my "stack popping" of macro defs, without that but just with ANSI C 89 you might do something like this instead to get "namespace nesting":

    #ifndef CT_ENVIRON_H
    #define CT_ENVIRON_H
    /* This file establishes a macro environment suitable for instantiation of
       any of the Map/Set/Seq/Pool or other sorts of generic collections. */
    
    #ifndef _
    /* set up a macro-chain using token pasting *inside* macro argument lists. */
    #define _9(x)    x    /* an identity macro must terminate the chain. */
    #define _8(x) _9(x)
    #define _7(x) _8(x)   /* This whole chain can really be as long as   */
    #define _6(x) _7(x)   /* you want.  At some extreme point (maybe     */
    #define _5(x) _6(x)   /* dozens of levels) expanding _(_) will start */
    #define _4(x) _5(x)   /* to slow-down the Cpp phase.                */
    #define _3(x) _4(x)   /* Also, definition order doesn't matter, but  */
    #define _2(x) _3(x)   /* I like how top->bottom matches left->right  */
    #define _1(x) _2(x)   /* in the prefixing-expansions.               */
    #define _0(x) _1(x)
    #define _(x)  _0(x)   /* _(_) must start the expansion chain */
    #endif
    
    #ifndef CT_LNK
    #   define CT_LNK static
    #endif
    #endif /* CT_ENVIRON_H */

    #define _8(x) _9(i_ ## x)  /* some external client decides "i_"          */
    _(_foo)                    /* #include "I" -> i_foo at nesting-level 8   */
    #define _6(x) _7(e_ ## x)  /* impl of i_ decides "e_"                    */
    _(_foo)                    /* #include "E" -> i_e_foo at level 6         */
    #define _3(x) _4(c_ ## x)  /* impl of e_ decides "c_"                    */
    _(_foo)                    /* #include "C" -> i_e_c_foo at level 3       */
    #define _0(x) _1(l_ ## x)  /* impl of c_ decides "l_"                    */
    _(_t)
    _(_foo)                    /* #include "L" -> i_e_c_l_foo at level 0     */
    #define _0(x) _1(x)        /* c impl uses _(l_foo) to define _(bars)     */
    _(_foo)                    /* i_e_c_foo at nesting level 3 again         */
    #define _3(x) _4(x)        /* e impl uses _(c_foo) to define _(bars)     */
    _(_foo)                    /* i_e_foo at nesting level 6 again           */
    #define _6(x) _7(x)        /* i impl now uses _(e_foo) to define _(bars) */
    _(_foo)                    /* i_foo at nesting level 8 again             */

Personally, I started doing this kind of thing in the mid-1990s as soon as I saw people shipping "code in headers" in C++ template libraries and open source taking off. These days I think of it as an example of how much you can achieve with very simple mechanisms and the trade-offs of automating instantiation at all. But people sure seem to like to "just refer" to instances of generic types.

I think the #include extension could make vec_vec / vec_list / lst_str type nesting more natural/maybe more general, but maybe just my opinion. :-)

I guess ctags-type tools would need updating for the new possible definition location. Mostly someone needs to decide on a separation syntax for stuff like `name1(..)=expansion1 name2(..)=expansion2` for "in-line" cases. Compiler programs have had `cc -Dname(..)=expansion` or equivalents since the dawn of the language, but they actually get the OS/argv idea of separation from whatever CL args or Windows APIs or etc.

Anyway, might makes sense to first get experience with a slimcc/tinycc/gcc/clang cpp++ extension. ;-) Personally, these days I mostly just use Nim as a better C.

This Facebook repository also use a new "extension" to do a similar thing:

https://github.com/facebookresearch/CParser#multiline-macros

debugging information is more precise than line numbers, it usually conveys line and column in a source file.

Some debuggers make use of it when displaying the current program state, the major debuggers do not allow you to step into a specific sub-call on a line (e.g. skip function arguments and go straight to the outermost function call). This is purely a UI issue, they have enough information. I believe the nnd debugger has implemented selecting the call to step into.

Addr2line could be amended. I am working on my own debugger and I keep re-implementing existing command line tools as part of my testing strategy. A finer-grained addr2line sounds like a good exercise.

I don't think this is optimizing for the right thing, I've sat in front of hundreds of gcc & clang compiler time traces and lexing is a minuscule percentage of the time spent in the compiler

Just because a feature is there doesn't mean you have to use it.

Additionally the example isn't even possible, at least make ridiculous examples that compile.

Don't use inheritance and you won't have to find out.

This is just silly. C++ gives you a smorgasbord of multi-paradigm features. Everything has its place and you can mix and match your needed featureset based on project needs, team skillset etc. You don't have to know or learn everything.

I think the main appeal is subset lock-down and compile times. ~5000 lines in C gets me sub second iteration times, while ~5000 lines in C++ hits the 10 second mark. Including both iostream and format in C++ gets any project up into the ~1.5 second mark which kills my iteration interests.

Second to that I'd say the appeal is just watching something you've known for a long time grow slowly and steadily.

I see it the other way round. People hurt themselves by using C++. C++ fans will never understand it, but it you can solve your problem in a much simpler way, this is far better.

C offers a different solution to the problem in Annex K of the standard. It provides a type `rsize_t`, which like `size_t` is unsigned, and has the same bit width, but where `RSIZE_MAX` is recommended to be `SIZE_MAX >> 1` or smaller. You perform bounds checking as `<= RSIZE_MAX` to ensure that a value used for indexing is not in the range that would be considered negative if converted to a signed integer. A negative value provided where `rsize_t` is expected would fail the check `<= RSIZE_MAX`.

IMO, this is a better approach than using signed types for indexing, but AFAIK, it's not included in GCC/glibc or gnulib. It's an optional extension and you're supposed to define `__STDC_WANT_LIB_EXT1__` to use it.

I don't know if any compiler actually supports it. It came from Microsoft and was submitted for standardization, but ISO made some changes from Microsoft's own implementation.

https://www.open-std.org/JTC1/SC22/WG14/www/docs/n1173.pdf#p...

https://www.open-std.org/JTC1/SC22/WG14/www/docs/n1225.pdf

> It makes sense that you should be able to assign a pointer to a size. If the size is signed, this cannot be done due to its smaller capacity.

You can, since the number of bits is the same. The mapping of pointer bits to signed integer bits will mean that you can't then do arithmetic on the resulting integers and get meaningful results, but the behavior of such shenanigans is already unspecified with no guarantees other than you can get an integer out of a pointer and then convert it back later.

But also, semantically, what does it even mean to convert a single pointer to a size? A size of an object is naturally defined as the count of chars between two pointers, one pointing at the beginning of the object, the other at its end. Which is to say, a size is a subset of pointer difference that just happens to always be non-negative. So long as the implementation guarantees that for no object that non-negative difference will always fit in a signed int of the appropriate size, it seems reasonable to reflect this in the types.

Stroustrup believes that signed should be preferred to unsigned even for values that can’t be less than zero: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p14...

I dont know either.

int somearray[10];

new_ptr = somearray + signed_value;

or

element = somearray[signedvalue];

this seems almost criminal to how my brain does logic/C code.

The only thing i could think of is this:

somearray+=11; somearray[-1] // index set to somearray[10] ??

if i'd see my CPU execute that i'd want it to please stop. I'd want my compiler to shout at me like a little child, and be mean until i do better.

-Wall -Wextra -Wextra -Wpedantic <-- that should flag i think any of these weird practices.

As you stated tho, i'd be keen to learn why i am wrong!

> It makes sense that you should be able to assign a pointer to a size. If the size is signed, this cannot be done due to its smaller capacity.

Why?

By the definition of ptrdiff_t, ISTM the size of any object allocated by malloc cannot be out of bounds of ptrdiff_t, so I'm not sure how can you have a useful size_t that uses the sign bit?

"Naturally, sizes should be unsigned because they represent values which cannot be unsigned."

Unsigned types in C have modular arithmetic, I think they should be used exclusively when this is needed, or maybe if you absolutely need the full range.

Pointer arithmetic that could overflow would probably involve a heap and therefore be less likely to require a relative, negative offset. Just use the addresses and errors you get from allocation.

FWIW If you don't care about portability and target x64 you only get 48 bits worth of virtual address in the MMU.

That way my plan, but the committee had concerns about type safety.

This is intentional. But my idea for _Generic is to have

_Generic(x, int i: i + 1, float f: f + 1.);

where the i and f then have the correct type, so you do not need to refer to 'x' in those expressions.