Re: references and pointers
On Nov 9, 10:04 am, Kira Yamato <kira...@earthlink.net> wrote:
On 2007-11-09 03:42:42 -0500, James Kanze <james.ka...@gmail.com> said:
On Nov 4, 8:08 am, Kira Yamato <kira...@earthlink.net> wrote:
[...]
I'm still a newbie in C++, but I'm getting the sense that
proper use of STL should eliminate all needs of pointers.
Where did you get this idea from? Iterators can only be used
for objects in a sequence---in practice, in a container. Most
objects aren't in a container; entity objects never are, since
they aren't copiable, and it's rare to need a pointer for
anything but an entity object.
What is this "entity object" you speak of?
They're the category of objects which represent entities in your
application. More precisely, they will normally have identity,
and sometimes be polymorphic.
Why can't you use references to "point" to them instead?
You can't reseat references. You can't put references into
containers. If you require pointer semantics, references won't
do it.
However, for efficiency purposes, perhaps pointers should
sometimes be employed, just like 'goto' is theoretically not
needed but may be practically needed.
'goto' is never needed, even practically.
I'm been told (from friends in the computer department) that
"the use of goto in Linux kernel code is well thought out and
justified." Linus himself cited that use of it can make the
code easier to read than with nested if statements.
I wouldn't take Linux as an example of good, well written
software.
Pointers are almost always needed, even theoretically.
Well, I'm not saying the concept of pointer is unneeded.
Certainly, references is a type of "pointer" to refer to an
object. I was referring to the idea that the STL and C++
reference type & together should provide sufficient need in
place of C++ pointer type *.
But they don't. They don't even come close. Both STL iterators
and C++ references handle special cases. Neither are designed
for more general use.
(I say almost, because I believe that there are applications
which don't have any "entity" objects.
What is this entity object again?
See above. Or just Google it. (But be aware that many of the
hits you'll get with Google refer to entity objects in a
specific context. Thus, for example, one says "Entity objects
are classes that encapsulate the business model, including
rules, data, relationships, and persistence behavior, for items
that are used in your business application." Which is fine as
far as it goes, but I've used entity objects in technical, real
time applications, and I've used entity objects which weren't
persistent.
The key factor, I think, is identity: even if two entity objects
have the same value, they are different objects. In this case,
another important point is that entity objects typically have
relationships between them: one entity object object knows about
other entity objects. In many cases, authors will consider only
entity objects as objects, and not consider things like double
an object. (I prefer to think of everything as an object, even
if not in an OO way.)
While there are a number of ways you can categorize objects, and
a number of different categories, I think it safe to say that
most objects are either entity objects or value object (values);
the other categories are a lot less frequent. The difference is
that what is important with a value object is the value---which
instance you use doesn't matter. So you copy and assign them,
put them into containers, etc., and rarely if ever allocate them
dynamically or take their address. What is important with
entity objects is their identity: they are not generally copied
(only for purposes of rollback in transactions, and such), never
assigned, you can't put them into containers (but you can put
pointers to them), etc. They often manage themselves; in a
certain sense, they have built-in intelligence.
--
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