Re: pointer vs non-pointer
worlman385@yahoo.com wrote:
So, if I want to return an object created in a function I better use
dynamic creation?
MyCar myfunction(){
MyCar mycar;
return mycar;
} // this is return by value
// this is more expensive as it copy whole value and return value
MyCar* myfunction(){
MyCar* mycar = new MyCar();
return mycar;
} // this is return by reference(pointer)
// less expensive as it only return 4 byte = pointer.
Firstly, a pointer's size is implementation-defined. I have seen sizes from
1 to 8 bytes. Secondly, dynamic allocation is extremely expensive, so it is
best avoided. However, try writing correct programs first and then try
making them fast if that is at all necessary. Not using dynamic allocation
surely helps writing correct programs.
Now, the question is what you actually _mean_ with your code. In particular,
is MyCar a value or an entity? If it is a value type, you might consider
calling it 'car_info' or something like that, in order to signal to the
reader that it's just some data that can be copied. OTOH, if it is a
certain car and maybe MyCar is just the baseclass and the derived class
defines its behaviour, then it is an entity and you typically can't copy
those anyway.
Also for a collection of object like a LinkedList object, since it's
very expensive to return by value, i must use return by
reference(pointer):
LinkedList* myfunction(){
LinkedList* list = new LinkedList();
return list;
} // this is return by reference(pointer)
// less expensive as it only return 4 byte = pointer.
// instead of return by value to copy all element in the List
No. If you find out that a significant amount of your program's time is
spent in copying a list around you can (after profiling) try to optimise
away unnecessary copying operations.
The first choice for that is typically to rather make the caller responsible
for allocating the object and then pass a reference to the object to the
function.
The second choice involves smart pointers. In the case that you are
returning a resource from a function and want to transfer ownership,
std::auto_ptr<> is the way to go. Make sure you carefully read its
documentation, because its semantics are actually a bit surprising at
first.
A third choice would be to use MOJO (search for "MOJO C++ Alexandrescu"). In
fact that should be the first choice (after extending the C++ language
itself with move semantics) but it's a bit intimidating to a newbie to C++.
In no case would I use raw pointers.
and if mycar is used by outside scope means:
void myfunction(){
MyCar* mycar = new MyCar();
// mycar is used by other function also after function returns
mycar->AddEventListener();
// even myfunction returns,
// but mycar still need to listen for events
}
In this case, you have no choice but to create a MyCar object that still
exists after this function exits, so you need dynamic allocation. Note
that in theory, objects of static duration (globals, function-static,
class-static) could work, too, but are not as flexible.
In that case, if I used static object allocation, will it crash my
program?
Note: the term 'static allocation' or 'static storage' is actually used for
objects that live the entire runtime of your program. What you mean
is 'automatic storage', i.e. lifetime bound to the scope of a function or
block. And yes, you must not touch such objects (e.g. via a pointer to
them) after they ceased existing.
Will something like null pointer exception happens?
No. If you compare C++ with e.g. Python or Java, Java checks for invalid
states and signals them (e.g. with mentioned exception). C++ instead puts
this burden on the user and simply says that this or that misuse "invokes
undefined behaviour". This is a burden, because you need to do it yourself
(see above three choices for how to avoid making mistakes doing so) but
also allows performance benefits. These are fundamental differences, but
I'd say that C++ is a sharper tool than Java, making it more dangerous to
use but also more powerful in the hands of a skilled artisan.
Dereferencing invalid or null pointers invokes undefined behaviour.
Uli
--
C++ FAQ: http://parashift.com/c++-faq-lite
Sator Laser GmbH
Gesch??ftsf??hrer: Michael W??hrmann, Amtsgericht Hamburg HR B62 932