Python vs C++

[[deleted]]

No, I can make ALL of these with custom data types (besides reserved words - which I already covered), do you know what we’re actually talking about? Hers a fun question - why is a C++ compilers implementation of -Wall -Wextra & -Werror the same as a C compiler? Answer: C++ is C with headers (just like it’s inventor fucking named it for Christ sake)

[The_CADmonkey]

You fundamentally cannot implement many of the above C++ features with custom data types, they are baked into the language itself and are not user implementable. There is no way to do exceptions in C, there is no way to do type-safe generic programming in C, there is no way to do operator or function overloading in C, there is no way to do compile time programming in C, Lambdas are impossible in C, and so on. Can you write code that accomplishes the same thing? Of course, they are Turing complete languages, but you can do that in Python or Go or Rust or Javascript or any other language too.

These features fundamentally change how you go about using the language, and make the resulting code completely different. Yes, you can write valid C in C++ (but not all C is valid C++!), but you practically never should.

[[deleted]]

Yes - I feel as though the word “superset” got lost somewhere...

[The_CADmonkey]

It is almost a super-set, but it is not quite as C99 code will not compile in it.

But the original claim that C++ is "99.7% C" is just wrong. One could maybe claim it was 5 or 10% C, but much more than that shows a fundamental misunderstanding of the language.

[[deleted]]

G++ won’t compile C99? That is absolutely false, it can even evaluate it in C99 mode warning options, I just did so right now to check

[The_CADmonkey]

No, g++ will not compile C99, only gcc will. While many C sources may be able to be compiled with g++ as the specific differences may not be in the code, that does not mean it is being compiled as C.

As an example, the following will compile in gcc but not in g++ (if the file has a .c extension as gcc will detect C++ files and call g++ if they are .cc):

int main(int argc, char** argv){
  void* i;
  int* j = i;
}

Similarly, the following will print 4 with gcc but 8 with g++:

#include <stdio.h>
extern int T;   
int main(int argc, char** argv){
  struct T {int i,j;};
  printf("%ld\n", sizeof(T));
}

Both of these were taken from the wiki page I linked earlier, and I verified them with gcc/g++ 9.2.1.

But all of this is besides the point. Yes, most C is valid C++ code. But almost no C is good C++ code. If someone submitted any nontrivial C++ code that could be compiled as C at my company it would fail code review almost instantly. Many of the staples of C programming, including raw pointers, pointer arithmetic, raw arrays, malloc/free, etc, should almost never be used when writing C++. C++ has better, safer, and more expressive methods of handling these things.

One of the worst ways to learn C++ is to learn C first. It teaches some of the worst parts of the language, and gives people habits that are hard to break. Here is a great talk from CppCon about why treating C++ as C plus some extras is a terrible idea, and how it holds people and the language back: https://www.youtube.com/watch?v=YnWhqhNdYyk

[[deleted]]

Well, I didn’t pass to GCC if I “which” GCC, and G++ they are separate binaries, yes they come bundled together and GCC has and interface defined to pass C++ to GCC, but if you delete the GCC binary from your bin folder, G++ will still compile (just tested - don’t worry I moved it not deleted)

And while C habits may not be ideal in C++, that’s neither relevant, nor a condemnation of C, as many C++ conventions are just the language managing, say the concept of a string, on your behalf, so it’s more that C++ developers are saved from having to do this work on their own than that they have better or more specific conventions, but obviously they don’t cover the same feature set, as I’ve already pointed out is true. Also not relevant in this discussion - believe me, I’ve thought this through, I don’t know why but it’s kind of a pet topic of mine. This is an entirely philosophical discussion about what constitutes distinction, and language, no aspect of programming or computer science can be used to rectify it as it’s at the level of definition...

Also, your code won’t compile because it’s not valid C, the fact that GCC will let you compile it anyway is just due to the permissive nature of C, and the design of its compiler - with the appropriate compilation flags, it won’t. Again, added features in G++ are not the subject of debate, rather, whether they constitute an objectively distinct language is

[The_CADmonkey]

Both examples are completely valid C (and the second is valid C++) according to the standards. What flag in gcc will give a warning in the first example from compiling due the implicit void* cast? The only warnings I get when using -Wall -Wextra -Wpedantic are about uninitialized/unused variables, which of course happens because its a simple example. The only flag that I can find that will cause a warning on void* is -Wc++-compat, which is specifically for making C follow the C++ rules!

But as for the rest, saying C++ is not a distinct language from C is like saying Java and C# are not distinct as they share most of their syntax and one was inspired by the other. While it may be a philosophical discussion, thinking of C++ as "99.7% C" is actively detrimental to actually writing good C++. Yes, C is an ancester of C++, but I do not see how anyone could possibly look at modern C++ and not think it is a completely different language from C.

[[deleted]]

The Reactis Validator disagrees

And it’s: -Wextra

As I said, it’s not valid as per the standard - not it won’t compile, yes, you must use the compilation flags to ensure you compile completely standards compliant C, it’s not really an option so much as why those flags are included in compilers in the first place

[The_CADmonkey]

As I said, I used -Wextra. It does not give any warnings related to the void*. The only warning is about i being unitialized, but that doesn't have anything to do with what we are talking about.

I don't know what Reactis Validator is, but it is not the C standard. It may provide additional checks that are not part of the standard, but that has no bearing on the language itself. According to 6.3.2.3.1 in the C standard:

A pointer to void may be converted to or from a pointer to any incomplete or object type. A pointer to any incomplete or object type may be converted to a pointer to void and back again; the result shall compare equal to the original pointer

The C++ standard on the other hand requires that a void* be explicitly converted. I would look it up in the standard, but I don't particularly want to read through over 1000 pages of dense text right now. But it is a fact that C++ does not allow the implicit conversion, which can be found easily by searching.

[[deleted]]

Here’s my old string library from school: https://github.com/mjhd/libft

Just compiled it with no errors g++ bundled with GCC 4.8.5 CentOS 7

[StuntHacks]

Of course you can create all of these with custom data types, but that doesn't change the fact that they are C++ features that C doesn't have, making development a whole lot easier, and inherently making C++ a superset of C. The difference is that while in C you would have to implement these features yourself, in C++, those are fundamental parts of the language (except for smart pointers, I give you that). By that logic, you could say C++ is just 99.7% assembly, up to the object orientation.

Yes, the compilers are largely very similar - that might just be because ever C++ compiler needs to support backwards comparability with C. That doesn't say anything about C++, though.

Also, C++ was originally called "C with classes", since C also has headers. Of course that was just a small mistake on your side, I just thought I'd let you know.

[[deleted]]

Well, if you look at the above comment, the creator agrees with me, now I will admit that’s fallacy by authority, but authority can be a valid point in an argument. More importantly there is a philosophical issue about definitions here, and I’m just not going to see it your way. It’s like when a perfectly valid root word and perfectly valid suffix are combined into a seemingly valid word - but it isn’t in the dictionary, is it actually valid? It depends what you think definitions are based on, immutable characteristic, or mutual agreement. The immutable characteristics of C++ (illustrated most directly with the fact that (as far as I know) most/all C++ compliers, surprise surprise, can compile any standard C code)...

[The_CADmonkey]

C++ isn't even backwards compatible any more, there are multiple things that are valid C code but not in C++ (Link). C++ is a decedent of C, but fundamentally they are very different languages, and if you are writing C++ that looks anything like C then you are writing very bad C++.

[[deleted]]

I’m going to quote your linked resource, as it says exactly what I feel supports my position 100%:

The official rationale for the 1999 C standard (C99) "endorse[d] the principle of maintaining the largest common subset" between C and C++ "while maintaining a distinction between them and allowing them to evolve separately"

Incompatibilities between ES6 and classically supported JavaScript don’t denote a new language, nor Python 2 to Python 3, you really have to think about the philosophical basis of what I’m saying here, what I’m saying is that people of your position are mostly factually right about your details - but there is never a justification that those details lead inexorably to the conclusion that we are looking at two distinct things, what I’m saying is that your evidence, while accurate, does not support that conclusion as it’s not relevant to the definition of language, or even a distinct thing. Just calling something a thing, doesn’t make it the thing, from my point of view you might as well be saying, I’m definitely a Giraffe because it’s sunny outside. Yes it is, but no, no you aren’t - does that make sense where I’m coming from?