Live data from Hacker News

C++ is not a superset of C

mcla.ug

101–110 of 114 posts

Re: C++ is not a superset of C

#101
post #99
post #81

Earlier quoted context omitted.

You're high. In industry C and C++ are very widespread. Go and Rust are ... not. You'll have an easier time finding a job that requires FORTRAN than one requiring Rust, and Go is only a bit more popular.

Lets touch base again in five years and see how C++ is doing.

Let's touch base in five years and see if anybody remembers Rust. It is likely they will, but not assured.

Consider that the number of programmers adopting C++ every day far, far exceeds the number adopting Rust, and the rate is increasing faster, in absolute numbers, than ever before, it is hard to imagine any scenario where C++ is less popular, relative to Rust, than today. Yes, C++ usage will less than double, while Rust usage will multiply, but the absolute difference in number will be much larger than today.

Re: C++ is not a superset of C

#102
post #54

Earlier quoted context omitted.

Are they trying to make C literally become the same as C++ except classes and templates?

> Are they trying to make C literally become the same as C++ except classes and templates? As a C programmer, aren't classes, templates, and exceptions the things that have classically differentiated C and C++?[0] I don't see anything obviously objectionable about nullptr[1], auto, __has_include, or constexpr. (I don't have a ton of experience with them, either.) I'll admit I don't really grok what "make false and tr…

> aren't classes, templates, and exceptions the things that have classically differentiated C and C++?

The key difference is the destructor. Classes, templates, and exceptions extend the reach and value of the destructor. Absent the destructor, the other stuff is of little value (cf. Java).

Re: C++ is not a superset of C

#105
post #67

Earlier quoted context omitted.

Not that I've worked in a lot of places, but everywhere that I've worked that uses C at all treats it this way. Writing new C code is considered a no-no.

As a view into a different part of the industry, when I was writing code for cheap embedded processors, it was C code all the way.

Yes, embedded development has always been stuck in the stone age. C is actually a recent, and major advance over assembly. It happened only because vendors discovered they could steal accounts from competitors by being source-compatible, even though their ISA was different. C++ does not offer that advantage for them, no matter how much it might benefit developers, so they have no intention of ever supporting it.

But Arduinos are programmed in a dialect of C++, so it will become necessary to enable it in the near future, i.e. by 2030. Civilization might fall first.

Re: C++ is not a superset of C

#106
post #16
post #11

Earlier quoted context omitted.

I've definitely heard c++ described this way.

It was a superset, once. C++ started as a C preprocessor. But the languages have diverged. It's enough of a superset, though, that C++ hasn't deleted bad features of C, like pointers and arrays being the same thing.

Once C++ gained "//" for comments - which was the original release in 1983 - it was no longer a superset:

   uses_BCPL_style_comments = 1 //*  */ 2
                    ;
C99's // support did not restore the superset nature.

This means your "once" was almost certainly "never".

Re: C++ is not a superset of C

#107
post #100

Earlier quoted context omitted.

I write C every day at a major silicon valley networking company. So it's not at all considered bad.

It is considered bad at many other places. I would add, more enlightened places. But competent C++ programmers are expensive. It is harder to tell whether a C programmer is competent, because the code they write has less room to be better than minimally tolerable.

[deleted]

Re: C++ is not a superset of C

#108
post #105

Earlier quoted context omitted.

As a view into a different part of the industry, when I was writing code for cheap embedded processors, it was C code all the way.

Yes, embedded development has always been stuck in the stone age. C is actually a recent, and major advance over assembly. It happened only because vendors discovered they could steal accounts from competitors by being source-compatible, even though their ISA was different. C++ does not offer that advantage for them, no matter how much it might benefit developers, so they have no intention of ever supporting it. But…

[deleted]

Re: C++ is not a superset of C

#109
post #64

Earlier quoted context omitted.

They're not the "problems" with C++, they're what make C++ great. It's like C is slowly realizing C++ features are actually useful, but doing so as slowly as molasses, while still trying to pretend like this isn't the case...

> [Classes, templates, and exceptions are] not the "problems" with C++, they're what make C++ great. We're going to have to agree to disagree on that one. > It's like C is slowly realizing C++ features are actually useful, but doing so as slowly as molasses, while still trying to pretend like this isn't the case... I think it makes sense to adopt C++ features that do some combination of (1) providing a useful feature…

C with templates (not classes), STL algorithms/ranges and small things like nullptr, auto, lambdas, stronger basic types, etc is actually a powerful configuration.

Re: C++ is not a superset of C

#110
post #78
post #57

Earlier quoted context omitted.

I am hoping this isn’t an implication that C is legacy and C++ is the modern and the future. :-)

C isn't just legacy, it's fundamentally broken. Rust is the future. C++, while it mitigates some of the brokenness of C, favored backward compatibility with C over fixing the brokenness once and for all.

Does the RESF just browse C/C++ threads waiting for the right moment to jump in and proselytize? It is not even mentioned once in the article.
Post reply on HN