Well probably it would be sufficient to write simple programs. But maybe this guide is just too quick in that it just covers some basic syntax but leaves out a lot of goodies which actual programs use (no containers/algorithms at all, indeed no C++11 and beyond which is imo a shame for any recent C++ guide - there's not even any mentioning of it), doesn't adhere to current best practices (take 'double getVolume(void)': void argument has no place in C++ and should arguably be const, no error checking on stream methods) and seems too lack crucial information (no mention of heder files, no mention of how to get the samples compiled).
EDIT: ... because a) it's extremely outdated, and b) it doesn't even give you the basics.
This is not true. One example, void* pointers are not automatically converted to "narrower" types in C++ as they are in C.
enum toto { a = 1 }; enum toto b = 1;
Fixing versions of both standards could bring in more examples (like trailing comma in enums and use of the names reserved in C++, by the C code).
Overall, ironically, as typing is stronger in C++ (which I agree is a non-syntactic change), poor C code (using lots of unjustified casts), will require less modifications to be compiled as C++.
void f() {
int x;
scanf("%d", &x); // read from user
int numbers[x]; // dynamic
}
is legal C, but not C++.Also, the C "restrict" keyword doesn't exist in C++ either. Add in C's looser typing rules regarding conversions, and C and C++ are basically sibling languages at this point. Their common ancestor language being K&R-era C.
Fixing versions of both standards could bring in more examples (like trailing comma in enums and use of the names reserved in C++, by the C code).
Overall, ironically, as typing is stronger in C++ (which I agree is a non-syntactic change), poor C code (using lots of unjustified casts), will require less modifications to be compiled as C++.
There are differences, but they are few and far between.
Instance names should be lowercase, for God's sake.