Thanks
C-for-all: Extending C with modern safety and productivity features
41–50 of 143 posts
Re: C-for-all: Extending C with modern safety and productivity features
#42Obligatory name-drop: Zig is an awesome low level programming language targeting the same space as C and CForAll. It isn't at all compatible with C on the source level like CForAll is, but it does make it super easy to interop with C, because it can include .h files. That means it lets you move projects from C to Zig file-by-file. Because Zig benefits from decades of insights about how C could've been better, it has…
I second the props for Zig. It's basically a really well designed, trimmed down C with "compile time values" that, as an emergent phenomenon gets generics, and composable allocators. C interop is beautiful. My primary language is on the Erlang Virtual machine, and it's easier to write FFI using Zig than it is to write it in C.
Now that is an interesting combo.
Re: C-for-all: Extending C with modern safety and productivity features
#43Earlier quoted context omitted.
I don't know, I work in the games industry and we're currently building a small project that's probably 95% C(the only C++ we have is for one library that has to have a C++ wrapper). It's just.....we don't need the C++ features, the compilation times are instant(last project I worked on was a large AAA game in C++ and compiling it from scratch was about 40-50 minutes on a single workstation), and pretty much all libs…
Long compile times are almost always because of bad use of header files which include basically everything, insteda of only the used component. And this sometimes is because of bad separation of concersn / modularization.
As soon as you include C++ stdlib headers (even only for the stdlib features you're actually using), you have tens- to hundreds-of-thousands of lines of complex template code in front of your own code, and this in each compilation unit. In the end your own code is maybe one percent of all the code the C++ compiler needs to work through each time something is compiled (depending on how many source files you have, this is also why unity builds - merging all source files into one - are so much faster in C++).
In comparison, CRT headers (when compiled as C, not as C++, as in that case additional C++ bloat is added) are usually a few dozen to a few hundred lines of simple declaration code. Compared to C++, it's very hard to make a C project compile slowly.
Re: C-for-all: Extending C with modern safety and productivity features
#44Earlier quoted context omitted.
Long compile times are almost always because of bad use of header files which include basically everything, insteda of only the used component. And this sometimes is because of bad separation of concersn / modularization.
I used to agree with this, but having spent a while in a very good C++ project (by C++ standards), even if we try to always forward declare and not include any unnecessary headers in headers, we still have a clean debug build time of 30-40 minutes. Even changing a single line in a cpp file, will still take around 30-40 seconds at best with incremental builds. I think long compile times are in the eye of the beholder,…
Well said, I could not have said it better. Just to add, the productivity boost you get from short build times, in a long run, think of a project you work on for years, will out perform ANY gain you get from using a library, templates, and the like that kills your build time.
Re: C-for-all: Extending C with modern safety and productivity features
#45if safety is what they want without departing from C just use MISRA-C > While C++, like C∀, takes an evolutionary approach to extending C, C++'s complex and interdependent features (e.g., overloading, object oriented, templates) mean idiomatic C++ code is difficult to use from C, and C programmers must expend significant effort learning C++. the "significant effort" for learning C++ pays off (financially), while this…
MISRA-C is just a set of rules. It does not stop humans making stupid mistakes or ignoring rules, and causing safety to be violated.
It not as hard as rust where the binary is not built if a rule is violated.
Re: C-for-all: Extending C with modern safety and productivity features
#46Here's a snapshot from the Wayback Machine, given the original website is down https://web.archive.org/web/20181206232625/https://cforall.u...
Re: C-for-all: Extending C with modern safety and productivity features
#47I'm sure a lot of very smart people are working on this, and I don't want to detract from their dedication, but man this language looks like a mess. And in no small part because it wants to be backwards compatible with C (the reasoning is unconvincing -- why not just use C++?). In the age of Go and Rust, which already have a hard time finding niches, I don't really think there's any room for a language like this. And…
I remember seeing people from INRIA talking about CompCert (a formally verified C compiler http://compcert.inria.fr) and the main idea was that C was still the main language used in some critical application like aviation and military equipment.
This is why it was not rare to see defense company or Airbus financing those research.
Re: C-for-all: Extending C with modern safety and productivity features
#48if safety is what they want without departing from C just use MISRA-C > While C++, like C∀, takes an evolutionary approach to extending C, C++'s complex and interdependent features (e.g., overloading, object oriented, templates) mean idiomatic C++ code is difficult to use from C, and C programmers must expend significant effort learning C++. the "significant effort" for learning C++ pays off (financially), while this…
> use MISRA-C MISRA-C's idea of safety is banning function pointers.
actually that's not true. It's more complicated than that[1]:
---
Rule 104:
This is there to prevent the address of a function from being calculated at run time. i.e. the use of pointer arithmetic to calculate the value of a pointer to function is prohibited.
The reason is that an error in the calculation of the address could lead to a system failure.
Rule 105:
This is to ensure that a function pointer is only used to access functions that have the same return value type and formal parameter list. i.e. the type of the function pointer and the function to which it points must be the same.
The reason for this is to keep the use of the pointer consistent. If it is not, it is possible for the programmer to supply the wrong number of parameters when a function call is made, as it might not be clear which function the pointer is pointing at.
---
FWIW I have used function pointers twice in my career. From my personal experience you can improve readability by avoiding function pointers.
Re: C-for-all: Extending C with modern safety and productivity features
#49Earlier quoted context omitted.
I second the props for Zig. It's basically a really well designed, trimmed down C with "compile time values" that, as an emergent phenomenon gets generics, and composable allocators. C interop is beautiful. My primary language is on the Erlang Virtual machine, and it's easier to write FFI using Zig than it is to write it in C.
Now that is an interesting combo.
if that combination is interesting to you, this is what I'm working on (on the side from my main job):
Re: C-for-all: Extending C with modern safety and productivity features
#50I'm sure a lot of very smart people are working on this, and I don't want to detract from their dedication, but man this language looks like a mess. And in no small part because it wants to be backwards compatible with C (the reasoning is unconvincing -- why not just use C++?). In the age of Go and Rust, which already have a hard time finding niches, I don't really think there's any room for a language like this. And…
It's very confusing, they start off saying C++ is too complicated and then go basically reinventing C++ with (IMO) absolutely awful syntax.
I think they're missing the point of why people use C - there's no magic. It's pretty much the wysiwyg of high level -> asm. If you want a systems language with magic there's C++. If you want a safe one there's Rust.
Personally if I were going to make C better, I'd add a better macro/template feature so you don't have to write generic code as a define block with slashes all over, something like Go's defer, and some low level stack unwinding support. Maybe tuples as struts with numbered fields, but no magic syntax sugar. And that's it. No crazy operators, type theory things, or anything that doesn't do exactly what the code says. Because then it's not C.
But what do I know?