sigsev_251

> Outdated documentation is pretty normal unfortunely, even .NET suffers from that nowadays.

That's really unfortunate.

> Not as bad as Apple nowadays though, quite far from Inside Inside Macintosh days.

Funny story, I know a guy who wanted to write a personal Swift project for an esoteric spreadsheet format and the quality of the documentation of SwiftUI made him ragequit. After that, he switched to kotlin native and gtk and he is much happier.

> Personally, I think that with the improvements on low level coding and AOT compilation from managed languages, we are reaching local optimum, where C and C++ are good enough for the low level glue, C23 and C++23 (eventually C++26 due to static reflection) might be the last ones that are actually relevant.

I agree on the managed language thing but, I mean, the fact that other languages are getting more capable with low level resources does not mean that improvements in C/C++ are a bad idea and will not be used. In fact, I think that features like the transcoding functions in <stdmchar.h> in C2y (ironically those are relevant to the current HN post) are useful to those languages too! So even if C, C++ and fortran are just used for numerical kernels, emulators, hardware stuff, glue code and other "dirty" code advancements made to them are not going wasted.

I think the documentation is outdated given that C11 atomics [1] and threads [2] are available for more than a year now. Same goes for pretty much everything MSVC frontend related stuff (I've yet to try which C++23 features are supported at the moment, but they've secretly added support for C23 features like typeof and attributes, as well as GNU Statement Expressions).

[1]: https://devblogs.microsoft.com/cppblog/c11-atomics-in-visual...

[2]: https://devblogs.microsoft.com/cppblog/c11-threads-in-visual...

Why would you need multiple allocations?

edit: Isn't it just:

  float (*arr)[m][n] = malloc(sizeof(*arr));

Yes, but is one allowed to move a pointer inside it as they see fit? On a one-dimensional array, one can iterate through it starting with a pointer pointing to the first element and ending with a pointer pointing one position past the last element (which the user is not allowed to dereference). For multidimensional arrays, the element type is an array too (with a smaller rank than the original one), so one could perform that type of iteration with a pointer to an array. My question is whether a pointer to the underlying scalar type can freely move inside the multidimensional array without UB, since it may have to actually leave the array it was originally part of. If that's not allowed, how could one build slices and other view types?

Are C multidimensional arrays guaranteed to be contiguous in memory? In practice they are, but can one iterate through them just by incrementing a pointer which points to the first element without UB?

Thank you!

Do you happen to have any source/book on why you can't use anything but a conservative gc on C-like languages? I would really like to know why that's the case.

There is a compatibilty chart: https://www.graalvm.org/python/compatibility/

There is always qbe if you need something simpler

> At least it does generics now

Not in gccgo

Maybe cranelift will help with this. Faster compile times is one of its selling points.

> using LLVM backends

Wait, there is an LLVM based Go toolchain? I thought the Go crowd was known for their NIH obsession.

- Though freeware and not foss, there is also pellesc over at Windows land, with almost full C23 support.

- For small 8 bit systems, SDCC is an excellent choice, supporting even C23 features! Also its lead maintainer is a committee member with really useful contributions to the standard.

- I have heard the RiscOS compiler is pretty cool and supports modern standards. That one uses the Norcroft frontend.

I agree with you in that we need a production level C compiler written in C. Though that is not a simple task and the C community nowadays prefers to engage on infighting over pedantic issues or rust rather than working together. A simple example of this is the lack of a modern library ecosystem, while everyone and their mother has their own custom build system. Even though C is sold as a performant language, there isn't a single parallelism library like OneTBB, Kokkos or HPX over at C++. Don't get me started on vendors not offering good standard support (Microsoft, macos-libc, OpenBSD libc)...

One correction though, cparser uses libfirm as a backend, not qbe. Also the author of chibicc has stopped writing that book AFAIK.

Bonus non-c based entries: - The zig community is working on arocc. Judging by the awesomeness of zig cc, these are really good news. - Nvidia offers their EDG based nvc with OpenACC support for free these days, which is cool.

Edit: formatting

A possible answer is that one could modify n inside the function body, which means that the length is lost. But honestly, one could just use const to avoid this. Though, pointers to VLAs are really useful and convenient when allocating dynamic arrays, especially multidimensional.

I get what you mean and I'm not saying that not having extra operators is a dealbreaker that will make spans unusable. I just find it more pleasant/convenient for the following reasons: 1. Helps clarify intent 2. Makes teaching the feature easier, since it's name is closer to what the user wants to write. Also, rejecting pointers helps people not make mistakes. 3. Keeps sizeof consistent. The operator sizeof is supposed to return the size of the storage occupied by the object. A span is a pointer and some sizes (one could also design a span to be strided, meaning more integers to the mix), so sizeof could just return the size of that pointer ond the integers. Having sizeof be somewhat overloaded for spans could be surprising to nome people. But again, just having sizeof is fine

Very nice comment. This was a blocking point I fell onto too. There is another option, to not allow spans on the return channel, but I don't know how people who handle resources with lifetimes that exceed the function scope will take this. Just like you, I'm curious to see what how this will be solved.

(Just to be clear, I am not the author of the draft I posted in the parent comment, but it's the feature I want the most to be added in C2y. I was actually meaning of writting a proposal, but realized that I don't know a thing about compilers and language design.) I have examined many other ways one could add such functionality in C. I found that the most pleasant one is a combination of your syntax and some runtime operators to retrieve the length. As for the lack of implementation burden, I would send an email to thephd in your position. I think that having that comment coming from you would be really beneficial for the paper.

Not a glsl or hlsl compiler, but there is a C compiler that targets spirv and is written in C. Here's the repo: https://github.com/heroseh/hcc

With all respect, please don't say nobody cares. There many people in the C community that want this but it's not easy to add a fat pointer to C after all these years. Though, there are people who are planning to work on this exact solution [1]. The best thing the rest of the ecosystem can do, is support them.

[1]: https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Non-own...

Michaelforney has also built croc [1], a qbe based C compiler. Really impressive!

[1]: https://github.com/michaelforney/cproc

Curious, why do you think Rust does not look like a better C++ (in the sense of not making the mistakes of it)? Is there something you find impractical?

Aviation would be my personal experience. We have to implement services on the aircraft for structured communication support with the ground tower. Those would really benefit from something like that, since we wouldn't have to implement a backend for every project and we could simply reuse the whole library everywhere.

Because there are platforms with no, or really buggy C++ support.

Isn't the gcc-ia16 more of a cross-compiler for embedded systems?

I mean, _Generic is usually hidden behind a macro anyways, so it doesn't really show up in you text file all that much.

Generic libraries. There are programming domains in the embedded world where code reuse can shorten the development timeline in a significant way, which gives engineers more time to test and verify.