The two languages really should be used as different tools as although there is obviously significant use-case overlap, each excels at its own niche. C++ is quite beyond C with classes. Personally, I think C++ should continue to evolve far away from C (though as of C++20 we now have C99's designated initializers). C is "perfect" for what it is, dare I say it. C++ can incorporate things we've learned from other languages like Rust's memory safety and be better for it. Though to be fully honest I haven't totally worked through the revised memory model of C++20 and it would be great if someone could shed some light on that.
> though as of C++20 we now have C99's designated initializers
C++20 only supports a thin imitation of C99's designated initializers. In C99 you can a) mix definition forms (designated and non-designated), b) define members out of order, and c) override earlier definitions. C++20 doesn't support any of these. I've often relied on a and c in initializer macros that provide default, non-0 values that can be overridden (using vararg parameters) by the user, but many might see that as unclean. The lack of b, however, significantly diminishes the value of designated initializers: by reordering struct members you invalidate all uses of designated initializers for that type in C++20, which means they're useless to minimize the burden of refactoring.
Also, C++20 doesn't permit designated array initializers, which I've found very useful for arrays that map, e.g., enums to strings.
Definitions shift over time. Yes, C targets an abstract machine. Yes, C doesn’t give you direct access to hardware. But in the range of widely used languages C is much “lower level” so it gets that name. Quibbling over the definition doesn’t add to a conversation but just exists to make somebody look smarter than the room.
>C++ has a stronger type system, and unfortunately using C idioms punch a giant hole in that type system, and so C compatibility has a cost in terms of safety.
This may sound like C++ has a strong type system, but it's only a little stronger than that of C, if at all.
That's author's words, I'd say it's stuff like narrowing conversions, arrays and memcpy. Though the author doesn't claim that memcpy is a C idiom, and indeed it's used broadly in C++.
A properly formed modern C++ program doesn’t really use memcpy. Most idioms from the C language have a much stricter counterpart that is part of the C++ language.
You’ve made a few comments now about a language that you don’t seem to actually use or know.
Of course a C-style array in C++ doesn't have a defined end. It doesn't have an end in C either. But in C++ you don't need to be using those anyway.
Part of the issue is that, while you can use the usual C idioms in C++ (e.g. a function takes an array and its length as arguments), you don't need to, especially if you're using C++ correctly. This is one of the points of the article.
Like hellofunk said, this has nothing to do with the type system. But the solution to what you're talking about is fundamental C++: use the standard library.
> But the solution to what you're talking about is fundamental C++: use the standard library.
The safety-critical real-time embedded systems where strong static typing would be most useful often don't have the standard library available. Even in C it's not unusual to need to justify every line of code in the final product, which precludes linking against an all-inclusive libc—at best you might get a vetted subset. The design constraints, too, are often incompatible: "no vararg functions" (printf), "no recursion" (qsort/bsearch), "no dynamic memory allocation" (malloc). Where C++ is allowed it is often with additional restrictions like "no RTTI" and "no exceptions" which would rule out large portions of the STL, including most collection types. By the time you take all these coding standard issues into account you generally find that you're writing in a novel language which is just enough like C++ to cause confusion. C++ programming for these environments is not like the C++ which is taught in schools or practiced in other fields. There is a lot to unlearn.
I’m not sure what you’re talking about, to be honest. First, what does this have to do with the type system? Second, C++ typically uses vectors, which know exactly where they end, with the option to use an indexing into them that will throw an exception if you try to access them out of their range. C certainly does not have that.
I will continue to say C/C++. To me they are not distinct enough as languages to truly be considered fully separate and they use the same compilers. The fact that they use the same compiler is to me a devastating argument. No other distinct languages use the same compiler.
>A language is also its good practices, patterns, idioms
The usual argument, but I disagree. If programmers don't have freedom of expression then fuck programming. We should all be free to write our own programs the way we want and not have to worry about standard practices or cultures.
- Ada, D, Delphi, Fortran, Haskell, Julia, Objective-C, Rust, and Swift (if you go by LLVM)
- Objective-C, Objective-C++, Fortran, Ada, and Go (if you go by gcc)
It is true that you should have the freedom to write code in any way you want. Thankfully employers have the freedom to reject your code if you don't follow their practices. Just like with freedom of speech, you have a right to say what you want without fear that the government will punish you, that doesn't mean you're shielded from what other people think of you.
But seriously: I wish more programmers had really good background (I'm not talking about academia, but e.g. learning from many books and conference videos).
The "good practices" are often a set of ideas like "do it this way, so you won't suffer later". Nothing more. This way you can avoid mistakes made by others. Of course, you can do whatever you like and suffer later.
C is C. C++ is C++. If they are the same, well... why do they have different names?
Let's call them C/C++/Fortran OK? You can use one tool (you called it "one compiler", while in fact they are different compilers with common core) to rule them all, even in the same program... https://www.cae.tntech.edu/help/programming/mixed_languages.
I'd love to see more programmers naming things with care. This way we would have C, we would have C++. But also we would have MB when talking about megabytes, not mb (millibits, is that even a thing?).
If surgeons would have freedom to do things the way they want... in fact they have the freedom, but they rather follow the "good practices" made mainly by the retrospection after someone made a tragic mistake. But if they really would do whatever they want... let's not talk about it for now, OK?
While I agree with C/C++ term as shorthand for "C and C++" as it is widely used across ISO papers, C++ books and FAANG official documentation, I don't care about C and ISO C++ doesn't require C++ compilers to also bundle a C compiler in the package.
That is an historical accident of C compiler vendors adopting C++ and C++ being also a language out of Bell Labs.
> To me they are not distinct enough as languages to truly be considered fully separate
There are plenty of subtle differences, precisely because they aren't the same language. [0][1] They're deeply connected, but there are important differences between them, and it doesn't do to gloss over the details. For instance, empty structs are permitted in C++ but might get you into trouble in C. [2]
> they use the same compiler
Many of the major compiler suites support lots of different languages. You can compile Fortran, C, and C++ code using LLVM, GCC, ICC, or even OpenWatcom. So what?
It's true that where you find a C++ compiler, you generally find a C compiler, but the converse does not hold. The TCC C compiler doesn't support C++, for instance. The same goes for many of the more obscure C compilers out there.
Also, sometimes a compiler suite will have solid support for C++ but poor support for C. If you want to do modern C++ programming on Windows you might use MSVC, but MSVC has surprisingly awful support for C. [3]
> We should all be free to write our own programs the way we want and not have to worry about standard practices or cultures.
Disagree. It can improve quality to use strict coding-standards and a strict language. Software development is not about maximising creative freedom, it's about effectively developing high-quality solutions, see [4]. This is the reason software in safety-critical domains like avionics is never free-form, it invariably uses highly restrictive coding-standards like MISRA C, or highly restrictive languages like SPARK Ada.
(Hope that wasn't too off-topic, my points there don't pertain whether a 'language' should be understood to include its conventions.)
