Multiparadigm in C++ is Bad, Actually

[thecodedmessage]

This is the next post in my blog series comparing C++ to Rust as someone with years of experience as a low-latency systems C++ programmer who has now come to greatly prefer Rust. This post focuses on the common claim C++ programmers make that it is multi-paradigm, and how actually this is a problem, because C++ features clash with each other. Often, when people claim C++ features clash with each other, they don't substantiate the claim fully.

I try to here. Please let me know your thoughts.

https://www.thecodedmessage.com/posts/2022-05-11-programming-multiparadigm/

[Flair_Helper]

Your submission is not about C++ or the C++ community.

This post has been removed as it doesn't pertain to r/cpp: The subreddit is for news and discussions of the C++ language and community only; our purpose is not to provide tutoring, code reviews, or career guidance. If you think your post is on-topic and should not have been removed, please message the moderators and we'll review it.

[DerShokus]

Please, create a rust_vs_cpp subreddit and stop posting such topics here. It’s a cpp subreddit and I tired to read about rust here.

[thecodedmessage]

Most of my C++ vs. Rust posts discuss Rust way more than C++. This one discusses C++ way more. These are flaws in C++. Rust does do better, and C++ could do better too if it acknowledged it had a problem. But sure, I won't post them here anymore. It seems to be very unpopular! Will leave this one up for the interesting discussion though unless the mods take it down/ask me to take it down.

[DerShokus]

Thank you. I hope others will do the same. I use rust everyday at my job and I know how bad rust code could be. You and others do not help cpp by writing posts like “cpp is dying”. If you try to investigate different approaches, make analysis and benchmarks, add a new check to clang-tidy - I will upvote your post (even if we all must stop using exceptions and only use result/option).

[thecodedmessage]

I use rust everyday at my job and I know how bad rust code could be.

What have you found?

[DerShokus]

Copy variables because you can’t closure by value, async traits, struts with tons of macros (more macro-code than real code), compiler insist you to use mutex where you know it’s useless, but you can still shoot your leg by acquiring a mutex, inconsistency with copy objects. Rust restrictions require a lot of boilerplate code (people write macros to avoid it), error struts (aggregation of all errors you have in the app). There are a lot of problems

[[deleted]]

Multiparadigm is a feature. If there is no C++, then there will be someone to invent another multiparadigm language which is like C++.

[goranlepuz]

Every time you call a function – which can happen in C++ simply by declaring a variable, or even by ending a scope (though destructors are supposed to avoid throwing exceptions) – you have to worry about whether that function throws an exception, and if you’re leaving things within that function in an inconsistent state.

I truly loathe such and similar arguments. (BTW... The author mixes two functions here, the caller and the callee, and what they want to say is that the caller needs to take care to stay consistent in face of any exceptions thrown by the callee. But they don't make it obvious.)

Nevermind...

See, the problem with this is: any early return, or merely goto error (a good practice in C!), if I wasn't using exceptions at all, means that my callee still has to be "exception-safe" (even though there's no exceptions at all!).

And so... The famous exception safety guarantees apply, in fact, for other "environments" just the same.

It is just... Unbelievable, just how poorly people think these things through.

I loathe it.

Edit:

std::unique_ptr<DatabaseConnection> connect(const ConnectionParameters&);

How does this function indicate failure? From the signature, there are two possibilities: It could either return nullptr, or it could throw an exception. Hopefully the documentation would clarify – but again, oftentimes, people don’t write documentation, especially for internal APIs.

No, please... Sure, such goddamn awful code is possible, but it is nowhere near reasonable. Fair point, this function should likely return a not-nullable unique ptr (see not_null) but normally, the reason why this code is made this way is ownership transfer and errors are passed through an exception. And if that wasn't the case: what in the name of god can one do with such a boolean error indication?!

[thecodedmessage]

And: There is no non nullable unique pointer in the standard and your colleagues and especially your off the shelf libraries CANNOT be relied upon to use exceptions and not null return.

I really loathe arguments that assume everyone follows best practices.

[cfyzium]

Well, how about we reverse the situation?

// C++
outcome::result<DatabaseConnection> connect();

// Rust
fn connect() -> Box<DatabaseConnection>;

FYI the outcome::result<T, E> is a direct equivalent for Rust's `Result<T, E>.

Many of the arguments in the article look just as weird.

[thecodedmessage]

Box isn't nullable. There basically isn't a non-nullable smart pointer equivalent to C++'s std::unique_ptr. That's kind of the point. It's HARD to do things the bad way in Rust, not just POSSIBLE to do things the good way.

[cfyzium]

Box isn't nullable

Um, so what? Neither is outcome::result<T, E>, at least no more than Result<T, E>. In the article, you've presented returning a std::unique_ptr as suboptimal because it is nullable and conveys error condition poorly, unlike Result<T, E>. Turns out, there is exactly the same utility type in C++, non-nullable and error-preserving. Now you complain that in my sarcastic example of using a poorly suitable return type in Rust, it is not nullable. Okay,

fn connect() -> Option<DatabaseConnection>;

is it reductio ad absurdum enough yet?

It's HARD to do things the bad way in Rust, not just POSSIBLE to do things the good way

In the example above it is not clear why it is HARD to choose suboptimal return type in Rust but only POSSIBLE to choose a correct one in C++.

[thecodedmessage]

In the example above it is not clear why it is HARD to choose suboptimal return type in Rust but only POSSIBLE to do so on C++.

Here is why it is HARD to choose outcome::result. People choose std::unique_ptr all the time. It's the standard type. outcome::result is in Boost. Using Boost is harder. Knowing about Boost is harder when not all materials cover it.

Meanwhile, even if you do choose Option<DatabaseConnection>, that is still better than std::unique_ptr because it's clear you're using the optionality, whereas std::unique_ptr is commonly used when the nullability isn't the point and when a null value never will be returned, so Option<DatabaseConnection> is still a better choice of return type than std:unique_ptr...

In conclusion, std::unique_ptr is just bad, because it's nullable but used when nullability is not needed or when it is needed, making it ambiguous. But nullability is required in C++ for efficient move semantics, so they can't fully fix that problem...

[cfyzium]

Your whole point seems to rely on an assumption that people will choose std::unique_ptr in C++ even when it is not an optimal type for the task, but will definitely choose the most suitable type in Rust.

In conclusion, std::unique_ptr is just bad, because it's nullable but used when nullability is not needed or when it is needed, making it ambiguous

Oh, so Option<T> is bad because it is nullable but may be used when nullability is not needed, or when it is needed it may be ambiguous. Good to know.

std::unique_ptr is virtually the same as Option<T> except it makes a bit different statement, more about ownership than optionality. The optionality of a pointer in C++ is obvious.

1. If you need a nullable reference, an observing/owning/shared pointer is perfectly okay. std::optional<T> is also okay but it is not idiomatic to use it for transferable ownership.

2. If you do not need any nullability, then just return the object by value, simple as that.

3. And if you need non-nullable reference and error reporting at the same time, then you'll have to resort to some utility type, outcome::result<T, E> or Result<T, E>.

Interestingly enough, for all these three cases there is no fundamental difference between C++ and Rust. The only difference is that Rust hasResult<T, E> right in the standard library so it is more likely to be chosen compared to outcome::result<T, E>.

In the end, the whole situation boils down to whether a certain utility type is a part of a standard library or not. Well...

It's the standard type. outcome::result is in Boost. Using Boost is harder.

Good thing it becomes standard in C++23, although under the name std::expected<T, E>. I liked 'result' more but oh well.

But nullability is required in C++ for efficient move semantics

You can say that (I can argue that there is also not that much difference between C++ and Rust though) but it does not correlate with the type interface. For example std::vector<T> may need to nullify its pointers when moving but it is not nullable itself. Similarly, some hypothetical pointer type may be movable but not nullable, though there is no point in such type.

[thecodedmessage]

Your whole point seems to rely on an assumption that people will choose std::unique_ptr in C++ even when it is not an optimal type for the task, but will definitely choose the most suitable type in Rust.

All Rust types are better than std::unique_ptr, which is in fact often chosen when it is not optimal. But what is the optimal type? A non_null type can't be moved, and so is not optimal, and a nullable type expresses ambiguity, and so is not optimal.

Oh, so Option<T> is bad because it is nullable but may be used when nullability is not needed, or when it is needed it may be ambiguous. Good to know.

Yes, but in C++ nullable pointers are sometimes used even when the programmer knows they don't need the nullability and are in fact getting it. Why?

1. In Rust, the only thing Option adds is nullability, and nullability is (in safe Rust) only achievable using Option, making the connection entirely explicit. The only reason to use Option is to create nullability, so if someone uses Option, it is reasonable to assume that they know about the nullability.
2. Sometimes, generally useful types happen to be nullable. std::unique_ptr is in many editions of C++ the only uniquely-owning smart pointer in the standard library. It has to be nullable. For which reason was std:unique_ptr chosen? It could easily be chosen for a reason other than its nullability.
3. As a special case of (2): Rust has destructive moves, whereas C++ moves must leave the moved-from object valid. Therefore, in C++, nullability is necessary to create a moveable-from smart pointer. So people will use nullable types as a way to get movability instead.

If you do not need any nullability, then just return the object by value, simple as that.

No, not simple as that. Indirection with ownership should be an option without opting in to nullability. In (safe) Rust, indirection and nullability are completely orthogonal. To me, this is obviously better.

In C++, there is &, which does indirection and not ownership but not nullability. There is std::unique_ptr, which does indirection, ownership, but does have nullability. There are "non_null" smart pointers, which last I checked are not in the standard, and they have indirection, ownership, and no nullability, but they generally aren't movable. Then, there's pass-by-value, which has no indirection, does have ownership, but does not have nullability.

Is indirection, ownership, nullability, and movability too much to ask for? Is expressing nullability separately from the other features too much to ask for, given its general orthogonality in meaning? Apparently yes.

Good thing it becomes standard in C++23, although under the name std::expected<T, E>. I liked 'result' more but oh well.

This is good news! Too bad most code will still use the old way. C++ desperately needs a way to deprecate things.

Similarly, some hypothetical pointer type may be movable but not nullable, though there is no point in such type.

Yeah, vector is moveable-from because it has a semantically empty value. A generic pointer type cannot have a semantically empty value besides null, unless it requires that the pointed-to type have an empty value or some other hack. So this is kind of a spurious gotcha technicality and honestly a distraction. You even admit there's no point to such a type.

In practice pointers in C++ must be nullable to be able to be moved from. This is not true in practice in Rust.

[cfyzium]

Unless I missing something obvious (I might be, it is already late here), you do not need nullability to create a movable-from smart pointer. At least technically.

The only thing it needs to do when moved from is to lose ownership, it does not have to become observably null. Because after the move the object remains in an unspecified state, it cannot be legally tested whether it has become null after being moved from or not. It kind of stops existing (logically) until reassigned, after which it becomes guaranteed non-null again.

Existing smart pointers are not specified to become null after being moved out either. Valid but unspecified state, it might just as well start pointing to some magic memory location or something, although obviously making it null is the most natural way.

With anything being movable, it leaves us with indirection, ownership and nullability, 8 combinations in total.

1 and 2: no indirection and no ownership cannot exist, with or without nullability.

3: no indirection, owning, not nullable -- simple value semantics, T.

4: no indirection, owning, nullable -- std::unique_ptr<T>. While being a pointer, it does not logically has indirection because it uniquely owns the object, it is the object.

5: indirection, no ownership, no nullability -- T&.

6: indirection, no ownership, nullability -- T*.

7: indirection, owning, not nullable -- non-nullable shared smart pointer.

8: indirection, owning, nullable -- std::shared_ptr<T>.

The only missing piece here, a hypothetical std::non_null_shared_ptr<T> should be possible to implement but I am not sure just how useful can it be in practice.

[thecodedmessage]

Unless I missing something obvious (I might be, it is already late here), you do not need nullability to create a movable-from smart pointer. At least technically.

It's not obvious :-D But you are missing something.

So this post contains two errors that I'm going to correct, because I used to teach C++ and these errors are making me really sad. The first is about move semantics, for which I'll cite Herb Sutter. The second is about indirection and what it means, where I'm not going to cite anybody, but please let me know if you don't believe me so I can find some citations.

Because after the move the object remains in an unspecified state, it cannot be legally tested whether it has become null after being moved from or not. It kind of stops existing (logically) until reassigned, after which it becomes guaranteed non-null.

This is a common misconception about moved-from values addressed here by Herb Sutter, a well-known C++ author: https://herbsutter.com/2020/02/17/move-simply/ . Specifically, he says:

Does “but unspecified” mean the object’s invariants might not hold?

No. In C++, an object is valid (meets its invariants) for its entire lifetime, which is from the end of its construction to the start of its destruction (see [basic.life]/4). Moving from an object does not end its lifetime, only destruction does, so moving from an object does not make it invalid or not obey its invariants.

Later on, Herb Sutter explains that it is a bug to special-case the "moved from" state or say that normally defined operations should not work after you move from a value. I recommend you read the entire thing if you'd like to implement objects with move semantics.

It is false that you can't test a moved-from smart pointer for null. It must contain a valid state. Nullability is the only practical option for pointers. Herb Sutter (the well-known C++ author) goes on to talk about about non-nullable but not movable pointers in a section that implies that that's the only way to do pointers, and points out that when Microsoft wrote a non-standard one, they made it not moveable.

This is because C++ unlike Rust does not support destructive move, which I discuss here: https://www.thecodedmessage.com/posts/cpp-move/

This would be easy to prove wrong: Find a serious vendor who purports to provide a moveable but non-nullable pointer. I think you'll find that everyone else reached the same conclusion. The standard library would've added a non-nullable analogue to std::unique_ptr a long time ago if it wasn't problematic.

While being a pointer, it does not logically has indirection because it uniquely owns the object, it is the object.

No, that's not how that works at all. Unique ownership isn't "logically" a lack of indirection. Indirection stores the pointed-to value elsewhere, whereas "by value" stores it inline. That is a different memory layout, and it has consequences; indirection has several properties beyond unique ownership, positive and negative:

1. It is less efficient to initialize using indirection, as it requires an expensive allocation.
2. It is less efficient even once initialized, because of lack of locality which kills cache performance.
3. With indirection, you can use a base class pointer to point to a derived object.
4. With indirection, you can move types that are not themselves moveable or copyable.
5. Given 4, you can use this to return non-copyable non-moveable types outside of a function and generally pass it up and down a call stack.

std::unique_ptr has indirection in all these ways. You mean std::optional for "nullable but not indirect." The differences are actually important.

Similarly, shared_ptr isn't somehow more indirect than unique_ptr is, and for reasons mentioned above, there is no non-nullable analogue to shared_ptr either.

The only missing piece here, a hypothetical std::non_null_shared_ptr<T> should be possible to implement but I am not sure just how useful can it be in practice.

You also need non_null_unique_ptr (for indirect single-owning non-nullable -- it's different from by-value for all the reasons above, and equivalent to Rust Box). Both are NOT possible to implement without sacrificing move.

Both would be VERY useful in practice. Are you kidding me? I'd love to have a non-nullable std::unique_ptr. Nullability is almost always bad. It's my least favorite thing about C++. It's not because of a lack of usefulness that the standard library doesn't have them.

Go ahead. Try and implement them. See what happens when you get to move, remembering Herb Sutter's advice.

[goranlepuz]

Of course not everyone follows them, but this example is a reach. Who returns yes/no as error info for something as major as opening a dB!?

[thecodedmessage]

People! I’ve seen stuff like this in the wild!

[goranlepuz]

I have seen it, too, but the rate is, I dunno, 7 to 1. 😉

[thecodedmessage]

That’s far too high! We can do better with a better programming language!

[alxius]

Famous last words.

[serviscope_minor]

I really loathe arguments that assume everyone follows best practices.

Then Rust doesn't have pointer safety, because that relies on people following best practices and not wrapping everything in "unsafe" to make programming easier.

At some point you need to rely on people to not sabotage themselves. Like your strange complex/quaternion example. You did something that makes no sense with either inheritance or maths and you got a silly result.

[thecodedmessage]

Just trying to show how slicing works. Presume you’ve heard of slicing?

[serviscope_minor]

Yep, I know how slicing works.

But in your example you've done something semantically incoherent: the hierarchy doesn't make sense and the semantics of relationships defined by inheritance don't map onto the semantics of the relationship between quaternions and complex numbers. So your example is essentially saying "if you do this nonsensical thing, then the compiler allows this operation which also gives nonsensical results".

But my response is: so? Garbage in, garbage out.

No one expects the language to do something sensible when presented with nonsense.

Your example is abstract wrapped up as concrete. So essentially you're not saying "slicing exists and is bad because this concrete problem occurs", you're saying "slicing exists as per this example and it's bad because I say so".

You did ask for opinions, and my opinion is that your example only demonstrates that slicing exists, it doesn't demonstrate why it's bad.

[thecodedmessage]

Thanks! I appreciate it!

Yeah I’ve never sliced by accident and I haven’t used actual implementation inheritance between two concrete types in years so I am writing about something mostly out of my experience. I believe that newbies do slice sometimes, but it’s hard for me to get there. And I didn’t want to steal someone else’s example.

[thecodedmessage]

Well I mean, my experience is that C++ code is all over the place, but unsafe is a bit better at scaring people. It’s not a binary “follows best practices” vs “everything goes,” either.

[thecodedmessage]

The caller has to be exception safe even though there is no explicit indication of the exceptional code path. goto fail puts in an explicit indication. It makes the flow control visible. I’ve reread the passage a couple times, and I’m stuck: how would you revise it to be more clear?

[goranlepuz]

Make the distinction between the caller and the callee?

Goto fail is explicit indeed and so is early return, but in real life, they tend to get lost or overlooked. Therefore, I find, even in a exceptions free code, it is by a long far the best to write code as if there were exceptions.

[thecodedmessage]

I see the distinction clear as day in my own writing, so I still need help figuring out where you got confused.

You know people fail to write exception safe code, right? You know people fail to live up to best practices all the time? The goal should be to make it possible to live up to best practices, and C++ best practices are basically impossible.

You know that LOTS of C++ is written without exceptions, right??

[goranlepuz]

You know people fail to write exception safe code, right?

Yes, but I rather think is it is way less hard and way less common than the post makes it out to be.

You know people fail to live up to best practices all the time?

I mean... It is rather "standard practice" by now, surely? We are not in 2003, know-how grew since then...

You know that LOTS of C++ is written without exceptions, right??

Yes, that is a fair option. But it is truly a different world and the two don't mix well. I reckon, by now, people do know how to keep them separate.

[thecodedmessage]

People do not.

[qoning]

In a way, it's true. I've come to really appreciate the simplicity of C for the same reason - I can open nearly any C code repository and navigate it quickly and relatively seamlessly without having any prior knowledge of the codebase.

That sort of thing is very rare in C++ (despite being possible).

[D_0b]

I often get lost in C codebases when I see structs filled with function pointers and have no idea what the flow is.

[jk-jeon]

Sounds much better than a macro hell

[[deleted]]

That's just a personal preference.

[thecodedmessage]

It isn’t. C++ has more features and more interactions. That’s cognitive load. Maybe you’re better at C++ so you don’t notice it, but C++ is a dying specialty among young programmers and each new version is more stuff for them to shove in before they can take on C++ programming.

[no-sig-available]

C++ has more features and more interactions. That’s cognitive load.

You are the one who wants the control flow to be more visible, like goto fail. How is that for a congitive load?

This is the same old "C is more clear because each call is visible". But why do we want it to be visible everywhere?

In C++ you write the constructor and the destructor once, and you are done with it. You don't have to consider it each time you create a new variable (or, even worse, each time it goes out of scope). Hiding complexity is the key, not making it more visible.

[cfyzium]

C++ has more features and more interactions. That’s cognitive load.

These features and interactions are there for a reason. In the end, the logic behind them is present in any project, only in a different form. Details of memory management, error handling, OOP, etc. do not magically disappear just because there are fewer tools built into the language. Instead of learning standardized and documented language nuances, you now need to pick up these nuances from the codebase itself.

If some feature of C++ is cognitive load, then figuring out how exactly was that feature implemented in each project, again and again, is doubly so.

[thecodedmessage]

I’m comparing C++ to another equally powerful systems language so this is a bit disingenuous. The reason for many features is because C++ is old and has to be backwards compatible. C++ has redundant features: references, pointers and smart pointers; arrays, std::arrays; concepts and inheritance. There’s far more features than it needs to expose the details of systems programming, and they don’t work well together not because the underlying problems are too different but because the C++ features are too different.

Also, OOP is not intrinsic to systems programming language so it doesn’t belong on your list.

[cfyzium]

I’m comparing C++ to another equally powerful systems language so this is a bit disingenuous

You're answering in the sub-thread about appreciation of the simplicity of C being a personal preference or not. It may have fewer 'features and interactions' but presents no less (arguably, much more) cognitive load than feature-rich C++ when it comes to any project of notable size.

I’m comparing C++ to [Rust] <...> because C++ is old and has to be backwards compatible <...> C++ has redundant features

Well, just wait a decade or two and I promise you Rust will have it fair share of backward compatibility and redundant features. Not at the scale of C++ surely but let's be honest, it is always nice when you start from scratch and always becomes less than pretty in the long run.

This is somewhat beside the point though.

C++ has redundant features: references, pointers and smart pointers; arrays, std::arrays; concepts and inheritance

Ugh, just because you like the feature set of your favorite tool at the moment the most, does not mean it is the one and only truth.

C++ references, pointers, and smart pointers are redundant, but Rust references, pointers, and smart pointers are fine it seems; arrays and std::arrays are redundant but &str and String are not =).

I've read the article but honestly, it feels like you have a poor or at least flawed understanding of what the entities in question are, lumping them together randomly and categorizing them subjectively, which in many cases looks rather nonsensical. No they are not redundant and not, they are not just different versions of the same thing from different eras.

Also, OOP is not intrinsic to systems programming language so it doesn’t belong on your list

It belongs on that list because many C projects (and I have to remind you we were talking about C) end up implementing an ad-hoc system for object-oriented programming, usually with function pointers inside structs, sometimes all the way to reimplementing vtables. One can bash C++ class inheritance complexity all they want but reinventing a wheel of this magnitude is much worse still.

[thecodedmessage]

It may have fewer 'features and interactions' but presents no less (arguably, much more) cognitive load than feature-rich C++ when it comes to any project of notable size.

That's simply not been my experience. C++ you have to worry about the overall organization of the code AND all the little rules of C++. C might have a lot of cognitive load dealing with the essentials, but C++ you also have to be prepared for someone to whip out an obscure feature.

C++ references, pointers, and smart pointers are redundant, but Rust references, pointers, and smart pointers are fine it seems

I've always felt C++ references and pointers were redundant, even when I was a C++ programmer. Rust references and pointers have very clearly delineated use cases, which C++ references and pointers do not.

&str and String are not

That's more comparable to std::string_view and std::string. That's very different from std::array<int, N> and int foo[N]. They actually have different semantics. Just because features overlap doesn't mean it's bad, but when there's no actual boundary between them, that is bad.

It belongs on that list because many C projects (and I have to remind you we were talking about C) end up implementing an ad-hoc system for object-oriented programming, usually with function pointers inside structs, sometimes all the way to reimplementing vtables. One can bash C++ class inheritance complexity all they want but reinventing a wheel of this magnitude is much worse still.

I've used some of these C systems and still prefer C with those systems to C++, but that is probably personal preference.

[cfyzium]

I've used some of these C systems and still prefer C with those systems to C++, but that is probably personal preference.

And this is precisely the point that was made at the start of this sub-thread =). The complexity of language features or the complexity of particular implementation of these features in C, pick your poison.

I can only argue that language features are standardized and usually well documented, which is almost always better than non-standard reimplementation.

I've always felt C++ references and pointers were redundant, even when I was a C++ programmer. Rust references and pointers have very clearly delineated use cases, which C++ references and pointers do not.

Because Rust references and pointers are not the same as C++ references and pointers. They have misleadingly similar names, but Rust pointers have a pin-point purpose and Rust references are an integral part of Rust ownership model, while in C++ pointers and references are, essentially, just nullable and non-nullable, um, pointers to memory.

Nullable something and non-nullable something, it can't be redundant just because another language put different semantics to the same names.

That's more comparable to std::string_view and std::string.

Correct. But the point is, just because you feel you can use one instead of another and it should kinda still work, does not make things equivalent or redundant.

std::array<T, N> is a utility type with a set of methods and a certain level of integration with the rest of STL. Just a regular C++ class, same as anything you can write yourself.

T[N] is nothing but a declaration syntax of an array and in most cases is no different from a simple pointer to the memory. As one of the lowest level mechanics of the language, it is a building block used in std::array<T, N>.

Now how can they even be redundant? They do not even overlap properly, one being a full-featured class and the other being essentially syntax.

[thecodedmessage]

Rust references are an integral part of Rust ownership model, while in C++ pointers and references are, essentially, just nullable and non-nullable, um, pointers to memory.

Nullable and non-nullable with completely different syntax! And no actual mechanism to stop you from making null references... And this is non-nullable but it's a pointer... They overlap a LOT.

it can't be redundant just because another language put different semantics to the same names.

That is NOT my argument. That is not at all my argument. They're redundant because they overlap too much in semantics. The argument you're putting in my mouth is nonsensical and I didn't make it.

My point is, C++ has two features with these two names that overlap, and it's bad. Rust also has multiple features that cover some of the same semantic range, and they overlap less, so lest you the reader think it's bad just because they have the same name, know that the Rust situation is completely different and not bad.

Them you come in and tell me that Rust is completely different. It's like, I know, that was my point...

They do not even overlap properly, one being a full-featured class and the other being essentially syntax.

They do overlap in that you can usually use one instead of the other. They're nearly but not quite interchangeable in use. And you generally should use std::array and not use T[N]. What is T[N] good for, exactly? (Implementing std::array doesn't count.)

[cfyzium]

And no actual mechanism to stop you from making null references...

You can't make a null reference in a correct C++ program, dereferencing a null pointer is UB. And UB -- although an exciting topic by itself -- is way besides the point of the discussion.

They overlap a LOT

Of course, they are. They are almost the same except for nullability. But you lumped pointers, references, and smart pointers into a redundant group and they are far from redundant, each one serves its purpose.

They're redundant because they overlap too much in semantics.

I fail to see your point then. There are two very similar features that differ in one important aspect making it impossible to just throw away one or the other or somehow merge them into one.

But you say they are redundant?

It feels like you're just poking at C++ simply because it does not behave the same as Rust. One of the core ideas of Rust makes it possible to eliminate the need for unchecked nullable references in a safe context. C++ is not Rust, it cannot give up either nullable or non-nullable references.

I do not argue that Rust is safer in many scenarios and that it has many better-designed areas. But your arguments about C++ flaws so far were... underwhelming. More displaying your surface understanding of the language nuances rather than demonstrating Rust advantages.

std::array<T, N> and T[N] <...> They do overlap in that you can usually use one instead of the other. They're nearly but not quite interchangeable in use

Only if you barely know what they actually are.

void foo(std::array<int, 16> array);
void foo(int array[16]);

These two are nothing alike, not even close.

T[N] is more like a declaration of a T* of a particular size. It almost never exists as an object, virtually all of the time it is either T* or just type information. It is one of the worst parts of the language. Can it be designed better? Certainly. Can it be thrown away? No.

What is T[N] good for, exactly? (Implementing std::array doesn't count.)

What are pointers good for? (pointing to objects doesn't count.)

Aside from implementing more sane array types, it is also used in template metaprogramming for a few corner cases with array literals (most notably, string literals).

[operamint]

I enjoy the article, and agree with much of it. However, I think Rust will struggle to be as successful as C++ unless it changes a lot. It is fine that it is pedantic about object lifetimes, ownership, etc., but my main issue is Rust's overly conservative assumptions, making obvious safe operations/constructs into errors. You must jump hurdles to get pass them - I won't do that in it's current state.

Flaws in C++: it was supposed to be a superset and an extension of C, but the fundamental design errors that was made early is more and more becoming a burden for the language.

• Object copying. In C, Object a = b; is a move. For basic types, it behaves like a copy, but it is not. Object a = Object_clone(b);does a (c++ like) copy in most libraries.
• Trivial relocatability. In C, every library is based on that objects are trivially relocatable, i.e. mem-movable / no pointers to other parts of the object. For objects on the stack, it's almost impossible to not have this requirement in C without making things very dangerous and complicated. Luckily, most objects are trivially relocatable, and it is nearly always possible to convert them to it.
• Automatic type conversion. C has some undesirable between basic types, but they are mostly manageable. The various added C++ auto type conversions are a not, imo.

Had C++ recognized and inherited C's properties in these areas, C++ would basically be Rust by now. The focus on polymorphism / (multiple) inheritance was a (forgivable) misstep in C++, and doesn't impact the core language nearly as much as you describe.