Earlier quoted context omitted.
https://www.musl-libc.org/
That doesn't fix the issues mentioned. (Whether it's an "alternative" stdlib for C is debatable; nobody ever said that glibc is "the" stdlib for C…)
It is the de facto standard on Linux.
C-for-all: Extending C with modern safety and productivity features
71–80 of 143 posts
Re: C-for-all: Extending C with modern safety and productivity features
#72Earlier quoted context omitted.
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.
You can't say "one is bad, therefore the other is good." They can both be bad.
In which case you shouldn't paint one as the exceptional evil for doing the same thing, as is usually the case.
Re: C-for-all: Extending C with modern safety and productivity features
#73Earlier quoted context omitted.
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).
>Whataboutism is never the correct answer to a valid concern
I'd say it is. I puts the concern in perspective, and stops people from using it to paint the "enemy" (anybody that's not them/their government) as particularly evil for doing the same thing the other side does.
Re: C-for-all: Extending C with modern safety and productivity features
#74It started out so great, but at the end I was left with the impression that someone was just trying to shoehorn features into C with quirkier syntax than C++. That type declaration syntax will probably haunt me in my sleep.
Re: C-for-all: Extending C with modern safety and productivity features
#75Earlier quoted context omitted.
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 m…
> C - there's no magic Strict aliasing and weak typing say hello. > wysiwyg of high level -> asm Except neither GCC nor Clang compile even remotely predictable ASM. It's easier to predict OCaml assembly output than the GCC's one.
How is strict aliasing magic? How could you possibly define the meaning of accessing an object through an incompatible type since the type of an object determines how the compiler interprets its value? The bits stored in the object do not even necessarily correspond to a value for every type, after all. And that's not even considering the fact that there is a great deal of freedom wrt how implementations can represent floating point numbers, etc. so how can the standard impose a requirement on what happens when you, say, access a double as an int?
What do you mean by weak typing? That can you cast away basically anything?
>It's easier to predict OCaml assembly output than the GCC's one
Surely you are kidding. If that were true, why doesn't OCaml curb-stomp C in benchmarks? IMO GCC's output isn't even a little surprising, esp. once you've gained experience with its favorite optimizations.
Re: C-for-all: Extending C with modern safety and productivity features
#76Earlier quoted context omitted.
Who owns the return value of new_point?
The function that calls `new_point`, the value is moved. Similarly, consider the following case. struct Point a = new_point(); struct Point a2 = a; Assuming `struct Point` has a destructor, this would move `a` into `a2`, and prevent accesses to `a` after `a2` assignment, as `a` is no longer considered to be alive at this point. C++ has a wrong default of cloning instead of moving, but a new language could fix that.
So you’re looking for Rust with C’s syntax?
Re: C-for-all: Extending C with modern safety and productivity features
#77Earlier quoted context omitted.
Who owns the return value of new_point?
The function that calls `new_point`, the value is moved. Similarly, consider the following case. struct Point a = new_point(); struct Point a2 = a; Assuming `struct Point` has a destructor, this would move `a` into `a2`, and prevent accesses to `a` after `a2` assignment, as `a` is no longer considered to be alive at this point. C++ has a wrong default of cloning instead of moving, but a new language could fix that.
Why is cloning rather than moving the wrong default?
Re: C-for-all: Extending C with modern safety and productivity features
#78Earlier 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,…
We use Delphi at work, just did a full rebuild of our core product, 978015 LOC compiled and linked in 22 seconds on my aging i7 4790k.
Re: C-for-all: Extending C with modern safety and productivity features
#79I’m very surprised that no one here has mentioned the Cyclone language[0] yet. It seems to me that it tried to address the same niche as C-for-all. [0] https://cyclone.thelanguage.org
> Cyclone is no longer supported
This might be the reason.
Re: C-for-all: Extending C with modern safety and productivity features
#80Earlier quoted context omitted.
Who owns the return value of new_point?
The function that calls `new_point`, the value is moved. Similarly, consider the following case. struct Point a = new_point(); struct Point a2 = a; Assuming `struct Point` has a destructor, this would move `a` into `a2`, and prevent accesses to `a` after `a2` assignment, as `a` is no longer considered to be alive at this point. C++ has a wrong default of cloning instead of moving, but a new language could fix that.
> C++ has a wrong default of cloning instead of moving
Which it inherited from C.