references and pointers

[Kira Yamato]

[...]

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? Why can't you use
references to "point" to them instead?

'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.

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 *.

(I say almost, because I
believe that there are applications which don't have any
"entity" objects.

What is this entity object again?

I can imagine some serious numeric
applications, for example, which use neither pointers nor
iterators, ever.)

Iterators are for iterating. For the most part, you don't want
to maintain iterators (nor pointers to objects in a container)
for any significant duration; adding or removing elements from
the container can invalidate the iterators. STL containers are
designed with value semantics (the only semantics which really
make sense for a container in the context of C++). This means
that objects in the container do not have identity; they may
"move around".

Ah... Good to know this. Thanks for telling me this or else I might
have introduce hard-to-find bugs.

 

[James Kanze]

[...]
References are usually implemented by pointers anyway, so there is no
efficiency gain (except that you don't (shouldn't) need to check for
NULL-ness, but that's more a design issue and costs next to nothing
anyway on current hardware).

It depends. A reference cannot be reseated. The compiler knows
this. That may open up some additional optimization
possibilities, or make them simpler.

Pointers are not good for out parameters IMHO, because
pointers can be NULL.

C++ doesn't allow out parameters, at least not for class types,
so the question is moot.

For inout parameters (or parameters which are conceptually out,
even if you can't call the function without actually having
given them a value), it's a question of convention---I prefer
references, too, but I'll adapt to the local convention.

Pointers are required, on the other hand, if the out parameter
is optional---things like the second parameter to functions in
the strtoxxx family (strtod, etc.).

If I call some function for retrieving some data and passing NULL
pointer, what I'm saying?

That you're not interested in the data, only in the side effects
of looking for it.

Out parameters are not all that frequent. Except in some very
rare cases of optimization, they only occur when a function has
more than one value to return. In that case, it's a fairly
common idiom to pass the address of the second return value as a
pointer, with the convention that a null pointer means that
you're only interested in the primary return value. There are a
number of examples of this in the C standard, for example.

Do I want to get this data after all or not? If
not, why I call this function?

Because if it has an out parameter, it also has a return value,
and you're only interested in the return value.

I should call another function or overload instead if I don't
want to get any data back.

That's another alternative---provide two functions. But what is
the real difference between:
Type1 function( Type2* out = NULL ) ;
and
Type1 function() ;
Type1 function( Type2& out ) ;
(The only real difference I can see is that some older compilers
might still accept a temporary as argument in the second case.
Which is an argument for using the first alternative---and for
using pointers in general for out parameters. But you should
probably update such compilers, rather than adapting your coding
standards to them.)

In case of references I am obliged to provide the space for
data and the meaning of the operation is much clearer.

You are right that raw pointers should generally not be used
in C++ code. If pointer semantics are required, for example
for storing in STL containers, some kind of smart pointers
should be used instead.

This is simply false. There are times when smart pointers are
appropriate, but most use of pointers is for navigation, and raw
pointers are still the best solution for that.

 

[Kai-Uwe Bux]

This is simply false. There are times when smart pointers are
appropriate, but most use of pointers is for navigation, and raw
pointers are still the best solution for that.

Whether most use of pointers is for navigation depends heavily on the
application domain. You are presumably correct for event-driven programs.
However, there is a whole lot of other stuff out there where pointers are
used for other purposes (e.g., COW-optimization for large objects,
implementation of container-like data structures, working with incomplete
types to meet conceptual requirements, interfacing legacy code, ...).
Without a qualification of the type of program you are talking about,
statements about the fraction of pointers that are used for navigation
compared to what is used for other purposes seem to be a matter of pure
speculation. On the other hand, if you have some significant data on this,
I would be interested.


Best

Kai-Uwe Bux

 

[James Kanze]

On 2007-11-09 03:42:42 -0500, James Kanze <[email protected]> said:

[...]

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.

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.

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.

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.