Good luck trying to understand C++ without C. The numerous C++ traps and pitfalls will just look mad to you.
BTW, 'multi-paradigm' is an oxymoron. Not even Scala uses that concept any more.
look at it this way: suppose some alternate universe where there is no such thing as C, it just doesn't exist, nobody ever heard of it. Why would you not be able to completely master C++ that universe? The traps and pitfalls which you consider C, would then just be known as C++ (just as in reality they are C++ now, maybe not just always named as such). I think that's one thing what's being advocated here.
Anyway, what traps do you have in mind specifically?
This. Moreover, much of the complexity of the language is caused by being designed as a super-set of C. C++, literally, makes no sense without C.
Go does a good job of rectifying this: strings are generally opaque binary objects--indexing into them gives you abstract "runes" (representing Unicode code points) which can then be encoded into various flavors of UTF characters.
Overselling Go a bit there. Indexing into a string gives you that byte: http://play.golang.org/p/rxeexRzW7e
There are ways of iterating along a string by "rune" but it's not the default. That said, given that strings in Go are assumed to be UTF-8, indexing into them by rune is expensive and if you actually want to iterate by Unicode char I'm not bothered by having to be a bit more explicit about it.
"Rune" is an alias for int32. So we are saying the same thing, essentially.
I'm not sure what your point is in this argument? You're saying the above is worse than braindead C ASCII-only strings?
It's best to be correct about how languages work, because when you interest someone in a language via a false statement, they do not end up thinking highly of either you or the language when they discover the falsity. While I'm not sure I'd call myself a Go "advocate", I do prefer that people like and/or dislike it for valid reasons rather than invalid ones.
But if we accept the hypothetical, I think that people in that universe would still identify and separately consider the C-ish subset of C++, much like template metaprogramming is considered its own subset of the language.
So no, I don't think they would understand C++ without first understanding C, even if they didn't call it "C" or consider it to be a completely separate entity.
When some people say that when you are learning C++ you should not be exposed to C, I really have to disagree.
False.
What's a paradigm? It's a way of viewing things. What ways are there of viewing programming? Well, there's functional, there's structured, there's object-oriented, there's generic, and maybe some more.
Can C++ be used to write non-object-oriented, non-functional, purely structured-programming-style procedural code? Yes, it can. (Essentially, that's the subset that's in common between C and C++.) Can it be used to write object-oriented code? Certainly. Can it be used to write functional code? Again, yes (though not nearly as purely as the Haskell zealots would like - but C++ doesn't enforce the purity the way Haskell does precisely because C++ is multi-paradigm). Can C++ be used to write generic code? Yes. (I have heard that the STL was written in C++ because, at the time, it was the only widely used language that would do what Stepanov wanted to be able to do.)
Four different paradigms. You can write C++ code using any of them, or you can mix and match. That's multi-paradigm.
Or are you arguing that, if you have more than one paradigm, you don't have any? That might be true of a program, though I think that the argument is merely a matter of definition, and therefore not very interesting. But if the language makes it easy to write in several paradigms, it seems perfectly appropriate to call it multi-paradigm.
You need a basic understanding of C.But C and C++ are different languages,period.
Genuine question.
Printf and the cstdlib - eh yeah I'll hand you that, if someone had no concept at all that a language called C existed prior to C++ this would be confusing without explaining it to them. But a newbie should not be looking at C++ code that uses the cstdlib or printf anyway, they should be looking at streams and true C++ code to begin with.
If you type in hello world to the internet, you are going to be getting C and C++ versions and you are going to find out that both work. You can't hide the truth from beginners for any length of time. Imagine telling someone that they can't look stuff up on the internet in case they get exposed to "the wrong stuff"?
check out google on streams:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.h...
And so far as google and streams, well that's their opinion and fits into their particular style. There's plenty of dev houses that would tell you to avoid C style string manipulation due to the dangers of stack overflows etc.
Anyway I'm not wanting to fall into a C vs C++ argument, I'm merely pointing out that it's very possible for someone to pick up C++ without having the slightest bit of knowledge of C to begin with. I sure didn't know any C to start with.
you even knew when you started that you had to append C++!
Support for a legacy language full of security holes.
why do we have structs and classes? all this stuff in the first week.
You don't need to learn C, just read "The Design and Evolution of C++".
Back when a I was teaching assistance in the late 90's, we never talked about C in our C++ classes, besides the initial history introduction.
The fact that the C++ language contains a (almost) C compatible subset doesn't require students to be aware of it. It is all ANSI C++.
i have been taught extremely poorly and am many years your junior. K&R/stan lipmann's "inside the C++ object model" was a huge "oh ok, I've been basically lied to the entire time"
To be able to reuse existing C code in a C++ compiler, while allowing them to participate in class hierarchies.
This is the real reason, but you don't need to explain it like that to new C++ devs.
Use struts when you just need a data container. Use classes when you need to add behaviour.
Simple rule, no need to talk anything about C.
> What exactly do you need to know about C, that is not part of C++, to understand C++?
why can't you memcpy classes but you can structs? it's a confederation of languages, i think coldtea's idea of representing it as a superset is excellent, you cannot understand C++ by taking out its C subset.
if that's your attitude where it's not the real reason, but you think your explanation is sufficient:
your withholding information is limiting my education and as a student i would hate that. your explanation isn't an explanation, it's an order/instruction without explanation, C++ is full of this. you only get to "why" with C.
Since when?! Try this on a struct and it will go boom!
The only difference between structs and classes is the default access specifier.
> C++ is full of this. you only get to "why" with C.
No, you get the why by knowing Assembly and how computers work.
Any system programming language since FORTRAN exposes the same set of issues.
We never teached C at our university (during the 90's), first year students had Pascal followed by straight C++.
If they ever need to use C, it was based on what they learned from C++. There were no C lectures, nor teaching what is C or C++.
I never saw anyone speaking about learning BCPL to use K&R C, or having to learn Pascal to use Ada or Modula-2.
memcpy(s1, s2, sizeof(struct_type)); // wat is the problem :?
> There were no C lectures, nor teaching what is C or C++.
> Back when a I was teaching assistance in the late 90's, we never talked about C in our C++ classes
What exactly do you mean by the first statement? You mean you never taught people the difference?
You can't properly explain the existence of the struct data type without C, this is nothing to do with FORTRAN.
> I never saw anyone speaking about learning BCPL to use K&R C, or having to learn Pascal to use Ada or Modula-2.
that is not the argument I am making. the argument people are making is that you can learn C++ without learning C. they seem to be forgetting that in the process of understanding C++, you have to learn C. if you do not understand C, you cannot understand C++.
to transplant your argument, if you take out all the keywords from BCPL that are shared with C and try to learn C without using them, you aren't going to get anywhere.
This only works if struct_type is a POD.
Meaning no member functions, no virtual functions and no inheritance.
> What exactly do you mean by the first statement? You mean you never taught people the difference?
No, why should I, it is all C++.
It might be called struct, but only the keyword is the same, the semantics are quite different.
So why bother students heads with needless details how a C compiler sees a struct and a C++ sees a struct?
A struct is a class with default public access, that is all.
> You can't properly explain the existence of the struct data type without C, this is nothing to do with FORTRAN.
Why? It is a C++ data type. Why should I use another programming language to explain it?
> If you do not understand C, you cannot understand C++.
I wonder how my students could manage their exams.
You have to learn C++ relation to computer hardware and the design decisions behind it.
This means computer architecture and Assembly, C is not required.
Sure one can explain that some decisions are related to the desire to have C++ interoperate with zero attrition in the C Eco-system, but that isn't required to explain C++ language features.
Do you also want people to learn C before C# and D?
Keywords and programming concepts are common across programming languages.
it's like having a debate with the iraqi information minister, you don't even believe yourself what you are saying.
C# and D are sufficiently different, D and C# will not compile most/any C programs.
as soon as any of your students got in to a professional context and have to use C++ in anger, they found out pretty quickly that they actually didn't understand it. you did them a disservice by ignoring C.
the design decisions in C++ are reactions to C - not computer hardware, architecture or assembly. there are a few exceptions to this, but they are small in number.
the "why" is staring you in the face and you are willingly ignoring it. it's actually infuriating to try and learn from someone with this attitude, never explaining why correctly but giving directions with no explanation or falsified explanation.
A struct is a C++ data type that offers the same set of features as a class, just with a public access as default.
The use cases for a struct are POD (Plain Old Data) used to aggregate variables that refer to a common data structure, hence struct as abbreviation.
> C# and D are sufficiently different, D and C# will not compile most/any C programs.
But they also have struct. So you don't need to explain struct to those developers?
You can also do memcopy and pointer manipulations in C# and D.
Why shouldn't then they also learn about C?
Regarding the C subset in C++, it is actually C89 with a few semantic changes.
There quite a few examples of C89 compliant code that won't compile with a C++ compiler or will have strange behaviors.
The way struct namespaces work is such example.
> A struct is a C++ data type that offers the same set of features as a class, just with a public access as default.
these are lies. at this point it's a semantic argument, what you mean by "understand" is "use". what i mean by understand is its dictionary meaning.
to answer your questions, no you don't need to explain them or teach C to them because the syntax for struct in those languages is not identical to C. that is why. because they are not C structs. "C++ structs" are C structs with some syntatic sugar applied. C structs will not compile in those languages. C structs are not valid code in those languages.
I am aware of the long list of minor incompatibilities between C89 and C++, and how C++11 has removed some and added more
In short you know nothing about this I don't already know and you are quite happy to knowingly deceive your students. i object but there's no point in debating with you further.
Out function parameters are implicit pointers via references. Cannot be null.
Pointers and arrays aren't compatible.
Pointer arithmetic is frown upon and in many of those languages requires an explicit unsafe block/system module import.
How it allows for all the C pointer features, while adding a little bit more safety.
MODULE examples;
IMPORT Terminal, SYSTEM;
(* procedure with reference parameter, no need for pointers *)
PROCEDURE ChangeParam (VAR changeMe: CARDINAL);
BEGIN
changeMe := 25;
END ChangeParam;
(*
procedure with a slice, bounds given by HIGH(changeMe) and LOW(changeMe).
also a string in this case
no need for explicit pointers
*)
PROCEDURE DumpLetters (VAR letters: ARRAY OF CHAR);
VAR
i : CARDINAL;
BEGIN
FOR i := 0 TO HIGH(letters) DO
WriteChar(letters[i]);
WriteLn;
(* Or just use *)
WriteString (letters);
END DumpLetters;
VAR
anInt : CARDINAL := 12 ;
aPtr : POINTER TO CHAR;
aBuffer : ARRAY [1..2] OF CHAR;
anAddr : ADDRESS; (* think void* *)
aPtr2 : POINTER TO CHAR;
BEGIN
WriteInt(anInt); (* writes 12 *)
ChangeParam (anInt);
WriteInt(anInt); (* writes 25 *)
DumpLetters ('A simple string');
NEW(aPtr); (* The compiler knows the size, no need for sizeof, but you can use ALLOCATE(aPTR, SIZE(CHAR)) if you want *)
(* This is where it shares the same problems with C, due to manual memory control *)
DISPOSE(aPtr);
(* do pointer arithmetic if really required *)
anAddr := SYSTEM.ADDADR (SYSTEM.ADR(aBuffer), SIZE(CHAR) * 1);
aPtr2 := SYSTEM.CAST(POINTER TO CHAR, anAddr); (* aPtr2 now points to aBuffer(2) *)
END examples;
All Modula-2 successors, have GC support, as such the DISPOSE() would have to be written as SYSTEM.DISPOSE() and could only be applied to untraced pointers.
http://stackoverflow.com/questions/6456253/why-is-reference-...
it's a great shame it's defined in such an alien to use way in C++.
Of course this isn't an argument, but this shows that even though C++ doesn't prevent you from falling into the same trap that are present in C, it does give you the tool to at least allow you to do better than C to avoid these traps, notably thanks to RAII.
Oh and let's not forget nullptr, which is a blessing compared to NULL.
Pointers are still a feature of both languages.
Pointers in C++ are basically the same than in C, just with mechanisms that solve the ownership and some safety problems.
So yes, it allows the same holes, but at least you have tools to avoid falling in them.
RAII -> Why? nullptr vs. NULL -> Why? Pointers -> Why? Don't use them in a certain way -> Why?
The answer in all cases is C.
There are endless languages that have pointers, no need to talk anything about C.
Starting to sound like a broken record. No, the answer in all cases can also be found in C++, and understood in C++ terms alone. C++ is a SUPERSET of C, not just an arbitrary language + C.
i will now abstain from further conversation - i will leave you with this - i don't care to read your answer in case i have to respond and you might have to deal with some more repetition:
using the language of sets, the set of C++ minus the set of C, with what is now left:
how can you explain the things i have listed?
As evolution within the same language. Inconsistent ideas ironed out for more uniform and safer handling.
A lot of used languages have similar historical warts...
How do you explain "var" in JS, when "let" exists?
Because references can't be NULL in C++, and you can't reseat a reference in C++.
> why does printf exist?
Personally, I think the more interesting question is "why isn't printf extensible?" And, with variable length template functions, it should now be extensible. If it were converted to a template.
> what is everything in the cstdlib?
I can't speak for all beginners, but I can say that when I was a beginner, the concept of language (and library) evolution was never hard for me to grasp. Even in a world where C never existed, I think I could have understood that some the library had old ways to do things, and new ways to do the same thing.
In fact, I can't think of any language that's been around for more than, say, ten years without a little cruft and duplication in the standard library.
If it were the case that the new ways were actually superior in all cases, then that point would stand, but in many they are not.
It's a confederation of languages and pretending it isn't hinders people and their understanding.