Re: Object Management
On Aug 30, 5:42 am, Jerry Coffin <jcof...@taeus.com> wrote:
In article <1188413857.173394.309...@19g2000hsx.googlegroups.com>,
spekyu...@gmail.com says...
[ ... ]
This is lunacy. In reality, rather the opposite is true: a class should
contain at most one member that's a pointer, and when it does, the class
should be dedicated to managing that pointer. If it's not dedicated to
managing a pointer, a class shouldn't contain a pointer -- it should (at
most) contain instances of other classes that manage pointers on its
behalf.
Come now Jerry, you can't really mean this. Are you saying that
nodes in a red-black tree should only contain smart pointers (a
class dedicated to managing a pointer)? And what about pointers
used for navigation between entity objects? The object
containing the pointer must be informed about "lifetime" events
concerning the pointed to object, but encapsulating the pointer
into a separate class isn't necessarily (or even usually, in my
experience) the best solution.
I think the important points here are:
-- C++ supports value semantics quite well, thank you. We
don't have to (and usually shouldn't) play around with
pointers and references when we're dealing with values.
-- Pointers and references are language level tools, which can
be used to implement a number of high level concepts. Once
the design is done, and we know what we are trying to
achieve, we can choose which ever tool is most appropriate.
Raw pointers work very well for navigation, for example.
Your rule really applies mainly to cases where you are
allocating objects dynamically in the constructor. In such
cases, you definitly want some sort of wrapper for the pointers,
so that they will be correctly destructed if the constructor
fails (an exception) after construction of one or more of the
objects is completed.
Of course, quite a few things simply don't need to be pointers
at all -- directly, or managed by another class. Storing a
pointer where you really only need a char would be incredibly
foolish and wasteful.
I'd argue that the same thing holds for strings or other types
with value semantics: std::string const* are very, very rare in
my code. (Off hand, I think they only occur as return values,
when the function does some kind of look-up which may fail.)
[ ... ]
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 may be negligible, but appears to accomplish nothing -- using
overloading instead of a default argument makes no real difference in
the documentation required.
You may or may not want the default argument; there's nothing
wrong with requiring the user to specify explicitly that the
argument is not provided. More to the point, documenting two
different functions is more work than documenting just one.
More work for the person documenting, and more work for the
person having to read and understand the documentation. If the
semantics of the function really are different in the absense of
the argument, you need to document both semantics, the
difference is negligeable, and using the same function for two
different semantics is confusing. If the semantics are more or
less the same---say, the function uses a reasonable default when
the argument isn't provided---then it's much easier for the user
to get his head around one function than around two.
Either way you need to document the number and types of
parameters allowed and what is accomplished with different
numbers of parameters.
[...]
How should members and their operations be handled in a general sense,
while considering effeciency and portability top priority?
The first advice I'd give is to NOT consider efficiency (at least as
most people use the word) as a top priority. Efficiency is rarely as
valuable as readability.
Note that the real problem isn't the word "efficiency"; it's
what the word is applied to. Increasing programmer efficiency
should be a top consideration.
Using the same coding style regardless of what sort of object you're
dealing with will usually lead to problems in both efficiency _and_
readability though. Just for example, if you expect things to be small
and cheap to create and copy, you can far more reasonably deal with them
by value. If you expect them to be large and expensive to create and
copy, you often can't do that.
Actually, you can do it more often than you would think. It
only becomes a problem if the function is called very
frequently, or in a critical path or loop. If a function has a
single out argument, I will return it by value, regardless of
the type, until the profiler tells me I can't. (I've
successfully returned my pre-STL equivalent of an std::list with
60000 elements, using a compiler which didn't implement RVO, and
without "performance problems". The return statement, on the
machines of that epoch, took some seven seconds, but the
function was only called five or six times in an application
which otherwise required a couple of hours runtime.)
Of course, if it had been a question of a function argument,
rather than a return value, I would have used a const reference
rather than a value; it's pretty automatic to pass by const
reference whenever a container is involved---for most people,
it's pretty automatic as soon as a class type is involved
(although the STL uses pass by value a lot for class types:
iterators, predicates, etc.).
--
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