Does the StringView/Span implementation here seem lacking? If the underlying data goes away, wouldn't the pointer now point to an invalid freed location, because it doesn't track the underlying data in any way?
Giving C a superpower: custom header file (safe_c.h)
121–130 of 277 posts
Re: Giving C a superpower: custom header file (safe_c.h)
#122Earlier quoted context omitted.
Yes, plenty have been done already so since Lisp Machines, Smalltalk, Interlisp-D, Cedar, Oberon, Sing#, Modula-2+, Modula-3, D, Swift,.... It is a matter to have an open mindset. Eventually system languages with manual memory management will be done history in agentic driven OSes.
Swift, by design, does not have GC.
Chapter 5,
https://gchandbook.org/contents.html
It would help if all naysayers had their CS skills up to date.
Re: Giving C a superpower: custom header file (safe_c.h)
#123Intentionally or not, this post demonstrates one of the things that makes safer abstractions in C less desirable: the shared pointer implementation uses a POSIX mutex, which means it’s (1) not cross platform, and (2) pays the mutex overhead even in provably single-threaded contexts. In other words, it’s not a zero-cost abstraction. C++’s shared pointer has the same problem; Rust avoids it by having two types (Rc and…
> the shared pointer implementation uses a POSIX mutex
Do you have a source for this? I couldn't find the implementation in TFA nor a link to safe_c.h
Re: Giving C a superpower: custom header file (safe_c.h)
#124Earlier quoted context omitted.
You can use GCC on MS Windows just fine. Installing MSYS2 will also give you a package manager.
Yes, of course. Unfortunately, sometimes you need to link to Windows binaries and therefore need to compile against the Windows ABI.
From https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
> -mabi=name Generate code for the specified calling convention. [...] The default is to use the Microsoft ABI when targeting Microsoft Windows and the SysV ABI on all other systems.
> -mms-bitfields Enable/disable bit-field layout compatible with the native Microsoft Windows compiler. [...] This option is enabled by default for Microsoft Windows targets.
Doesn't this work in practice, due to bugs?
Re: Giving C a superpower: custom header file (safe_c.h)
#125Earlier quoted context omitted.
Because about 99% of the time the garbage collect is a negligible portion of your runtime at the benefit of a huge dollop of safety. People really need to stop acting like a garbage collector is some sort of cosmic horror that automatically takes you back to 1980s performance or something. The cases where they are unsuitable are a minority, and a rather small one at that. If you happen to live in that minority, great…
> Because about 99% of the time the garbage collect is a negligible portion of your runtime In a system programming language?
Whether or not GC is a negligible portion of your runtime is a characteristic of your program, not your implementation language. For 99% of programs, probably more, yes.
I have been working in GC languages for the last 25 years. The GC has been a performance problem for me... once. The modal experience for developers is probably zero. Once or twice is not that uncommon. But you shouldn't bend your entire implementation stack choice over "once or twice a career" outcomes.
This is not the only experience for developers, and there are those whose careers are concentrated in the places where it matters... databases, 100%-utilization network code, hardware drivers. But for 99% of the programs out there, whatever language they are implemented in, GC is not an important performance consideration. For the vast bulk of those programs, there is a much larger performance consideration in it that could be turned up in 5 minutes with a profiler and nobody has even bothered to do that and squeeze out the accidentally quadratic code because even that doesn't matter to them, let alone GC delays.
This is the "system programmer's" equivalent of the web dev's "I need a web framework that can push 2,000,000 requests per second" and then choosing the framework that can push 2,001,000 rps over the one that can push 2,000,000 because fast... when the code they are actually writing for the work they are actually doing can barely push 100 rps. Even game engines nowadays have rather quite a lot of GC in them. Even in a system programming language, and even in a program that is going to experience a great deal of load, you are going to have to budget some non-trivial optimization time to your own code before GC is your biggest problem, because the odds that you wrote something slower than the GC without realizing it is pretty high.
Re: Giving C a superpower: custom header file (safe_c.h)
#126Intentionally or not, this post demonstrates one of the things that makes safer abstractions in C less desirable: the shared pointer implementation uses a POSIX mutex, which means it’s (1) not cross platform, and (2) pays the mutex overhead even in provably single-threaded contexts. In other words, it’s not a zero-cost abstraction. C++’s shared pointer has the same problem; Rust avoids it by having two types (Rc and…
Unfortunately, for C++, thats not true. At least with glibc and libstdc++, if you do not link with pthreads, then shared pointers are not thread-safe. At runtime it will do a symbol lookup for a pthreads symbol, and based off the result, the shared pointer code will either take the atomic or non-atomic path.
I'd much rather it didnt try to be zero-cost and it always used atomics...
Re: Giving C a superpower: custom header file (safe_c.h)
#127Earlier quoted context omitted.
MSVC now supports C17.
MSVC is also made out of a dozen javascript processes which makes typing text need a beefy computer.
MSVC is a C++ compiler toolchain and it does not contain any JavaScript. You're thinking of VSCode, probably, but your comment was an off-topic rant either way.
Re: Giving C a superpower: custom header file (safe_c.h)
#128This reminds me that Scott Meyers (IMO rightfully) considered the destructor as the single most important fearure in C++.
I too enjoy space leaks on recursion
Re: Giving C a superpower: custom header file (safe_c.h)
#129C++: "look at what others must do to mimic a fraction of my power" This is cute, but also I'm baffled as to why you would want to use macros to emulate c++. Nothing is stopping you from writing c-like c++ if that's what you like style wise.
Embedded CPU vendors not shipping C++ compilers is what usually stops people.
Yup. And I like the implication that Rust is 'cross platform', when it's 'tier 1' support consists of 2 architectures (x86 & arm64). I guess we're converging on a world where those 2 + riscv are all that matter to most people, but it's not yet a world where they are all that matter to all people.
[1] https://doc.rust-lang.org/beta/rustc/platform-support.html
Re: Giving C a superpower: custom header file (safe_c.h)
#130I feel like there might be some value in this header file for some projects, but this is exactly the wrong use case. > In cgrep, parsing command-line options the old way is a breeding ground for CVEs and its bestiary. You have to remember to free the memory on every single exit path, difficult for the undisciplined. No, no, no. Command line options that will exist the entire lifetime of the program are the quintessen…
shouldn't be individually allocated either, arenas for the win