Hacker News Reader

Comment by rightbyte | Hacker News Reader

The notion of using C++ like "as C but with namespaces, std::vector, string and map" is way underrated.

When you add those to the mix you're dealing with destructors, ownership, etc. so I don't see anything wrong with using stuff like unique_ptr/shared_ptr.

And C tends to reinvent object oriented programming with each library so you might as well use language defined classes.

So I don't really see the point.

You don't need to use stuff like concepts, or "showing off how smart I can be with template libraries" (looking at boost), but C++ has a lot of features that make it much more productive than C.

Yeah that's basically how I use it for embedded programming c with classes, raii, better strings, and smart pointers :) . I generally avoid rolling my own pointers and anything much fancier that the simpler algorithms/sorts/etc

That’s your choice of C++ subset, but the problem with these huge languages is that everyone chooses a different subset to use.

Sticking to plain C has the advantage of probably being the subset of C++ (I know, it’s not technically a subset) that’s in widest use.

I’d add that deciding on the subset is a high cost operation. Design of such a smaller subset-language will likely not be on par with language that is small by design.

> (I know, it’s not technically a subset)

Is it not? I thought C++ was explicitly a strict superset of C?

Syntactically, it almost was; and even this is no longer true today with C11 and later,

More importantly, though - the syntax is not what matters. The languages are very very different in idiomatic use. You just don't write programs the same way with C and with C++. And the gulf between the two only expands with time. A decent C program is almost certainly a poor C++ program, in terms of idioms, utilization of library facilities, and sometimes even in terms of performance (!).

It is not and never was.

Look at for ex. what const means in each, or auto. Or variable length arrays (feature that doesn't exit in C++). Or designated initializers that C++ didn't have for a long time.

Here is a good list of differences: https://mcla.ug/blog/cpp-is-not-a-superset-of-c.html

C++ is almost a perfect superset of old C before C99. There are odd corner cases where prograns are parsed differently, but these are quite contrived. The 3rd edition of The C++ Programming language lists a few cases. Since then, C has had may additions to the language that made it diverge from C++. Your linked article is almost entirely about these new C additions.

Even for the old C it wasn't a superset.

There are plenty of legal C programs that aren't legal C++ - if for nothing else, then because C++ has more reserved keywords which are perfectly legal identifier names in C.

E.g. this is legal C but not legal C++:

int template = 10;

> everyone chooses a different subset to use

I prefer using C++ like "C but with cin and cout" and I informally call it C+ :)

I think the niche of "more than C, but not C++" is going to be eaten by Rust. It's like C with modules, Vec, String, HashMap, and one standard sensible cross-platform build system.

It might, but Rust still needs to grow a matching eco-system.

Rust has plenty of advanced language features that can entertain the same kind of people who enjoy writing C++ template metaprogramming as a brain teaser.

In practice Go is making inroads in that area. Since Rust has similar complexity to C++ it's not really comparable to C or Go.

Go is a nice language growing in popularity, but it's not a C replacement.

Garbage collection, big runtime, and non-zero-cost FFI are acceptable trade-offs in many areas of programming, but they are deal-breakers for domains where C (or Rust) is necessary.

Rust is somewhat similar to C++ in the feature set, but not in complexity. Rust's features are more orthogonal, without duplication and backwards-compat warts, and you get hand-holding by the compiler.

C is "misused" for a lot of things and Go is a contender in those areas though.

Technically you could be right about complexity vs. feature set, but from the POV of someone that's using a simple language, the two don't look that different. One does help you avoid certain errors, although whether that counts as hand holding or hand slapping is in the eye of the beholder.

I don't know. Rust is still pretty complicated. I'm hoping Zig will have success here as a better C.

And templates, and standard algorithms, and move semantics, and lots of other things that are pretty much necessary in modern code. Well, not necessary, but by restricting yourself from using them you are needlessly:

* creating more work for yourself, and

* introducing bugs in your code.

Don't do that. Use C++ as C++.

If I want all the advantages of that stuff I'll just use rust.

Agreed. The bigger C++ gets, the more important it becomes to treat it as "C with some cool extras" and to consider any and all new features as optional extras that you only use if you legitimately need them. The moment you start seeing "C with classes" style as a bad thing, you will slowly wander off into the wilderness.

The vast majority of the real world code a C++ programmer writes day to day is just that.

Reply on news.ycombinator.com