sigsev_251 (u/sigsev_251)

sigsev_251 commented on WorstFit: Unveiling Hidden Transformers in Windows ANSI blog.orange.tw/posts/2025... · Posted by u/notmine1337

pjmlp · 8 months ago

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

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

Glad to know about C23 features, as they went silent on C23 plans.

C++23 looks quite bad for anything that requires frontend changes, there are even developer connection issues for us to tell what to prioritise, as if it wasn't logically all of it. There is another one for C++26 as well.

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.

Similar to how although COBOL and Fortran standards keep being updated, how many ISO 2023 revision compliant compilers are you going to find out for portable code?

sigsev_251 · 8 months ago

> 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.

sigsev_251 commented on WorstFit: Unveiling Hidden Transformers in Windows ANSI blog.orange.tw/posts/2025... · Posted by u/notmine1337

pjmlp · 8 months ago

Mostly C99 compliant, some things are left out.

https://learn.microsoft.com/en-us/cpp/c-runtime-library/comp...

sigsev_251 · 8 months ago

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...

sigsev_251 commented on Some programming language ideas jerf.org/iri/post/2025/pr... · Posted by u/todsacerdoti

krapp · 8 months ago

Yes, you can do that, it's fine as long as you stay within the bounds of the indexes. Under the hood, it's a single contiguous block of memory.

Although at least with 2d arrays I prefer to just use a 1d array and index it with [x * width + y], because one problem with multidimensional arrays in C is they need multiple allocations/frees.

sigsev_251 · 8 months ago

Why would you need multiple allocations?

edit: Isn't it just:

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

sigsev_251 commented on Some programming language ideas jerf.org/iri/post/2025/pr... · Posted by u/todsacerdoti

krapp · 8 months ago

Yes. All arrays in C are contiguous. Multidimensional arrays are just arrays of arrays, and are therefore also contiguous.

Source: https://stackoverflow.com/questions/36647286/are-c-multidime...

sigsev_251 · 8 months ago

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?

sigsev_251 commented on Some programming language ideas jerf.org/iri/post/2025/pr... · Posted by u/todsacerdoti

uecker · 8 months ago

C has arrays with more than one dimension. (but no direct support for strides). Of course, it is just the same thing as arrays of arrays.

sigsev_251 · 8 months ago

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?

sigsev_251 commented on The Swift compiler is slow due to how types are inferred danielchasehooper.com/pos... · Posted by u/paraboul

pjmlp · a year ago

Basically C semantics are to blame, due to the way C was designed, and the liberties it allows its users, it is like programming in Assembly from a tracing GC point of view.

Meaning that without any kind of metadata, the GC has to assume that any kind of value on the stack or global memory segments is a possible pointer, but it cannot be sure about it, it might be just a numeric value that looks like a valid pointer to GC allocated data.

So any algorithm that needs to be certain about the exact data types, before moving the wrong data, is already off the table in regards to C.

See https://hboehm.info/gc/ for more info, including the references.

sigsev_251 · a year ago

Thank you!

sigsev_251 commented on The Swift compiler is slow due to how types are inferred danielchasehooper.com/pos... · Posted by u/paraboul

pjmlp · a year ago

To add to the GC discussion, something that many that weren't around during the GC project failure for Objective-C, is that ARC was pivot from a failed project, but in good Apple fashion that had to sell the history on their own way.

The GC for Objective-C failed, because of the underlying C semantics, it would never be better than a typical conservative GC, and there were routinely application crashes when mixing code compiled with GC and non-GC options.

Thus they picked up the next best strategy, which was to automate the Cocoa's retain/release message pairs, and sell that as being much better than GC, because performance and such, not because the GC approach failed.

Naturally, as proven by the complex interop layer in .NET with COM, given Objective-C evolution, it would also be much better for Swift to adopt the same approach, than creating a complex layer similar to CCW/RCW.

Now everyone that wasn't around for this, kind of believes and resells the whole "ARC because performance!" story.

sigsev_251 · a year ago

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.