Hacker News Reader

Comment by AdieuToLogic | Hacker News Reader

From the article:

  In 2019 I wrote a short survey of C constructs that do not 
  work in C++. The point was not that C is sloppy or that C++ 
  is superior. The point was that C++ is not a superset of C, 
  and that C programmers crossing the border should know 
  where the checkpoints are.

C++ was a superset of C 30-ish years ago. Now, as the author correctly identifies, it is not as both have taken different evolutionary paths.

View on HN

30 years ago, in C89 and pre-standard C++, it was the case that `int foo()` in C is a function that accepts any parameters, and in C++ it is a function with no parameters. In C89 you have to write `int foo(void)` if you want no parameters. This counterexample to C++ being a superset of C was well-known even back then.

Another well-known counterexample is implicit conversion from void*. In C89 you can do `int* foo = malloc(100);` but in C++ it requires an explicit cast from void* to int*.

I don't believe there was ever a time, even pre-standardization, when C++ was a strict superset of C; it always had little incompatibilities here and there.

Perhaps in c-with-classes(Cpre)? To the extent that its output could be considered C.

It looks like you're right and the answer to when was C++ a superset of C may well be "never".

From the description, Cfront had always been a full-fledged parser that only happened to output C since the very beginning.

> a full-fledged parser

perhaps more accurately a fully fledged compiler (that emitted C)

Already in C++98 there were differences.

?: has another execution priority.

Implicit cast scenarios are reduced in C++.

Reply on news.ycombinator.com