Re: C23 thoughts and opinions

On 6/4/2024 12:17 AM, Kaz Kylheku wrote:

On 2024-06-03, Scott Lurndal <scott@slp53.sl.home> wrote:

At the time, in the OS research community, Chorus was, indeed well-known.

 If Chorus at least doesn't vaguely ring a bell, you must have your head
up your ass as even a bachelor-level computer scientist.
 

FWIW: When I was going to college for a CS major, the emphasis was mostly on Microsoft technologies, and a lot of the classes were taught in C#. I mostly stuck with C for my own uses though (and IIRC did write one class project in C++/CLI).
No mention of projects like Chorus, and relatively little even for Linux. But, if you wanted classes to cover things like "Interface with SQL Server via C# and LINQ", yeah, they did have this...
Granted, C# wasn't a bad language per-se (and more useful than VB.NET), main obvious downsides being that the garbage collector and dependence on the .NET runtime are hindrances for many use-cases.
I did clash a few times with the teachers for my (kinda open) preference for non-"Managed" languages (like C and similar). Or, the implication that people might want to use or develop for non-Windows operating systems (or, random other conflicts, like at the time people not approving of my use of a custom-written JPEG loader rather than the one in the .NET API, ...).
Though, did switch over to using MS tools for Windows development (mostly MSVC), mostly because they were less crappy at the time than Cygwin (which I had been using since around 7th/8th grade or so; also at the time Cygwin did not support Win64 so could only build 32-bit programs, which MSVC did, and this was also around the time Visual Studio was effectively becoming freeware).
Don't really know what things are like now, as all this was many years ago.
In one of my own languages (created some years later, sorta resembling a Java/C#/AS3 hybrid), I mostly went over to a combination of manual memory management, automatic memory management, and a zone allocator (memory objects are keyed to a zone, and the zone can be used to bulk free any objects it "contains", and in theory the zones could also be organized into a tree, where freeing a top-level zone would also free any objects in sub-zones).
In my current project, similar also sort of applies to my C compiler, but in slightly debatable ways.
Like, say, the compiler does sort-of support C99 VLAs, but internally they are (like in my other language) internally heap-allocated and freed automatically when the parent function returns, mostly by adding them to a hidden linked list, and freeing everything in the linked list on function return.
But, a few advantages over a more traditional GC:
   Lower overhead;
   No unpredictable / random GC stalls;
   ...
In some contexts, implicit heap allocations are not ideal, but mostly easily avoided. Ironically, with my projects putting VLA's (or alloca's) on the stack would be in some ways worse (I am also tending to use a default stack size of 128K, trying to put largish arrays on the stack will blow out the stack much faster than typical recursion will, so if any large arrays or VLAs are folded to the heap, having a 128K stack is generally sufficient; though a 64K stack is still pushing it for many programs).
Similar can also be applied to by-value structs, where trying to pass a large struct by-value may turn it into implicit heap allocation and memcpy (and internally my ABI passes and returns structs by reference for anything larger than 16 bytes, so, ...).
As for C vs C++:
   When I was starting out:
     C and GCC generally always worked fine;
     C++ and G++ was prone to immediately die in a storm of error messages (not even trivial "hello world" style programs would work).
After that, nearly every time I "could" have used C++ was counter-balanced by other drawbacks for why not to use C++ (and what merits C++ would have had, being not enough to counter-balance the issues associated with using it).
C mostly still works. And, even in my own language design efforts, kinda hard to beat, as "language that is not C" still has more hassle than "language that is C" even when both are using the same compiler, runtime, and ABI (so effectively one can do cross-language calls mostly by the use of function prototypes).
Pretty much any code I want to port over is C, so C remains the most natural choice.
Though, I do have some questionable experimental features, like a compiler option to cause arrays and pointers to be bounds-checked, which is sometimes useful in debugging (but in some cases can add bugs of its own; also makes the binaries bigger and negatively effects performance, ...).
...