C++ is not a superset of C

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

by lochsh • 7 years ago

107 107 7 years ago

mcla.ug

adamnemecek• 7 years ago

Very 1995, no offense.

Japhy_Ryder• 7 years ago

Agreed.

stephen823• 7 years ago

I hope you mean the website theme.

If yes, indeed.

I had to view in Reader mode via Firefox.

I could not read it, I got dizzy by its colors; my sensitive vision couldn't stand it -_-

einpoklum• 7 years ago

In other news, 1+1=2; and two wrongs don't make a right (but three lefts do.)

jhatemyjob• 7 years ago

And now it's time for the show!

mhh__• 7 years ago

I thought this was common knowledge? Pointer aliasing for example

mark-r• 7 years ago

Common knowledge is like common sense - not as common as you'd think.

gpvos• 7 years ago

I knew most of those things except for the pointer aliasing details.

monocasa• 7 years ago

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.

_kst_7• 7 years ago

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.

loeg8• 7 years ago

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

saagarjha• 7 years ago

I'm suspicious of restrict. It seems like playing with fire, and anecdotally it seems common to run into compiler optimisation bugs when using it because it's exercised so little.

On the contrary, I wish C++ had restrict in the standard, for exactly the reasons mentioned: it can help the optimizer in certain cases.

cozzyd• 7 years ago

Indeed, auto-vectorization usually won't work without it...

lochsh15• 7 years ago

This is all totally fair -- I've never used restrict, so it's hard for me to have a useful opinion on it.

I think it's easy to dismiss things that can help optimisation when you've never seen their effect first-hand. I imagine if I'd had an experience where I'd used it to great advantage I'd be wishing it was in the C++ standard too :)

jdmoreira• 7 years ago

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

dahfizz• 7 years ago

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

Animats• 7 years ago

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.

MauranKilom• 7 years ago

You evidently haven't been looking at the stackoverflow questions coming in at the [c] and [c++] tags... ;)

A frightening amount of [c][c++] tagging is expunged there every day.

EpicEng• 7 years ago

And 90% of those posts are made by beginners with a crashing linked list implementation. They're uninformed.

Veedrac• 7 years ago

Which is often just meaningless pedanticism. There are a lot of questions about C APIs where it's irrelevant whether the answer uses C or C++. The latter might not be an exact superset, but in most cases it's easily close enough.

lochsh15• 7 years ago

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.

Laakeri• 7 years ago

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.

dec0dedab0de• 7 years ago

I thought it was until just now. I've never done anything of substance in either, but I've tried both. Now I'm wondering if it was something I heard, or if I just assumed based on my extremely limited experience with both languages.

eesmith2• 7 years ago

FWIW, https://duckduckgo.com/?q=%22C%2B%2B+is+a+superset+of+C%22&t... finds things like:

- C++ is a superset of C, and that virtually any legal C program is a legal C++ program. https://www.tutorialspoint.com/cplusplus/cpp_overview.htm

- "C is a subset of C++." / "C++ is a superset of C." https://www.geeksforgeeks.org/difference-between-c-and-c/

- "C++ is a superset of C; (almost) anything you can do in C, you can do in C++." https://www.cprogramming.com/begin.html

- "As you recall C is a root for C++ and C++ is a superset of C." https://www.c-sharpcorner.com/article/similarities-and-diffe...

_kst_7• 7 years ago

Several of the examples shown as valid C are not.

For example, this:

    const int foo = 1;
    int* bar = &foo;
    *bar = 2;

is said to have undefined behavior, but in fact the initialization of `bar` is a constraint violation, requiring a diagnostic. (Some compilers will issue a non-fatal warning, which is allowed by the C standard but IMHO is unfortunate.)

Another example: it says that this:

    const size_t buffer_size = 5;
    int buffer[buffer_size];

will not compile in C, but it's valid at block scope in C99, which introduced variable-length arrays. (C11 made them optional.)

"In C, this would compile, albeit likely with warnings about implicit conversion:"

    int main() {
        auto x = "actually an int";
        return x;
    }

The "implicit int" rule was dropped in C99, and even before that the language did not define an implicit conversion from char* to int. Again, some compilers might support it with a warning, but it's a constraint violation.

lochsh15• 7 years ago

Thanks, this is useful! I'll have to look at the standards again and be more precise in my language.

klingonopera2• 7 years ago

Some compilers will issue a non-fatal warning, which is allowed by the C standard but IMHO is unfortunate.

GCC 5.1.0 reports:

  warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]

lochsh15• 7 years ago

I haven't been able to find anything in the C11 standard about the initialisation of bar being a constraint violation. In 6.7.3, the only constraints for type qualifiers listed are for _Atomic and restrict. Could you let me know where you got the information you talk about here from? I could be missing part of the standard.

_kst_7• 7 years ago

N1570 6.7.9p11 says that the constraints and conversions for simple assignment apply to scalar initializers.

6.5.16.1p1 says that, for pointers, "the type pointed to by the left has all the qualifiers of the type pointed to by the right".

In this case, the right operand is a pointer to a const-qualified type and the left operand is a pointer to a non-const-qualified type.

(Without this restriction, you could silently discard const qualification just by assigning or initializing a pointer, which would largely defeat the purpose of const.)

umvi• 7 years ago

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

siggen• 7 years ago

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

robbrit• 7 years ago

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.

Gibbon12• 7 years ago

C is a niche language and C++ is about to hit the wall as companies abandon it for languages like Go and Rust.

bitwize• 7 years ago

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.

powzapbiff• 7 years ago

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

lochsh15• 7 years ago

Yes, I think I made an embarrassing mess up here by using a compiler that doesn't support VLAs, and not fully understanding VLAs. Thanks for pointing it out.

eMSF2• 7 years ago

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.

lochsh15• 7 years ago

This is what I was going for in the blog post, but I got confused after seeing these comments as Clang _does_ compile this when the buffer is of static storage class.

Which I don't think is standard -- but it's not using VLAs. I wondered if it just has constant expression semantics for const variables.

Weirdly, adding a _Static_assert to test this theory proves it for c99 but not c11 :/

https://godbolt.org/z/q-bb-n c99 with clang https://godbolt.org/z/ad14Ah c11 with clang https://godbolt.org/z/xJSDQa c11 with gcc (which is the only one giving the output I'd expect)

stephen823• 7 years ago

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/

mehrdadn2• 7 years ago

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

banachtarski• 7 years ago

Are classes and templates not the bulwark of what makes C++ C++ though

stephen823• 7 years ago

Well, they are trying to slim down, so to speak, the gap between C and C++ for the sake of a safer interoperability between the languages and for the sake of safer and secure code.

If C could fix _Generic from C11 and make it behave more like a lightweight version of templates, then I could say we have a huge potential of having a safer version of what we currently have.

loeg8• 7 years ago

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.

turndown• 7 years ago

I do not really care about new features to C - I would just use C++ for these features - but what is your specific argument against something like auto? Or just in general on new features.

glouwbug• 7 years ago

"Add a type aware print utility with format specification syntax similar to python"

Now thats exciting

czr• 7 years ago

does anyone have more information on this? only reference I can find is that blog post; I can't find the specific section of the linked specs that discusses such a utility

colonwqbang3• 7 years ago

__attribute__((format(printf, ...))) makes printf every bit as type-aware as I need it to be. Put that in the standard instead.

nneonneo• 7 years ago

Nit: memmove allows src and dst to overlap while memcpy does not.

lochsh15• 7 years ago

Ah yes, what I meant was that more optimisations can be made on memmove if we restrict src and dst, as the overlap case no longer needs to be considered.

I've never used restrict, so I could be missing something, but this is what I meant in the blog post by mentioning memmove.

alexnewman• 7 years ago

Been saying this for years. The weird part is that it's a good thing. C++ redefined auto and it has never been the same.However it's clearly a better language than it was in 2010

jcranmer• 7 years ago

The C++ specification has an entire appendix devoting to listing incompatibilities with C. Some features missing from this list:

* A char literal is an expression of type int in C, but type char in C++.

* String literals are const in C++ but non-const in C (although attempts to modify them are undefined behavior).

* This program is legal C but not C++:

   int i;
   int i;

* structs and unions occupy a different name space in C than they do in C++.

* main cannot be recursive in C++, but it can in C.

* C++ allows lvalues in a few more places. Usually, this amounts to a compiler error, but there are a few places where the additional lvalue-to-rvalue conversion is legal and produces a different result.

* There are some cases where C++ requires an explicit cast that C permits an implicit cast (void* being the most well-known)

tambourine_man• 7 years ago

Which is part of the beauty of ObjC

ncmncm5• 7 years ago

As Stroustrup said, "Smalltalk is the best Smalltalk I know of."

vwstt• 7 years ago

That pink background to the left weighs 6 MB. Do you really think it's necessary?

lochsh15• 7 years ago

I should probably make it smaller! 6MB is pretty indulgent. But I do like how it looks and this is mostly just a fun blog for myself :)

bt8483• 7 years ago

I think your blog looks great. The color palette you are using for text is very pleasing.

jarjarbinks455• 7 years ago

You are also contributing to global warming. It takes a energy to transfer this data all over the world. And poor people will will run out of their monthly phone data limit.

lochsh15• 7 years ago

I've converted it to jpg and it's now 448K :)

ndesaulniers• 7 years ago

Designated initializers were added in c++20, I was just looking at a recent change to clang's semantic analysis that warns on the differences between C99 and C++20 designated initializers (Todo: post link when not mobile.)

One recent difference I saw was valid in (via GNU C extension) but invalid in c++:

    struct foo my_foo = ({
      init(&my_foo);
      my_foo;
    });

loeg8• 7 years ago

GNU C extensions are well outside the scope of standard C (or C++).

pietroglyph• 7 years ago

The designated initializers example will actually compile in recent versions of GCC, Clang, and Visual C++, even if that's not part of the standard prior to C++20. A better example (i.e. one that doesn't compile in C++ but does in C) would be

  int arr[3] = { [1] = 5 }

or even

  struct A c = {.x = 1, 2}

or another example where the designators are not declared in order of the struct members, or where the designators are nested. The version of designated initializers standardized in C++20 only allows the simple case that's currently implemented in all the major compilers.

See https://stackoverflow.com/a/29337570 for more info and examples.

camgunz• 7 years ago

To offer a different opinion, I love the design/images/color scheme. Feels fun and creative.

lochsh15• 7 years ago

Thank you so much! This is lovely to hear. ^_^ I like it too.

faehnrich• 7 years ago

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/

lochsh15• 7 years ago

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

jancsika• 7 years ago

The size of the array needs to be known at compile time.

In C99 the example you give does indeed compile and silently get turned into a VLA.

lochsh15• 7 years ago

It would only be a VLA if defined in a block, I intended the code snippet to be at file-scope, giving the buffer size and array static storage duration.

But it does indeed compile in Clang, and I'm looking into why. I think this line in the C11 standard might be key: "An implementation may accept other forms of constant expressions."

pmul2• 7 years ago

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.

pmul2• 7 years ago

The first example won't compile in c++ (can't get a ptr to a non const from a const without something naughty like a const_cast) - that's not undefined behaviour is it?

lochsh15• 7 years ago

you're right, I messed up here. I'm working on some updates to the blog post based on feedback.

autoexec2• 7 years ago

I love that roughly 35 years after its creation we're still arguing about what c++ is or is not in relation to C. I'm looking forward to the debates and blog posts of my grandchildren on Perl 6 vs Perl 5

harry8• 7 years ago

What are they?

user5994461• 7 years ago

Doubt either of our grandchildren will ever use Perl. It is truly an arcane language that has no niche and no new application written in it.

autoexec2• 7 years ago

I'm still using perl scripts for log parsing and some general sys-admin type stuff, but yeah, it's way past its prime.

kazinator• 7 years ago

C++ was once a near superset of C. However, due to language divergence, the situation is that both C and C++ are large supersets of an intersection.

What is in that intersection depends on which C and C++ dialect pair your intersect.

E.g. a newer C++11 dialect has "long long", so if intersected with C99, "long long" is in the dialect. If we intersect C++ older than C++11 with C, or C older than C99 with C++, then we don't have "long long".

(Except as a conforming extension from a compiler, which we could detect with a configure script and use anyway.)

The thing is that the intersection languages are basically fully fledged C: you can easily develop in them and do everything you'd want from C, if you're willing to live without a few frills here and there like C99 designated initializers, and variable length arrays (dropped from being required in C in C11) and whatnot.

If you require complex numbers, that could get hairy.

A long-time C90 programmer will not find anything amiss, though.

lochsh15• 7 years ago

I've made some updates to the blog post based on feedback -- thank you everyone who pointed out mistakes helpfully :)

I've made the updates clear, and linked to the archived version of the original post.

C++ is not a superset of C

Related Stories