And just a thought by me too: when it comes to classes, it's more efficient for functions to take pointers to them and create the objects on the heap to avoid hugging valueble stack space and to avoid all copying of objects forth and back, wasting precious resources and cpu time.
Last edited by laserlight; 10-24-2007 at 01:16 PM. Reason: First line from earlier discussion.
In C++, this is not the only option: one could use pass by (const) reference instead of passing pointers.And just a thought by me too: when it comes to classes, it's more efficient for functions to take pointers to them and create the objects on the heap to avoid hugging valueble stack space and to avoid all copying of objects forth and back, wasting precious resources and cpu time.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
But the thing is that the classes would need to be created on the heap, and then there's no real point in passing by reference. If the functions would take references only, the objects would go out of scope.
If you have a pointer, why not just pass it along? Or am I missing something here?
>> it's more efficient for functions to take pointers to them and create the objects on the heap to
>> avoid hugging valueble stack space and to avoid all copying of objects forth and back, wasting
>> precious resources and cpu time.
I disagree. Creating variables on the heap can be more expensive for small objects, it almost always leads to more bugs in your code (which is "expensive" itself) and in most cases you wouldn't notice a difference anyway. Use stack based objects unless you have a specific reason not to. In this case, one reason not to would be to keep objects around longer than the lifetime of the scope that created them, but as shown that isn't necessary and the alternative is perfectly appropriate.
>> Or am I missing something here?
Are you talking about a specific example in this thread? Which class and which example? (Actually, it's a bit off topic so a separate thread might be appropriate).
In general you should prefer local automatic objects over dynamically allocated ones. If you see a specific case where that general rule doesn't apply can you point it out.
Ah, but the issues are separate: avoiding copying is not a valid reason to use dynamic memory allocation.But the thing is that the classes would need to be created on the heap, and then there's no real point in passing by reference. If the functions would take references only, the objects would go out of scope.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
I find it better and more efficient to make a function that takes a pointer, like the register:
And creating a new Car object and passing it along:Code:void Register::RegisterCar(Car* pCar)
It doesn't hug stack space, it doesn't do a lot of copying and I'm sure there are other benefits as well.Code:Register.RegisterCar( new Car(...) );
The register could simply be responsible for cleaning up all the cars when it destructs.
And it looks more object-oriented to me, as well, though that could just be me.
Yuck! That's a memory leak waiting to happen. (Depending on what RegisterCar does, of course.)
And it's just you. Heap and stack have absolutely nothing to do with object-orientedness.
Using new is a matter of size (you typically have about 1M of stack space, but 1G of heap), lifetime (if the object must survive past the end of the function) and binding (if you decide at runtime which kind of object you create).
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
That it is not. The register creates records and should be responsible for cleaning them up as well. This is a usual approach I typically always use and which almost never results in memory leaks (usually they come from some screw-up elsewhere :P). You can also use a memory manager or smart pointer.
Of course, this approach can also be used to avoid bugs with the duplication of objects and if you usally do not want your object to be duplicated.
Anyway, carry on.
And how do I, as a maintenance programmer, know that? How do I know, from looking at the code, that RegisterCar takes responsibility for the pointer?
Pointers are awful low-level constructs. They're good for implementing high-level constructs, and should be avoided everywhere else.
If the function does not take responsibility for the object, make the argument a reference. If it takes responsibility for the object and wants to take the object away from you, make the argument an auto_ptr. If it wants to keep the object indefinitely, make it a shared_ptr. If it wants to keep a reference to the object indefinitely without taking responsibility, make it a weak_ptr.
Under no circumstances make it a raw pointer.
References are useless things in modern C++, they're almost of no use.
References are not the right tool for the use case at hand, but that doesn't mmake them useless. The idea that references are useless in modern C++ will get you laughed at by practitioners of modern C++.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
One should always take implemtation into mind. Decide who takes responsibility for the pointers.
But there are no good alternatives to pointers. References are near uselss. auto_ptr, etc, are you pointer handling classes to my knowledge.Pointers are awful low-level constructs. They're good for implementing high-level constructs, and should be avoided everywhere else.
That makes absolutely no sense to me at all. Wrap all memory pointers in memory handling classes such as auto_ptr and be done with it. I don't really have much insight into auto_ptr, shared_ptr and weak_ptr, but again, I tend to handle everything myself. Any class that gets rids of memory when no longer in use is okay by me.If the function does not take responsibility for the object, make the argument a reference. If it takes responsibility for the object and wants to take the object away from you, make the argument an auto_ptr. If it wants to keep the object indefinitely, make it a shared_ptr. If it wants to keep a reference to the object indefinitely without taking responsibility, make it a weak_ptr.
Under no circumstances make it a raw pointer.
Near useless. They're incredibly static, not dynamic. Must be initialized, and that is almost THE biggest flaw of them. I only use references when a function works with local variables and does not intend to store them in any way (and assuming it's not a thread, and the arguments are not pointers to begin with).
References are not the right tool for the use case at hand, but that doesn't mmake them useless. The idea that references are useless in modern C++ will get you laughed at by practitioners of modern C++.
Anyway, I take effciency before pass by value any day.
Then, with all due respect for your programming experience, you have no business talking about "modern C++".
Still nonsense. I typically use 10 times as many references as pointers, and that includes smart pointers. References are the method of passing objects around to functions that do not intend to keep them. And since you want object lifetimes to be as predictable as possible, you'll see to it that most functions have no intention of keeping their argument objects.Near useless.
They refer to the object they've been initialized with. That's a good thing. It makes them predictable. Reassigning pointers to different objects is a wonderful way of losing track of what the pointer points to.They're incredibly static, not dynamic.
They make rather poor class members, but that is their only flaw.Must be initialized, and that is almost THE biggest flaw of them.
That should be your primary use case. That should be an extremely frequent use case.I only use references when a function works with local variables and does not intend to store them in any way.
Who's talking about pass-by-value?Anyway, I take effciency before pass by value any day.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
What a crock. I've written several programs larger than 10,000 lines without ever using a pointer except in "char **argv."
Pointer-free code is both easier to understand and often more efficient. You just can't seem to imagine how it looks.Anyway, I take effciency before pass by value any day.
1M default, you can bump it in the project settings, and 2GB heap, bumpable to 3GB or 16 million TB if you go 64 bit. As for the rest fo the discussion, while it may make some exceedingly rare problems easier to solve, forcing the use of non-raw pointers presents serious performance isues as well as permanently removing functionality from teh language. One of the core concepts of C/C++ is 'assume the programmer knows what they are trying to accomplish'. If this isnt the case, then the programmer needs to rethink the problem. Trying to add too much functionality to the language will end up robbing it of its best assets, that is speed and versatility. Should we take out re-casting because some goof might forget the original type of the pointer and try to access a member variable of the wrong structure or class? Perhaps we shoudl take out run time memory allocation all together since someone might write sloppy code that causes a protection fault? At some point, you have to just trust that the people writing the code will know wtf they are doing. If you cant trust this, then perhaps you need to write teh code yourself, or just go back to using an abacus.
Yes its would be nice if the compiler did all your thinking for you, but honestly, if you cant keep track of which member variables are pointing to what types and coordiante their proper construction and destruction, then you need to find some simpler approach.
Last edited by abachler; 10-24-2007 at 03:06 PM.
By using pointers & C functions everywhere instead of references & STL, you've effectively become a C+ programmer. Unfortunately my company is filled with C+ programmers, which makes my job a nightmare when I have to figure out what the code is doing and try to fix it.
I'd highly recommend reading these 2 books:
"C++ Coding Standards" by Herb Sutter & Andrei Alexandrescu
and "Effective STL" by Scott Meyers.
If they can't convince you to add another + to your C+ style, then I don't know what will.
