Default mutable is one thing that could be seen as being the wrong choice these days. Similarly [[nodiscard]] shouldn’t exist, although I have to say that I prefer the flexibility of C++ to something like Rust, where I found myself having to reach for a mutex package/crate in single threaded code because it wouldn’t otherwise let me store a callback pointer passed from an app.
- The default implementation of copy constructors and assignment operators and even the default constructor often don’t do what you want
- Pass by copy by default instead of pass by reference by default for function parameters, leading to a lot of useless object copies if you’re not careful.
- Const is not the default so you have to manually specify it everywhere. The reverse would make more sense in a lot of cases (everything const by default and specify mutable where needed)
- By default all functions can throw any exception and all you have is noexcept, whereas the opposite would make more sense (exceptions not allowed by default, unless you explicitly specify them). It would be extremely verbose, but right now I have this verbosity in the comments around the function definition anyway because I just need to know what exceptions to expect from any function call.
- Having execution go through case: labels by default so you have to manually add break statements, while the opposite would make more sense (break by default, use continue; or something like that if you want the execution to continue with the next case: label)
These are just a few examples.
None of this is really a problem on its own, if you have used the language for long enough you know these things and you’ll accept it as part of the boilerplate you have to go through when writing any code. But when you learn the language, each of these things is something you have to discover the hard way, making the best way to architecture code often less obvious than all the wrong ways you can imagine.
3 Likes
Let’s do a few more:
-
By default C++ will try to use your single argument constructors to cast parameters without asking, so you need to tell it never to do that, for each such constructor.
-
C++ literal strings “Like This” aren’t C++ std::string class or a more modern string_view or some other sensible type, they’re the C char[] array of chars, which doesn’t remember how long it is and needs NUL byte termination. If you want a modern string type the default literals aren’t that.
-
C++ declarations silently default to uninitialized. Instead of say an “undef” keyword it just assumes if you didn’t initialize the variable that’s always intentional.
3 Likes
With all these points you forget C++ is a “low level” language while those languages you use as reference are “high level” languages. Some of these mentioned points are actually important for C++ to be high performance (at least for game developers). Higher level languages are typically slower and lack in the data–crunching department. So at least I see these points not as negative but as the power C++ gives us instead of revoking them.
2 Likes
Rust is not only a high-level language but once you wrap a bunch of “unsafe” Rust in procedural macros you will have created low-level code lower-level than C, let alone C++. It’s only the macros and API wrappers that give the illusion that Rust is a strictly high-level language.
Besides, Clang uses the same LLVM underpinnings as the standard Rust compiler. The only difference on the low-level code is that Rust’s wierd scope rules make data aliasing impossible thus simplifying the compiler.
Re:Carbon and Zig
I hope Carbon is to Zig what C++ is to C. Zig disallows unsigned wraparound from C so the LLVM compiler infrastructure can make safer guesses as to code optimization. If C++2x can be imported to Carbon like Zig imports C and cleans up the language comparably, Carbon might be worthwhile.
Zig is my favorite of the newer “C replacement” languages (though I think Nim and Odin also have good points.) I find it very easy to read and after 25 years as a programmer I think that is one of the most important aspects of a language. You read code a lot more than you write it. Though writing Zig isn’t hard either. It feels a lot like a combo of Go and Rust.
The compiled binaries it creates are also extremely fast, faster than C++ in some cases. They are working on a new “self-hosted” Zig-in-Zig compiler that will also make compiling Zig very fast (it is already on the order of Go in my experience, which also compiles very fast, but the new Zig compiler is pretty insane.)
I think Zig can replace C++ code as much as C code, the whole “X replaces C, Y replaces C++” is a bit of a trope. C++ is just way too complicated and tries to do too many things, no one should be seeking to replace it in the same way, we need simpler languages. In that sense Rust has failed, because it has become insanely complicated. I was very much a Rust fan until I saw there were alternatives like Zig, Odin, Nim and Hare.
Someone is working on porting Zig to Haiku and I think it is mostly there beyond maybe some clean-ups in the standard library.
I want to make a native Haiku word processor (eventually…) and I may have the core engine in Zig, with a Haiku C++ GUI around it. I think this will work well.
The current downsides to Zig:
- Still in progress, they are still breaking the language and standard library
- The self hosted compiler has taken quite some time, though I think they are close
- Still no official package manager, though I expect that to improve
- Not the best documentation, especially for the standard library (though part of that is intentional because the library design is still in flux.) With that said I find the standard library very easy to read and it also provides good guidance on Zig idioms
- On safety it doesn’t come close to Rust (at least on memory safety), but it is greatly improved over C and C++
With all that said, I will look into Carbon, having support for the C++ ABI is nice.
3 Likes
…i’m really want to see fpc can use for creating native application for haiku… but i dont know to begin with…
1 Like
The discussion is only about changing the default value for things. So the only consequence would be that writing the super efficient low level code would sometimes be a bit more verbose, but there should be no performance cost at all.
By the looks of it it was the BTextView, and IIRC, it actually echoed out an error at runtime relating to it needing to be created as part of a BWindow. It was 21 years ago, so I might not remember all of the details 
Olivier joined the project later and had a better way of binding the BeAPI. I think they got a lot further. My version mimicked the VCL. I have no idea if they ever bound the whole API as I stopped using Delphi after than and therefore stopped with FPC too.
Hmmm why do you think that? Unless Rust is doing 1:1 machine code instructions (which generally you can do with a lot of C compilers) all low level languages are really high level compared to machine language. C can direct manipulate memory and registers, so in the battle of “Rust is best” it probably doesn’t come out on top here, save maybe safety - but then at this level that adds overhead.
I mean I deal with a lot of low level code, packed structs with bits (not bytes) being carved up to represent data. C is low level I promise you, and Rust might be equally low level, but I doubt it is more low level unless it is doing something dangerous.
… did olivier have published his work? i curious to check it out
As I think about it, they are equally low-level but Rust’s macro system is more tightly integrated. C only supports a function-look-alike syntax for its macros and parameter passing while Rust allows direct access to the lexemes of its parser which means that macros can become new commands. This effectively removes the need for a standards body weighing out the need for the new command structure.
propose that to the c c++ governance
1 Like
Work yourselves out of a job there, C/C++ govrnance board and ISO standards committee! LOL!!! 
Rant
Other languages suck, too.
C is like a portable Assembler.
C++ is an ugly beast which is useful in the software industry.
Don’t know Rust well enough to judge if it is low level. But changing the language itself with macros is not limited to Rust. It’s known in Lisp for example.
Python is sheer trash I think. Nice to use, for beginners and for experts, but sheer trash anyway.
If the standards comitees do a good job is indeed questionable.
Carbon won’t be the C++ successor I think. Virgil is a nice try for that purpose, trying to do it simpler than C++.
*Ok enough of this rant. I love to talk about programming languages. I could go on endlessly *
Greetings
Peter
4 Likes
my brain says, probably easier to improve a language than start over
2 Likes
Yeah, I think so, too. Changing a language isn’t a good way. Think of Perl.
It depends on the language and how it was written initially. Inheritance is hard for a compiler to optimize away when it is overused. That’s why I lean away from OOP in the classical sense. Simpler structures can sometimes outperform one-size-fits-all solutions like classes.
1 Like
I’ll stop you there. That is not what we mean by “low level” in this context. Low level is “how close to the metal” you can get. C, will allow you to get closer than Rust every day of the week, because it has little or no safety… you can basically write inline assembler, directly grab a block of memory and write data or instructions to it, and if your OS does not safeguard, execute that code. C is high level, but only really a thin veneer over the underlying OS.
I don’t know Rust, but from what I hear, it protects the user from just doing that kind of stuff, so it is not really low level, it tries to accommodate that, but it is not. A C pointer, you can just increment and start reading memory out of bounds to the scope of what you were originally pointing to… you can directly change that memory and you could basically rewrite the code you are running while it is running if you wanted to.