True but its very clumsy for large number of parameters. Even more importantly, its not forward compatible. For example, cbrt() cant reliably expanded to support bigints or any private types.

This is typical of software development projects - the "new" replacement wants to kill off the old one so cannot have any improvements happening to the old one. If the new ones are so great though .....

I suspect that quite a lot of maintainers of code don't want to rewrite it particularly and quite a lot of people upstream of that don't want to re-integrate everything to use something new.

So little improvements that can be taken a bit at a time are fantastic.

It's already frozen and the replacement is already there. It's Rust. (Yes there are other competitors, but unless a large shift happens, Rust has won¹´⁴.)

The intent of maintaining C is to help maintain the shittons of existing C code. Even if people were to immediately start rewriting everything, it'd take a decade or two until most things have a replacement. And you still need to maintain and update things until then. There's enough work to think about making that task better - especially for safety concerns, like we're talking about here.

(And, yeah, sunk cost and whatnot… especially if you're making a commercial product, a rewrite is a hard sell and a lot of C code will live far longer than we all wish. It'll be the COBOL of 2077, I suspect.)

¹ "high-level" C code has a lot of other options and probably shouldn't have been written in C to begin with. For low-level C code, Rust is the most suitable² and popular option, everything else is significantly behind (in popularity/usage at least). That might of course change, but for the time being, it is Rust and Rust is it³.

² this doesn't mean Rust is specifically targeted at or limited to low-level things, it just does them quite well and is a good slot-in for previous C uses.

³ of course C++ was supposed to be "it" the entire time, but at least as far as I'm personally concerned, C++ is a worse disaster than C and needs to be replaced even more urgently.

⁴ I'm aware Zig exists. Call me when it reaches some notable fraction (let's say ⅓) of Rust's ratings on the TIOBE index.

> I mean, most of C just compiles as C++ and does the right thing.

In my experience, unless you’re strictly talking about header files (which I’m assuming you’re not), C code compiling via C++ compilers is usually hit or miss and highly dependent on the author of the C code having put in some effort into making sure the code actually compiles properly via a C++ compiler.

In the overwhelming majority of cases, what lots of folks do is just slap that `extern "C"` in between `#ifdef __cplusplus` and call it a day—that may work for most forward declarations in header files, but that’s absolutely not enough for most C source files.

By the way, a great example of C code that does this exceptionally well is Daan Leijen’s awesome mimalloc [0]—you can compile it via a C or C++ compiler and it simply just works. It’s been a while since I read the code, but when I did, it was immediately obvious to me that the code was written with that type of compatibility in mind.

[0]: https://github.com/microsoft/mimalloc

There are pretty fundamental differences in key areas, like zero initialization of a struct or array (`{0}` vs `{}`). Use the C way in C++ and you only 0 the first element or member. Use the C++ way in C and you don't 0 anything.

IMO there's no point even attempting a blind recompile of C as C++. A transpiler tool would be needed.

We could fire WG14 and add Walter Brights fix for passing arrays, buffer and slice types. Add phat pointers and types as fist class objects.

If you did that and implemented marking passing size info over function calls then you could probably mechanically convert crappy foo(void *buf, int sz) code to foo(slice_t buf) which would be a lot safer to maintain.

> I mean, most of C just compiles as C++

You're asking about old C code - that code won't compile as C++. And newer C code would likely also be cleaner and not benefit much from being compiled as C++.

(And, C++ is a net negative over C anyway due to much poorer reviewability.)

> most of C just compiles as C++

um, not unless explicitly written to so.

The ABI for C++ is a disaster. That alone would doom such a conversion.

Go does monomorphization in a rather useless manner from a performance perspective because all pointers/interfaces are essentially the same "shape". Hence you still have no inlining and you do not avoid the virtual function when any interfaces are involved as detailed in https://planetscale.com/blog/generics-can-make-your-go-code-...

C++ fully monomorphizes class/function templates, and therefore incurs 0 overhead while unlocking a ton of inlining, unlike Go.

The example you gave is the most trivial one possible. There is 0 reason to write that code over PrintAnything(item Stringer). Go doesn't even let you do the following:

  auto foo(auto& x) { return x.y; }

  package main

  import "fmt"

  func foo[T any, V any](x T) V {
     return x.y
  }

  type X struct {
       y int
   }

  func main() {
       xx := X{3}
       fmt.Println(foo[*X, int](&xx))
   }

Not to mention Go's generics utterly lack metaprogramming too. I understand that's almost like a design decision, but regardless it's a big part of why people use templates in C++.

It isn't though. C++ templates are duck-typed. Structural typing is two structs with the same structure are the same type. Duck typing is when you check if it has a quack field.

For a template like this:

    template<typename T> T max(T &a, T &b) { return a > b ? a : b; }

C++ templates get incredibly complex, but at no point is the type system structural. You can add a series of checks which amount to structural typing but that isn't the same thing at all.

I agree that the debugging and maintenance experience is much better that way, but it comes at the cost of very poor "DX". We, discussing this here on this thread, understand what's going on. But sadly at least for the projects I'm involved in, the average developer does not.

TBH, rather than fancy high-meta generic support, I'd be much more appreciative of ISO C adding something like "_Include" to the preprocessor, e.g.

  #define DEFINE_MY_WRAPPER(foo, bar) _Include("wrapper.h")
  /* "foo", "bar" remain accessible in wrapper.h */

P.S.: I ended up doing this https://github.com/FRRouting/frr/pull/15876/files#diff-90783... instead; a tool that can be invoked to expand some DEFINE_FOO if needed for debugging. It's not used particularly often, though.

I wrote a blogpost describing this technique. https://www.davidpriver.com/ctemplates.html

That's true, although I wonder if a "sufficiently smart compiler" could combine compatible definitions. Also note it's in a header file and most of these functions are minimal enough they would be inlined.

Sort of. If you want the instantiation model, you can go with forwarding functions (maybe preprocessor instantiated):

    void malloc_stack_drop(void *s) {
      stack_drop(&malloc_stack_global, s);
    }

Absolutely agreed that this is working around a lack of compiler hook. The interface I want for that is an attribute on a parameter which forces the compiler to specialise with respect to that parameter when it's a compile time constant, apply that attribute to the vtable argument. The really gnarly problem in function specialisation is the cost metric, the actual implementation is fine - so have the programmer mark functions as a good idea while trying to work out the heuristic. Going to add that to my todo list, had forgotten about it.

    fn genericReduceTypeErased(
        size: usize,
        total: [*]u8,
        list: []const u8,
        reducer: *const fn(total: [*]u8, current: [*]const u8) callconv(.C) void,
    ) void {
        for(0..@divExact(list.len, size)) |i| {
            const itm = &list[i \* size];
            reducer(total, @ptrCast(itm));
        }
    }

    inline fn genericReduce(
        comptime T: type,
        total: *T,
        list: []const T,
        reducer: *const fn(total: *T, current: *const T) callconv(.C) void,
    ) void {
        genericReduceTypeErased( @sizeOf(T), @ptrCast(total), std.mem.sliceAsBytes(list), @ptrCast(reducer) );
    }