231–240 of 281 posts
If the uber-bean counter, herald of the language of bean counters demonstrate unwillingness to count beans, maybe the beans are better counted in another way.
> [M]any developers use C++ as if it was still the previous millennium. [...] C++ now offers modules that deliver proper modularity. C++ may offer modules (in fact, it's been offering them since 2020), however, when it comes to their implementation in mainstream C++ compilers, only now things are becoming sort of usable with modules still being a challenge in more complex projects due to compiler bugs in the corner c…
Ya that is rather disingenuous, modules aren't ready, and likely won't be for another 5 years. Also they are difficult to switch to, so I would expect very few established projects to bother.
Earlier quoted context omitted.
That explains very well why rust (to me) feels like C++ommitte-designed, thanks for that!
I don’t understand what you’re trying to say, could you elaborate?
C++ feels like a language of bean counters.
Rust feels like a language of bean counters.
A lot of C++ folks I know went over to rust.
They were happy with C++ and it was the best thing since sliced bread.
They are now happy with rust and it is the best thing since sliced bread.
To me, languages have a, let's call it 'taste' for the lack of better word off the top of my head. It's that combining quality that pg called 'hacker's languages', such as C, and lisp, for example.
C++ feels like a bureaucratic monster with manual double bookkeeping, byzanthine, baroque, up to outright weird and contradictory in places. Ever since rust was conceived, I gave it multiple shots to learn. When I was not thrown off by what I perceive as java-style annotations, i.e., something orthogonal to the language itself where no one seems to have bothered to come to a consensus to be able to express this from the language itself, its general feel reminds me of something a C++ embracer will feel comfortable in. I.e., in pg's words, not a hacker's language, paired with a crusade of personal enlightenment. What used to be OO and GoF now is memory safety as-implemented-by-rust (note: not by borrow checker, we could've had this with cyclone, for example, more than two decades ago).
I have, in my original comment, marked this as my personal opinion and feeling, as is the above. I'm not arguing. I love FP and the idea of having a systems language with FP concepts working out to memory safety and higher level expression sounds like the holy grail of yester-me. I'm disappointed I couldn't find my professional salvation in rust with how uneasy I feel within the language. It's as if a suit and tie was forced on me, or a hawaii shirt and shorts (depending on your preference, image it's the thing you wouldn't voluntarily wear).
Now, if other folks also mirror my observation of how the folks flock from C++ to rust, you bet they take their mindset and pedestal with them to stand on and preach off of. At least those I know do, only their sermon changed from C++ to rust, the quality of their dogma remained constant.
Earlier quoted context omitted.
yes, and you will tell me exactly what subset and coding convention "makes sense" for this domain, and you will give your reasoning too. And I will give my arguments, and on and on it goes. teams have broken up over this. A well-designed language is one in which there are very few different ways of doing the same thing. And C++ is definitely not that.
Why would a well designed language have only one or few ways to do the same thing? Seems rather arbitrary. I like when I have many ways to do the same thing. Imagine if you told a writer or poet that English is bad because there is more than one way to say the same thing... Programming languages are for people more than machines. Machines are happy with microcode.
So that you focus on solving the problem at hand, instead of endlessly arguing over decisions that are irrelevant to solving the said problem.
Earlier quoted context omitted.
They don't have to. The subset depends on the job! That's the beauty and power of C++. That's why we have projects written in it in all domains. From websites to spaceships and Mars rovers.
yes, and you will tell me exactly what subset and coding convention "makes sense" for this domain, and you will give your reasoning too. And I will give my arguments, and on and on it goes. teams have broken up over this. A well-designed language is one in which there are very few different ways of doing the same thing. And C++ is definitely not that.
loving he goes 'int main() { ... }' and never returns an int from it. Even better: without extra error / warning flags the compiler will just eat this and generate some code from it, returning ... yeah. Your guess is probably better than mine. If the uber-bean counter, herald of the language of bean counters demonstrate unwillingness to count beans, maybe the beans are better counted in another way.
You might say this is very silly, and you'd be right. But as quirks of C++ go it is one of the most benign ones. As usual it is there for backwards compatibility.
And, for what it's worth, the uber-bean counter didn't miss a bean here...
Earlier quoted context omitted.
> The C++ committee, including Bjarne Stroustrup, needs to accept that the language cannot be improved without breaking changes. The example in the article starts with "Wow, we have unordered maps now!" Just adding things modern languages have is nice, but doesn't fix the big problems. The basic problem is that you can't throw anything out. The mix of old and new stuff leads to obscure bugs. The new abstractions tend…
You absolutely can throw things out, and they have! Checked exceptions, `auto`, and breaking changes to operator== are the two I know of. There were also some minor breaking changes to comparison operators in C++20. They absolutely could say "in C++26 vector::operator[] will be checked" and add an `.at_unsafe()` method. They won't though because the whole standards committee still thinks that This Is Fine. In fact th…
Every major project in that cares about perf and binary size would disable the option that compiler vendors would obviously provide, like -fno-exceptions.
Rust memory and type system offer stronger guarantees, leading to better optimization of bound checks, AFAIK.
There are more glaring issues to fix, like std::regex performance and so on.
The C++ Core Guidelines have existed for nearly 10 years now. Despite this, not a single implementation in any of the three major compilers exists that can enforce them. Profiles, which Bjarne et al have had years to work on, will not provide memory safety[0]. The C++ committee, including Bjarne Stroustrup, needs to accept that the language cannot be improved without breaking changes. However, it's already too late.…
> The C++ committee, including Bjarne Stroustrup, needs to accept that the language cannot be improved without breaking changes. The example in the article starts with "Wow, we have unordered maps now!" Just adding things modern languages have is nice, but doesn't fix the big problems. The basic problem is that you can't throw anything out. The mix of old and new stuff leads to obscure bugs. The new abstractions tend…
1. unordered_map requires some bizarre and not widely useful abilities that mostly preclude hash tables with probing:
https://stackoverflow.com/questions/21518704/how-does-c-stl-...
2. unordered_map has fairly strict iteration and pointer invalidation rules that are largely incompatible with the implementations that turn out to be the fastest. See:
> References and pointers to either key or data stored in the container are only invalidated by erasing that element, even when the corresponding iterator is invalidated.
https://en.cppreference.com/w/cpp/container/unordered_map
And, of course, this is C++, where (despite the best efforts of the “profiles” people), the only way to deal with lifetimes of things in containers is to write the rules in the standards and hope people notice. Rust, in contrast, encodes the rules in the type signatures of the methods, and misuse is deterministically caught by the compiler.
Earlier quoted context omitted.
The capabilities of a language are not defined by its worst programmers. Is the implication here that Bjarne is a bad C++ developer? If the person in charge of the EWG fails "to use the language competently in all cases", what hope is there for the rest of us mere mortals? For what it's worth, unsafe Rust is safer than C++. There's very little UB to explode your carefully crafted implementations. Safe rust of course…
UB is a feature of the standard, not the implementation. Many of those behaviors can be defined. Modern C++ conveniently allows you to replace many of the bits that have UB, per standard, with your own bits with defined behavior with zero overhead. This was not always the case. You aren’t dependent on the compiler implementor. The ability to consistently do this transparently became practical around C++17 IMO. The C+…
Modern C++ conveniently allows you to replace many of the bits that have UB, per standard, with your own bits with defined behavior with zero overhead.
Developers don’t even have to be hardware experts, they just have to not use std for most things.
If you have a foundational library that makes different and/or explicit guarantees than std, it is pretty easy to police that in a code base with automation.
UB is a feature of the standard, not the implementation.
Earlier quoted context omitted.
I don’t understand what you’re trying to say, could you elaborate?
I'm sharing sentiment. C++ feels like a language of bean counters. Rust feels like a language of bean counters. A lot of C++ folks I know went over to rust. They were happy with C++ and it was the best thing since sliced bread. They are now happy with rust and it is the best thing since sliced bread. To me, languages have a, let's call it 'taste' for the lack of better word off the top of my head. It's that combining…
Rust wasn't designed by committee.