Live data from Hacker News

C++ is not a superset of C

mcla.ug

71–80 of 114 posts

Re: C++ is not a superset of C

#71
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…

> This means that it cannot be used safely in portable incantations of variadic functions that expect pointer arguments.

Why only variadic functions? The answer to that may make my next question obsolete, namely: Wouldn't only C++ complain about this? In C, isn't the input to anything coerced to the data type it will represent, in actual complete disregard of the input type?

Re: C++ is not a superset of C

#72
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

Re: C++ is not a superset of C

#73
post #58

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.

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)

Re: C++ is not a superset of C

#74
post #57
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. :-)

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

Re: C++ is not a superset of C

#75
post #73
post #58

Earlier quoted context omitted.

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.

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 c…

>I wondered if it just has constant expression semantics for const variables.

That would be my guess also, for applicable const variables. File scope const variables are quite constexpr-y in C anyway, since C requires all file scope variable initializers to be constant expressions (C++ only requires that for constexpr variables).

Toying around with clang in Godbolt, it seems that there are some quirks regarding this. The following is accepted:

  static const int n = 0;
  int buf[n]; // invalid zero-length array is accepted
              // probably another non-standard extension
But the following is not, despite n having the same zero value:

  static const int n;
  int buf[n]; // complains about a file scope VLA

Re: C++ is not a superset of C

#76

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

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

Re: C++ is not a superset of C

#77
post #10

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…

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.

Re: C++ is not a superset of C

#78
post #57
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. :-)

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.

Re: C++ is not a superset of C

#80
post #61

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?

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