S
spekyuman
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. 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.
I recommend that all class members be saved as pointers. 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.
If an object is passed to a constructor or initialization method, the
user can expect the class to hang onto it. 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.
QUESTION: Should all class members be implemented as pointers? Why or
why not?
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. 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,
the be clear who has ownership of the object--its class, the
recipient, or a third-party.
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.
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.
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?
How should members and their operations be handled in a general sense,
while considering effeciency and portability top priority?
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. 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.
I recommend that all class members be saved as pointers. 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.
If an object is passed to a constructor or initialization method, the
user can expect the class to hang onto it. 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.
QUESTION: Should all class members be implemented as pointers? Why or
why not?
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. 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,
the be clear who has ownership of the object--its class, the
recipient, or a third-party.
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.
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.
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?
How should members and their operations be handled in a general sense,
while considering effeciency and portability top priority?