C++ is not a superset of C (mcla.ug)

Very 1995, no offense.

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

I thought this was common knowledge? Pointer aliasing for example

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

    enum { ANSWER = 42 };

    enum foo { this, that, the_other };
    enum foo obj;

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

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

    int class;

   uses_BCPL_style_comments = 1 //*  */ 2
                    ;

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.

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

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

    struct point { int x; int y; };
    int main() { struct point p = { .y = 0, .x = 0 }; }

    error: designator order for field ‘point::x’ does not match declaration order

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

  static const int n = 0;
  int buf[n]; // invalid zero-length array is accepted
              // probably another non-standard extension

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

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/

    printf("NULL = %p\n", (void*)NULL);

    printf("null pointer = %p\n", (void*)0);

    void f(char *p);
    
         f(0); /* integer literal auto promoted to pointer */
    

    void f(...);
    
         f(0); /* assume type of function is void f(int) */

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

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

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)

Which is part of the beauty of ObjC

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

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;
    });

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.

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

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/

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

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.

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?

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

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.