C++: Another Spoiled Newbie
-
Interesting that we have a thread full of what seems as competent programmers, all with a good understanding of the problem, hell-bent on trying to find flaws with each other for no real reason.
-
@Mikademus said:
Interesting that we have a thread full of what seems as competent programmers, all with a good understanding of the problem, hell-bent on trying to find flaws with each other for no real reason.
There's good reason for it.
By the time you get enough experience to be "competent", you've usually built up a good bag of tricks that help you be more efficient and avoid common mistakes. The problem is these tricks (and their relative importance) tend to be different for each person.If we only ever worked on code we developed ourselves this wouldn't be a problem. But unfortunately we often have to work in teams, or even worse, maintain code we didn't write ourselves. Working on code that doesn't match your style is less efficient, if it wasn't you wouldn't code that way in the first place (note: assuming competence here, not cargo cult).
So to maintain maximum personal efficiency, you have to convince as many people as possible to code the same way you do. The more people you can convince that your way is right, the less code will be out there that doesn't match your style. You have to spread your stylistic seed. And just like evolution, there's no guarantee the best will when out, just the one that spreads the most. Intimidation, posturing, it's all fair in love & war.
Given that perspective, does the behavior you see here remind you of anything? :>)
Maybe I should just go to bed instead of posting this....
-
@Mikademus said:
Interesting that we have a thread full of what seems as competent programmers, all with a good understanding of the problem, hell-bent on trying to find flaws with each other for no real reason.
This is the C++ effect. Having to work with something so powerfull and yet uglier-than-hell like C++ turns the most brillant minds into grumpy old men.
-
@JvdL said:
@asuffield said:
You don't have what it takes to be a software developer.
@Mikademus said:You just seem like an ass with anger issues [...] Ass-u-field
@bstorer said:Your recent MO of posting smug invectives seems misguided at best.
@fist-poster said:You don't understand references [...] You've degenerated into less than a troll
This starts to look like a pissing contest.To Mikademus, bstorer, fist-poster:
Asuffield is right: references are not safer than pointers and are primarily syntactic sugar that sometimes (operator overloading) makes your code easier to read, but often merely obfuscates it. Compilers will only protect from blatant typos, if at all. If you don't believe him or me, read second opinions by Bjaerne Stroustrup or Dan Saks.Don't try to beat asuffield on his home ground: he knows more about this stuff than all of us put together.
To asuffield:
You'll stand a better chance that people will listen to you if you wouldn't start your rethoric with insults.From Stroustrup's page that was linked:
If passing ``not an object'' (e.g. a null pointer) is acceptable, using a pointer makes sense. My personal style is to use a pointer when I want to modify an object because in some contexts that makes it easier to spot that a modification is possible.
I've bolded the relevant portion. The implication is that in all other situations using a pointer does *not* make sense, or equivalently: If passing "not an object" (e.g. a null pointer) is *NOT* acceptable, using a reference makes sense.
That's because a reference *must* refer to an object. Yes you can go out of your way to make that object invalid, but there is little a programming language can do to prevent willful stupidity. So instead the focus is on preventing accidental errors, something which references do quite admirably.
-
@dsharp said:
So instead the focus is on preventing accidental errors, something which references do quite admirably.
They really don't. I've seen people screw up references probably more often than pointers - because at least with pointers, it's obvious that you have to pay attention. Nobody ever pays attention to whether references are valid.
If you want to prevent this kind of accidental error, use (sp)lint. That's what it's for.
-
Returning a reference to a local object in Java is perfectly valid and is done all the time. So I would expect to have to break that habit for people moving form Java to C++, other than that though I'd be surprised to see other programmers screw it up too often.
Maybe I'm too optimistic.
Personally, I prefer to only use const references. If I'm going to modify a value I'll pass it in as a pointer, that way it's obvious in the calling code without having to look up the declaration. Consider:
foo(bar);
vs.
foo(&bar);
the &bar is a tip-off that foo is modifying bar.
-
@dsharp said:
Returning a reference to a local object in Java is perfectly valid and is done all the time. So I would expect to have to break that habit for people moving form Java to C++, other than that though I'd be surprised to see other programmers screw it up too often.
Maybe I'm too optimistic.
May I present my new one-act play, Objects:[Enter C++ and Java]
C++: Objects exist in a certain time and place only.
Java: Objects exist so long as we keep thinking about them.
C++: That's absurd. If you try to think about an object too late, you die.
Java: It's only too late when you no longer name it.
C++: Filthy hippie.
Java: Fascist bastard.[Exeunt, End Scene]
-
@bstorer said:
@dsharp said:
Returning a reference to a local object in Java is perfectly valid and is done all the time. So I would expect to have to break that habit for people moving form Java to C++, other than that though I'd be surprised to see other programmers screw it up too often.
Maybe I'm too optimistic.
May I present my new one-act play, Objects:[Enter C++ and Java]
C++: Objects exist in a certain time and place only.
Java: Objects exist so long as we keep thinking about them.
C++: That's absurd. If you try to think about an object too late, you die.
Java: It's only too late when you no longer name it.
C++: Filthy hippie.
Java: Fascist bastard.[Exeunt, End Scene]
Why oh why do I want to respond with:
Voice from Offstage: "Objects exist or do not, independent of whether you think they do, and their nature doesn't change depending on what name (if any) you call them."
Hopefully, of course, when it comes to programming, you only use objects that exist, don't create objects you don't use, and don't think that objects disappear when you close your eyes.
(A good corollary to this general discussion is: "When two measurements/opinions differ on a matter, at most one of them can be correct. Usually neither of them are.")
-
@nefigah said:
What is an auto_ptr? I saw it in the C++ FAQ, but haven't seen it in most code examples on the web.
its what is called a "smart pointer." rather than having memory management being the responsibility of the developer (because we all know how many developers suck at it), its a way for the developer to fire and forget. you create an auto_ptr which contains a normal pointer to whatever object you specify, and once you leave scope its destructor automagically deletes the new'd data.
@nefigah said:
When do I use references as opposed to pointers for function parameters?
the most common reason you would pass something by reference is if you want the called function to modify what youre passing. of course you can do this with pointers, but the general rule of C++ is that you should use references when you can, pointers when you have to. another reason to pass by reference is so you dont encounter overhead in putting a copy of the object on the stack. again, can be done with a pointer, but i think references are cleaner in that you dont have to dereference and . looks a little nicer than ->.
keep in mind, im a C guy, i hate everything C++ does, and i think references are stupid, but this is just a common convention among C++ developers. when in rome...
@nefigah said:
Should every "new" get a "delete"? (if that makes sense)
short answer: yes. if youre using an auto_ptr and declaring it as such:
auto_ptr<Bar> foo(new Bar); //i think thats how you use it, i dont remember off hand.
then the delete is automatically taken care of when foo is destroyed.
-
@fist-poster said:
@asuffield said:
int &a(void) {
int b;
return b;
}int* a() {
int b;
return &b;
}I think once you have been told and understand why you shouldn't do this, that won't be a problem any more.
And if you've been told and still forget, no biggie as both of these examples produce easy to understand warnings from the compiler (I checked with gcc on linux and an MS one on 'doze), IMHO, being fastidious with compiler warnings is as important to program health as washing your hands after #2's is to your own health :)
To newbie, I've been doing C++ for 16yrs and you can 'carbon date' my source by looking at the ratio of * to &. The earliest code (during my transition from C) is full of new/delete/*, over time I started to get sick of writing if(ptr!=NULL) {...} and ancillary activities like coding big3 functions (Cline/Lomow) to correctly handle my misguided desire to explicitly manage memory... slowly & started to creep into my function signatures, from then on it was smart pointers (thanks Scott Meyers), stl, and boost. My latest code rarely has a new/delete/* and I virtually never have to think about memory management, heap corruption, pointer validity or any of that rubbish.... it just works and I can use my brain power solving the real problems.
-
@snowman said:
@fist-poster said:
@asuffield said:
int &a(void) {
int b;
return b;
}int* a() {
int b;
return &b;
}I think once you have been told and understand why you shouldn't do this, that won't be a problem any more.
And if you've been told and still forget, no biggie as both of these examples produce easy to understand warnings from the compiler (I checked with gcc on linux and an MS one on 'doze), IMHO, being fastidious with compiler warnings is as important to program health as washing your hands after #2's is to your own health :)
To newbie, I've been doing C++ for 16yrs and you can 'carbon date' my source by looking at the ratio of * to &. The earliest code (during my transition from C) is full of new/delete/, over time I started to get sick of writing if(ptr!=NULL) {...} and ancillary activities like coding big3 functions (Cline/Lomow) to correctly handle my misguided desire to explicitly manage memory... slowly & started to creep into my function signatures, from then on it was smart pointers (thanks Scott Meyers), stl, and boost. My latest code rarely has a new/delete/ and I virtually never have to think about memory management, heap corruption, pointer validity or any of that rubbish.... it just works and I can use my brain power solving the real problems.
I started to automaticaly add a typedef [boost::shared_ptr / auto_ptr / ... ]<MyClass> Ptr; into each MyClass, so I have no more * just MyClass::Ptr ...Simplified my life ...The only problem is the stooopid MS Intellisense, because I do not have autocomplete anymore ...
Does anyone know a solution to that one ? (its in VS 2003 I do not know whether they fixed it in 2005)
-
Instead of asking people, you'll learn more by reading a bunch of books. I recommend:
The C++ Programming Language, special edition by Bjarne Stroustrup (this should be your main reference tome on the core language)
Effective C++, More Effective C++ and Effective STL by Scott Meyers
Exceptional C++ by Herb Sutter
