Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ is not a superset of C

mcla.ug

Post reply on HN
Print view View original

51–60 of 114 posts

Re: C++ is not a superset of C

#51

Post by Laakeri »

lochsh wrote: post #20
jdmoreira wrote: post #9

I never heard anyone say that C++ is a superset of C. Sure, the first version was a preprocessor on top of C and certainly that is common knowledge. But a superset? Never heard it. ObjC on the other hand...

I think it's quite a common thing for people to say if they're not actually experienced in writing the languages. I've heard it from multiple people. As I say in the blog post, it's common knowledge for people who are experienced in writing C and/or C++ that this isn't true. But it's a misconception that persists among other programmers.

Have you seen practical cases where there has been issues because C code is not compatible with C++? The blog has nice toy examples, but would be nice to know if they actually occur in the wild.

Re: C++ is not a superset of C

#52

Post by faehnrich »

Reminds me of a blog post of mine[1].

Funny that I say C is not a subset, while this says C++ not a superset.

But mine doesn't go too deep, don't reference any standards.

I love things that explore dark corners of languages like this, look forward to digging deeper.

Also, I like the web design, kinda cyberpunk.

1. http://faehnri.ch/how-c-is-not-a-subset-of-cpp/

Re: C++ is not a superset of C

#53

Post by lochsh »

faehnrich wrote: post #52

Reminds me of a blog post of mine[1]. Funny that I say C is not a subset, while this says C++ not a superset. But mine doesn't go too deep, don't reference any standards. I love things that explore dark corners of languages like this, look forward to digging deeper. Also, I like the web design, kinda cyberpunk. 1. http://faehnri.ch/how-c-is-not-a-subset-of-cpp/

Being told my web design is kinda cyberpunk is a great compliment, thank you ^_^ I like the banner image on yours.

Re: C++ is not a superset of C

#54

Post by loeg »

mehrdadn wrote: post #34
stephen82 wrote: post #17

Nearly everything that is mentioned in this blog is a subject of change / addition to the latest C standard, code named C2x. They are in discussions to introduce the following in C: * nullptr * auto * __has_include * make false and true first-class language features * constexpr and lots of other goodies [1]. https://gustedt.wordpress.com/2018/11/12/c2x/

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 true first-class language features" means — maybe make them reserved keywords? (int)true must still evaluate to 1, in any event.

[0]: "C++ is C with classes!"

[1]: C's "NULL" has this obnoxious wart in that it is implementation-defined whether or not it is a pointer type. I.e., it can be "(void *)0" or just "0". This means that it cannot be used safely in portable incantations of variadic functions that expect pointer arguments.

Re: C++ is not a superset of C

#56

Post by mehrdadn »

loeg wrote: post #54
mehrdadn wrote: post #34

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…

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...

Re: C++ is not a superset of C

#57

Post by siggen »

umvi wrote: post #13

This is true, but C++ is mostly a superset of C, which is "good enough" for the vast majority of developers. It's enough of a superset that we were able to seamlessly integrate our legacy C libraries with our modern C++ applications without hassle (and we didn't run into any of the corner cases listed in the article).

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

Re: C++ is not a superset of C

#58

Post by eMSF »

powzapbiff wrote: post #14

The code: const size_t buffer_size = 5; int buffer[buffer_size]; compiles fine in c, but not for the same reason. C99/C11 has dynamic arrays https://en.wikipedia.org/wiki/Variable-length_array#C99

To be exact, it doesn't compile fine outside of functions (which the sample code didn't have) because file scope arrays can't be VLAs.

Re: C++ is not a superset of C

#59

Post by pmul »

The first example doesn't produce undefined behaviour as c++ - it just won't compile - you can't initialise that pointer to a non const int from a const int without doing something naughty like a const_cast.

Re: C++ is not a superset of C

#60

Post by loeg »

_kst_ wrote: post #12
monocasa wrote: post #6

> The size of the array needs to be known at compile time. In C++, a const variable can be a constant expression, meaning it can be evaluated at compile time. In C, this is not the case, and we must instead use a pre-processor macro: Enums are also good here in C land for specifying compile time constants.

Yes, but only for constants of type int. For example, this is valid: enum { ANSWER = 42 }; But C enumeration constants are always of type int, so you can't define a constant of some other integer type this way.

It's worse than that. The type of a C enumeration is implementation defined. It must cover the full range of defined values, but it definitely doesn't have to be 'int'. (§ 6.7.2.2 (4)):

> Each enumerated type shall be compatible with [ed: one of] char, a signed integer type, or an unsigned integer type. The choice of type is implementation-defined but shall be capable of representing the values of all the members of the enumeration.

One possible source of confusion is that explicit values in an enum (i.e., '42' in your example) must have values representable as int. (§ 6.7.2.2, (2)).

Post reply on HN