Does this have implications for low-level backdoors/exploits?
You mean like the Americans did with Cisco? I am not really in a mood to defend the chinese regime, but the “free” West really threw away any moral high ground we might have had.
C-for-all: Extending C with modern safety and productivity features
21–30 of 143 posts
Re: C-for-all: Extending C with modern safety and productivity features
#22I'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 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.
Re: C-for-all: Extending C with modern safety and productivity features
#23Does this have implications for low-level backdoors/exploits?
In the same way the fact that Microsoft is a US company has implications on backdoors/exploits and Windows. Except C for all is Open Source, so you can go check.
Re: C-for-all: Extending C with modern safety and productivity features
#24It’s interesting how “evolutionary approach” is used. Compare with C2: http://www.c2lang.org/
I think that in the case of C2 it’s still a language that will rely on the same paradigms as C, whereas C-for-all is more of a “kitchen sink” style of language that moves very far from C in how the natural code solutions are. Just the small change adding destructors and constructors is a feature with huge impact on how data will be managed (for better and for worse)
(Full disclosure: I have contributed to C2 in the past and I’m working on the C3 lang which is feature and syntax-wise based on C2 but goes further: https://www.c3-lang.org )
Re: C-for-all: Extending C with modern safety and productivity features
#25if 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…
You quoted the key point: "idiomatic C++ code is difficult to use from C": most C++ libraries are useless in C programs.
They want the productivity improvement of C++ without leaving behind 2-way compatibility.
Re: C-for-all: Extending C with modern safety and productivity features
#26Does this have implications for low-level backdoors/exploits?
You mean like the Americans did with Cisco? I am not really in a mood to defend the chinese regime, but the “free” West really threw away any moral high ground we might have had.
Just because the west also can't necessarily be trusted not to try to sneak exploits into sponsored projects (or through other means, such as a snail mail MITM) doesn't mean we shouldn't ask the question of other countries as well.
Whataboutism is never the correct answer to a valid concern (in general. I'm not sure if there's much to worry about in this specific case or not).
Re: C-for-all: Extending C with modern safety and productivity features
#27Earlier 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.
I'm yet to see a C++ project that compiles as fast as a C one.
Re: C-for-all: Extending C with modern safety and productivity features
#28Obligatory 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…
Another (agruably better) option is to use Dlang's betterC feature.
Re: C-for-all: Extending C with modern safety and productivity features
#29Earlier 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.
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, but often it feels like people have just gotten used to unnecessarily long compile times because they've forgotten how fast computers are and how fast a compiler should be for most of the work except for maybe some of the more complex optimizations in -O3.
It kills productivity, and should really be a much larger focus than it sometimes seems to be.
Re: C-for-all: Extending C with modern safety and productivity features
#30Could someone expand on why Rust "isn't a systems language"?
I think that assertion muddles their argument. Their key points seem to be that Rust (and other existing languages) lack backwards compatibility and have different memory management strategies. Lumping Rust in with GC languages is confusing. Whether either of those things matter is another story. From using TypeScript, I'm personally inclined to believe that a superset of a difficult language can't solve all of the u…
All memory allocations in Rust follow a `malloc`-like API that ends up calling `malloc` and similar at some point.