10 ms·
C++ is not a superset of C
- adamnemecek 7y agoVery 1995, no offense.
- deleted 7y ago[deleted]
- Japhy_Ryder 7y agoAgreed.
- stephen82 7y agoI 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 7y agoIn other news, 1+1=2; and two wrongs don't make a right (but three lefts do.)
- jhatemyjob 7y agoAnd now it's time for the show!
- mhh__ 7y agoI thought this was common knowledge? Pointer aliasing for example
- monocasa 7y 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_ 7y agoYes, 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.
- loeg 7y agoIt'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)).
- _kst_ 7y agoI said enumeration constants are of type int. For example, given: enum foo { this, that, the_other }; enum foo obj; obj is of type "enum foo", which is compatible with some implementation-defined integer type, but the constants "this", "that", and "the_other" are of type int. In C++, the constants are of type "enum foo", which can also be referred to as "foo".
- saagarjha 7y 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 7y agoIndeed, auto-vectorization usually won't work without it...
- lochsh 7y agoThis 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 7y agoI 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 7y agoI've definitely heard c++ described this way.
- Animats 7y agoIt 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.
- loeg 7y agoIt was maybe a superset for the brief period between C++98 standardization and C99 standardization the following year.
- _kst_ 7y agoPointers and arrays are not the same thing. See section 6 of the comp.lang.c FAQ, http://www.c-faq.com/ http://www.c-faq.com/ . I doubt that C++ was ever a strict superset of C. Has int class; ever been a valid declaration in C++?
- eesmith 7y agoOnce C++ gained "//" for comments - which was the original release in 1983 - it was no longer a superset: uses_BCPL_style_comments = 1 //* */ 2 ; C99's // support did not restore the superset nature. This means your "once" was almost certainly "never".
- MauranKilom 7y agoYou 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.
- _kst_ 7y agoSeveral 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.
- lochsh 7y agoThanks, this is useful! I'll have to look at the standards again and be more precise in my language.
- klingonopera 7y 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]
- lochsh 7y agoI 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_ 7y agoN1570 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 7y agoThis 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 7y agoI am hoping this isn’t an implication that C is legacy and C++ is the modern and the future. :-)
- robbrit 7y agoNot 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.
- EliRivers 7y agoAs a view into a different part of the industry, when I was writing code for cheap embedded processors, it was C code all the way.
- colonwqbang 7y agoI write code for expensive embedded processors and it's still C all the way, with C++ recently starting to make a (small) appearance. As such I'm acutely aware of the wonderful incompatibilities between C and C++. My favourite is this: 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
- ncmncm 7y agoYes, embedded development has always been stuck in the stone age. C is actually a recent, and major advance over assembly. It happened only because vendors discovered they could steal accounts from competitors by being source-compatible, even though their ISA was different. C++ does not offer that advantage for them, no matter how much it might benefit developers, so they have no intention of ever supporting it. But Arduinos are programmed in a dialect of C++, so it will become necessary to enable it in the near future, i.e. by 2030. Civilization might fall first.
- powzapbiff 7y agoThe 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 https://en.wikipedia.org/wiki/Variable-length_array#C99
- lochsh 7y agoYes, 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.
- eMSF 7y agoTo 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.
- lochsh 7y agoThis 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 https://godbolt.org/z/q-bb-n c99 with clang https://godbolt.org/z/ad14Ah https://godbolt.org/z/ad14Ah c11 with clang https://godbolt.org/z/xJSDQa https://godbolt.org/z/xJSDQa c11 with gcc (which is the only one giving the output I'd expect)
- eMSF 7y ago>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
- stephen82 7y agoNearly 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/ https://gustedt.wordpress.com/2018/11/12/c2x/
- mehrdadn 7y agoAre they trying to make C literally become the same as C++ except classes and templates?
- banachtarski 7y agoAre classes and templates not the bulwark of what makes C++ C++ though
- stephen82 7y agoWell, 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.
- loeg 7y 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.
- nneonneo 7y agoNit: memmove allows src and dst to overlap while memcpy does not.
- lochsh 7y agoAh 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 7y agoBeen 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 7y agoThe 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)
- deleted 7y ago[deleted]
- tambourine_man 7y agoWhich is part of the beauty of ObjC
- ncmncm 7y agoAs Stroustrup said, "Smalltalk is the best Smalltalk I know of."
- vwstt 7y agoThat pink background to the left weighs 6 MB. Do you really think it's necessary?
- lochsh 7y agoI 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 :)
- bt848 7y agoI think your blog looks great. The color palette you are using for text is very pleasing.
- lochsh 7y agoThank you! ^_^
- jarjarbinks455 7y agoYou 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.
- lochsh 7y agoI've converted it to jpg and it's now 448K :)
- ndesaulniers 7y agoDesignated 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; });
- loeg 7y agoGNU C extensions are well outside the scope of standard C (or C++).
- deleted 7y ago[deleted]
- pietroglyph 7y agoThe 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 https://stackoverflow.com/a/29337570 for more info and examples.
- camgunz 7y agoTo offer a different opinion, I love the design/images/color scheme. Feels fun and creative.
- lochsh 7y agoThank you so much! This is lovely to hear. ^_^ I like it too.
- faehnrich 7y agoReminds 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/ http://faehnri.ch/how-c-is-not-a-subset-of-cpp/
- lochsh 7y agoBeing told my web design is kinda cyberpunk is a great compliment, thank you ^_^ I like the banner image on yours.
- jancsika 7y 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.
- lochsh 7y agoIt 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."
- pmul 7y agoThe 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.
- pmul 7y agoThe 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?
- lochsh 7y agoyou're right, I messed up here. I'm working on some updates to the blog post based on feedback.
- autoexec 7y agoI 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 7y agoWhat are they?
- user5994461 7y agoDoubt 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.
- autoexec 7y agoI'm still using perl scripts for log parsing and some general sys-admin type stuff, but yeah, it's way past its prime.
- kazinator 7y agoC++ 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.
- lochsh 7y agoI'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.