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.
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.
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.
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?
There are endless languages that have pointers, no need to talk anything about C.
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++.
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.