271–280 of 388 posts
Finally an article I can agree with. C is great mostly because it's easy to learn, and it has many other advantages. I dislike all those new languages because they have too many features, and they're non trivial to learn. I've looked at some rust codebases and I don't think there will be a lot of people who will want to maintain them. Rust is difficult, even though it's an awesome language. A language that could comp…
Go?
Earlier quoted context omitted.
unique_ptr is pretty bad for performance as well. It is more complicated to use compared to raw pointers and encourages an OOP object-per-object piecemal code and data architecture. I've never seen a C++ program making use of unique_ptr that didn't give a strong smell of enterprise programming.
Use correctly std::unique_ptr has no measurable impact on performance compared with the equivalent non-smart-pointer code. You use std::unique_ptr to indicate ownership, and pass raw pointers around to indicate non-ownership. That approach has the strong smell of a good programmer using the right tool for the job, especially considering the job is to communicate intent to the future reader. It's like the classic argu…
As a C programmer, I try to avoid tracking ownership in separate struct member fields. I try to make central data structures that keep care of the tracking. Cleaning up shouldn't happen pointer-by-pointer. Usually a much bigger context has a shared lifetime, so there is no point in splitting stuff up in individually tracked "objects". Instead you just track a bigger block of memory.
Earlier quoted context omitted.
Precisely. This is perhaps the strangest part of the original post: C++ has the same performance advantages as Rust! It has them not because it's more safe (although it is, in some regards), but because it allows programmers to express behaviors that the compiler can reason about statically.
Interesting. Can you list an example of C++ type system allowing optimization Rust system doesn't?
You obviously ideally want both, but that's not actually possible when you have a language this powerful. So, Rest's choice means sometimes (more rarely these days but it can happen) you will write a program that is correct, but the compiler doesn't believe you and rejects your program, you will need to alter it, perhaps after alterations it's actually nicer, but equally perhaps you feel this made it uglier or slower, nevertheless you have no choice in Rust (well, you could try waiting a few years, the compiler gets smarter)
However the C++ choice means sometimes (maybe even often) you will write a program that isn't correct and the compiler gives you no indication whatsoever that there's a problem, you get an executable or object file or whatever out, but what it does is completely arbitrary. Maybe it works how you expected... until it doesn't.
The magic phrase in the C++ standard is "Ill-formed, no diagnostic required". For example suppose you try to sort some floats in C++ 20. That's ill-formed (floats aren't in fact Totally Ordered but the function signature says you promise they are) and no diagnostic is required for... whatever it is your program now does. Maybe it crashes, maybe it works fine, not their problem, good luck with that.
Now, probably if all your floats are like boring normal finite reals like -2.5 or something this will work fine, there's no practical reason it wouldn't, but who knows, the C++ language denies all responsibility. So it gets to be very "optimal" here since it can do whatever it wants and it's your fault.
Wow, this blog entry's reasoning is a leaky ship. 1. C language toolchain -- No specifics (save static analyzers, ... because C needs static analyzers to catch C specific bugs...). What do you actually feel you're missing? Most of these "new C" languages use the same backend as a C compiler. What can't you use? 2., 3., and 4. -- Just chicken and egg FUD. Not to mention it's "'Better X' doesn't matter" fundamentally d…
> What do you actually feel you're missing? It explicitly says in the post... for example static analyzers. What is the "Frama-C" equivalent of any language that bills itself as a replacement / competitor of C? > Most of these "new C" languages use the same backend as a C compiler. Most of them use LLVM as far as I know, which does not target plenty of obscure platforms.
Earlier quoted context omitted.
> Modern C++ also discourages raw pointers and so you get references counters all over the place, essentially turning C++ into a garbage collected language. This doesn't match my experience. It's true that modern C++ discourages owning raw pointers, but the solution is usually unique_ptr, not shared_ptr. Truly shared ownership is actually pretty uncommon IME, usually you can have one entity which obviously "owns" the…
unique_ptr is pretty bad for performance as well. It is more complicated to use compared to raw pointers and encourages an OOP object-per-object piecemal code and data architecture. I've never seen a C++ program making use of unique_ptr that didn't give a strong smell of enterprise programming.
Let's go in a fantasy world where we have a B+ language which should have been C: remove typedef/_generic/typeof/restrict/enum/etc, well all those horrible things. Only one loop statement, loop {}, no switch ofc. Only sized/signed core types with properly sized/signed literals: ub/sb or u8/s8 with integer literals like 123ub/123sb, sw/sd..., udw/sdw... , uqw/sqw..., fdw/1.23fdw (f32), fqw/1.23fqw (f64) (for some hardware ymm/xmm/zmm with fancy literals, sorry I am not aware of the fine details of the C/CPP lexer). Ofc, no integer promotion and no implicit cast (void* would still not require any cast). Compile-time and runtime cast (not like with that horrible c++ syntax), same thing for consts (even though nowadays it is the the compiler which detects real compile-time constants), yes you may have to "static const" your literals. Oh, and for the C preprocessor, do fix that variadic-args function-like macro for good (I wonder if gcc the way is not better than c++ ISO way).
Without all that, it should be "reasonable" for a small team of average-skilled or an individual to write a naive compiler until they don't forget they can hit a goto at any line. And they are those who say "but feature A is cheap to implement"... 1 million cheap features later... well, you get the picture.
The really hard part for ISO was to keep C actually "cheap" to implement, this is where they are failing hard.
As for the gcc extension based C dialect for kernel developement, no salvation here, C is really too alien (or even B+). Namely the little ISA abstraction is not "enough", so either the kernel goes full "slow" with plain C and assembly (_not_ inline assembly ofc), or full assembly on all of its fast-paths which would require proper binary defined specs (I am currently researching how bad this could be).
I do believe the open source communities have the strength to maintain parallel assembly _significant_ code bases (which do the same thing), big monolithic corpos... not so sure...
Earlier quoted context omitted.
Interesting. Can you list an example of C++ type system allowing optimization Rust system doesn't?
I don't think you could do [0] in Rust, but would be very interested in finding out otherwise. [0] https://capnproto.org/news/2015-03-02-security-advisory-and-...
Earlier quoted context omitted.
Rust does emit bounds and other checks, though. Optimization passes can usually clear some of them away, but you'd need to check the assembly output to be sure.
Yes, that's "omit". "Emit" means "to send out", eg "emit a strange noise", "emit radiation".
- trying to access an arbitrary element in a slice, the compiler will emit bounds checks (`if index > len: panic()`) to avoid an uncontrolled out-of-bounds memory access — https://godbolt.org/z/cbY5ebzvK (note how if you comment out the assert, the code barely changes, because the compiler is adding an invisible assert of its own)
- if the compiler can infer that `index` will always be less than `len`, then it will omit the bounds check — https://godbolt.org/z/TTashYnjd
Earlier quoted context omitted.
I don’t know dude, if you want to write software for the worst performers instead of commodity hardware that’s up to you Just that single core systems are dying and probably won’t come back. Even Raspberry Pi’s are quad core now.
You should always write software for the worst performers. Unless you have a very good reason not to. Writing for the top performers is how we got into the silly mess where computers from 30 years ago have much higher ux then now.
Writing multithreaded applications increases the performance ceiling. If an application can’t take use of multiple threads, but is written in a multi-threaded way, there’s no harm done. It simply runs the multi threaded code in a single threaded way (think of ParArray) with a bit of overhead incurred for “becoming multithreaded”.
Reasoning out of adding multithreaded support for long running actions because “most systems can’t take use of the extra threads” is just irrational, especially since most modern commodity systems could have a linear improvement with the additional threads.
The single core systems are barely hurt by the memory overhead involved with provisioning CORE_NUM of worker threads. But the multi core systems can take massive advantages from it.
Earlier quoted context omitted.
Typical statement coming from people lacking experience in this field (no offense meant). The truth is, parsing strings in C is as easy as in any other language. You have a string array and a length field, and you scrub through it from left to right with a cursor. Done. What you do not get in C is creating lots of string objects willy-nilly, and concatenating them with a plus sign, like you do in scripting languages.
Now Object Pascal and Modula-2 are scripting languages....