Re: Object Management
On Aug 29, 8:57 pm, spekyuman <spekyu...@gmail.com> wrote:
I found a public paper online stating, "The first time I returned to
writing C++ after a year of writing Java, I was appalled at how much
my design was constrained by managing the lifetime of objects. When C+
+ classes share objects, then they must negotiate who owns the object.
Garbage collection is not available, and smart pointers often fall
short." This is how the fellow introduced himself.
In sum, he starts by proving his imcompetence. For two reasons:
The first, of course, is that garbage collection is available
for C++, and is used in many C++ projects. The second is that
while garbage collection does relieve the programmer of a lot of
grunt work in managing memory, it doesn't do anything for the
lifetime of objects; managing the lifetime of objects is just as
important in Java as it is in C++. (Object lifetime, in fact,
is a design issue, independant of the language.)
He is correct in that smart pointers are a very poor garbage
collector.
He goes on to make
some design decisions for object management:
[No pointers as arguments.]
Pass all objects to class methods and constructors as references.
There is absolutely no advantage to passing objects as pointers. This
rule is euqally valid whether the objects are const or not.
One common coding guideline is to use pointers when you need a
"maybe" value (a null pointer), references otherwise. It's not
a universal coding guideline, however. I've seen at least three
different guidelines (all reasonable) concerning how to choose
between pointers and references: use references unless you need
a null value, use references unless there is a transfer of
ownership (e.g. delete), and use pointers anytime the lifetime
of the object must extend beyond the function call, or is
modified by the function call. I've also seen the guideline to
use pointers anytime the object might be modified, but there
seems to be a consensus that this isn't a good recommendation.
My recommendation is to choose one of the three rules, and use
it consistently. Except in cases where historical conventions
say otherwise: conventionally, streambuf is almost always passed
as a pointer, even in cases where it should be a reference
according to any of the above rules.
I recommend that all class members be saved as pointers.
Saved, in what sense?
You can easily take the address of an argument reference with
an ampersand and assign it to your member pointer. Some C++
programmers do not seem to realize that the address of a
references is the same as the address of the original object.
So they pass pointers when they want to save the argument, and
references when they do not. This is a poor form of
documentation, based on misunderstanding.
It's a question of convention, see above.
In general, I find that object members should usually be values.
Also, that value type objects shouldn't contain references, only
pointers (because otherwise, you have problems with operator=).
Finally, when an object contains a pointer, it is either the
owner of the pointed to object (i.e. it does both the new and
the delete), or the pointer is for navigation, in which case, it
usually can be null (which excludes passing a reference, even to
initialize it).
If an object is passed to a constructor or initialization method, the
user can expect the class to hang onto it.
Why? The usual C++ idiom is to copy.
If a method saves an object from an argument, choose an
appropriate name like setColor(Color&) or
addInterpolator(Interpolator&).
The worst excuse for using a pointer as an argument is that you want
to give it a default value of null. You still have to document what a
null object is supposed to mean. Worse, the user may overlook that the
argument exists or is optional. Declare a separate method that lacks
the extra argument. The effort is negligible.
The effort is small. But the gain is zero; in some cases, I
would even say it is a loss.
QUESTION: Should all class members be implemented as pointers? Why or
why not?
Certainly not. Class members of value types should be values.
QUESTION: Should all parameters be implemented as references? Why or
why not?
[Returning objects.]
One can always return objects from class methods by reference,
either const or non-const.
Only if the class actually contains the object, and even then,
you end up with a dependency on the lifetime of the containing
object. Most of the type, member functions should return
values.
A user can take the address of the reference, if necessary, to
save the object. But there are no drawbacks to returning
objects always as pointers. Consistency is preferable, and
most API return pointers.
If you return an object allocated on the heap with the new operator,
then be clear who has ownership of the object--its class, the
recipient, or a third-party.
One classical convention for "being clear" about this is to
return an std::auto_ptr if the function is renouncing ownership.
Think about whether you are breaking encapsulation of member
data in a way that will prevent modification later.
Never return a reference to a class member allocated on the stack in
the header file. If your class replaces the value, then the user may
be left with an invalid reference, even though your object still
exists. Your class will never be able to remove the object as a
member. A user may manipulate the logic of your class in unexpected
ways.
I don't understand the above. How do "header files" come into
this?
A method should modify an object constructed by the user by
accepting it as a non-const reference. Returning the same
object would be redundant and confusing.
In general, arguments fall into three types:
in: Prefer pass by value in C++. For optimization reasons,
it may be preferrable to use pass by const reference,
and there is one case (the copy constructor) where it is
required, and another (the assignment operator) where it
is conventional.
inout: Non-const reference in C++.
out: Prefer a return value. If there is more than one out
parameter, however, all but one must be non-const
references, and if the object is expensive to copy,
optimization considerations may require using a
non-const reference. Note, however, that regardless of
the design intent, a non-const reference is an inout
parameter---there is no way in C++ to pass a non-const
reference to uninitialized memory, where the function
will construct a new value.
In general, if the function is declared to take a value or a
const reference, you know that it is an in argument; if it is
declared to take a non-const reference, you should suppose
inout, and the function should document the significance of the
in value. (If the parameter is conceptually an out argument,
then the function should document that the in value is
irrelevant.)
In general, the return type should be a value, unless it
explicitly must designate an existing object. Optimization
considerations may occasionally lead to returning a const
reference instead of a value, but this can only be done if there
is an existing instance of the object outside of the function;
threading may restrict even this. If the return value is
guaranteed, then it should be a value or a reference; if it is
not guaranteed, then it should be a Fallible or a pointer.
QUESTION: "One can always return objects from class methods by
reference, either const or non-const. A user can take the address of
the reference, if necessary, to save the object. There are no
drawbacks to returning objects always as pointers." (Referring to the
statement that all objects should be implemented with pointer
members.) Are there any drawbacks when this is the case?
The first sentence above is false. You can only return an
object that exists elsewhere by reference. You cannot return a
synthesized value by reference, ever. You can also get into
trouble returning references in a multithreaded environment.
How should members and their operations be handled in a
general sense, while considering effeciency and portability
top priority?
By value.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34