Class member: pointer or variable?
-
[quote author="peppe" date="1317650577"]
What has that snippet do to with Java? We're talking about having objects vs. pointers to objects as members, a concept that Java hasn't (all "objects" are actually pointers to them in Java).
[/quote]Poster says he's a Java programmer. Was trying to frame the concept in a manner that would be familiar to him.
[quote author="peppe" date="1317650577"]
NO! NO! NO! NO!
[/quote]A misunderstanding on my part, I'll concede that, thanks. Haven't touched Java in years.
[quote author="peppe" date="1317650577"]
This is just PLAIN, TOTALLY AND UTTERLY WRONG.
[/quote]Your example is silly and shows that you've not only misunderstood what I've said, but seem to misunderstand what constitutes valid, working C++. You've created a reference to variable which immediately goes out of scope, creating an invalid reference. You've violated an axiom of valid C++, that references should be valid.
[quote author="peppe" date="1317650577"]
So first you say that references are always valid, then you say they may be invalid?
[/quote]In terms of correct code, if you have a null reference, you have a bug. So yes, references are always valid in correct C++. If you like writing software riddled with segmentation faults, be my guest, just don't peddle it as anything but garbage. Just because something compiles, doesn't mean it will run (Do I really need to tell you this?), it's no mean feat to write garbage code that will compile and fault when run.
[quote author="peppe" date="1317650577"]
Abused in like the hundred of QObject subclasses in Qt (all of them have an optional QObject *parent argument in the ctor, defaulting to NULL)?
[/quote]Abused in that there are a multitude of ways to provide optional arguments in C++, and often developers fall back on pointer arguments and monolithic functions as a familiar tool. Congratulations on picking out a single instance where I'd personally consider the usage well chosen, how about you go and have a look at some of the badly evolved C89 libraries, and tell me how great they are to work with?
[quote author="peppe" date="1317650577"]
Qt has allowed people to write good C++ for ages, without requiring anyone to master templates.
[/quote]I didn't say master templates, did I? I said understand templates. Given that the standard library is built around the principle of reusable code and templates embody this principle, I think it would be reasonable to say that people should understand templates.
The statement that good, modern C++ doesn't require an advanced understanding of templates is absolutely ridiculous, and out of step with the direction of the language of the last 2 decades. Boost, the standard library and Qt all use templates, and at some point, someone had to master them.
When all you have is a hammer, everything looks like a nail. Good luck building a house buddy.
Oh, and as for your opinion (or rather, that of Mr Cline), if you'd looked beyond your nose, you would have seen this:
@// What does it mean that a reference must refer to an object, not a dereferenced NULL pointer?
// It means this is illegal:T* p = NULL;
T& r = p; ← illegal
T p = NULL;
T& r = *p; ← illegal@[quote author="Volker" date="1317683047"]I want a thumbs down button. NOW. (oh, surely not because of peppes answer...)[/quote]
Directed at me?
-
[quote]You’ve created a reference to variable which immediately goes out of scope, creating an invalid reference.[/quote]
I know. I did it on purpose. Just to show that references give no additional guarantees in that sense, compared to pointers (both can be "invalid"/"dangling"). Another example:
@
int main() {
int *a = new int(42);
int &r = *a;
delete a;
// oops! r is invalid now
}
@That's because you said:
[quote]The primary difference between a reference and a pointer is a reference gives certain guarantees, namely that it corresponds to something, that that something is valid, and that it will be valid for the lifetime of that reference. An invalid reference is bad, most compilers will happily compile that (with a warning or two) and your application will behave badly.[/quote]Which, again: makes no sense. You can't say that references give the guarantee that it refers to something "valid" throughout its entire lifetime, because it's false. In fact you then say that invalid references can exist. So that's not what references do actually guarantee.
The primary differences between a reference and a pointer are:
references can't be reseated
references don't have "special" values (NULL)
That's all.
[quote]In terms of correct code, if you have a null reference, you have a bug. So yes, references are always valid in correct C++. If you like writing software riddled with segmentation faults, be my guest, just don’t peddle it as anything but garbage. Just because something compiles, doesn’t mean it will run (Do I really need to tell you this?), it’s no mean feat to write garbage code that will compile and fault when run.[/quote]
Of course. I was referring to your statement above. Obviously that's a bug (exactly like a dangling pointer, although I should check the standard to find out if the only fact of having invalid references leads to UB).
[quote]how about you go and have a look at some of the badly evolved C89 libraries, and tell me how great they are to work with?[/quote]
Oh, doing Xlib programming is absolutely great :-D
[quote]
Oh, and as for your opinion (or rather, that of Mr Cline), if you’d looked beyond your nose, you would have seen this:@
// What does it mean that a reference must refer to an object, not a dereferenced NULL pointer?
// It means this is illegal:T* p = NULL;
T& r = p; ← illegal
T p = NULL;
T& r = *p; ← illegal
@
[/quote]The problem with that snippet, in my humble opinion, has little to do with references -- you're dereferencing the NULL pointer, and that's undefined behaviour in C/C++ (even before thinking of initializing a reference to whatever *p returns).
[quote]The statement that good, modern C++ doesn’t require an advanced understanding of templates is absolutely ridiculous, and out of step with the direction of the language of the last 2 decades. Boost, the standard library and Qt all use templates, and at some point, someone had to master them.[/quote]
I totally agree; but luckily people managed to write very solid code by using Qt and avoiding to mess up with highly templated (and possibly unreadable) code. I don't consider using QList<Foo> "understanding" templates in any way (which is unfortunate -- knowing what you're doing is always a good thing).
So, can we consider this argument settled down? :)