«

If I have an "add" method that adds a pointer to a foo to a private
std::list, should I define add like

1. void add( const foo &f ) { lst.push_back( &f ); }

to keep pointers out of my interface, or should I make it implicit that a
pointer is being added to the list, like so

2. void add( foo *f ) { lst.push_back( f ); }

Would the first method lead the user to believe that their foo is actually
being stored, potentially leading to a bad memory value in the list once
the foo is destroyed? Or is this discussion moot as long as I use pre and
post conditions?

Tim Partridge

"Tim Partridge" <> wrote...
> If I have an "add" method that adds a pointer to a foo to a private
> std::list, should I define add like
>
> 1. void add( const foo &f ) { lst.push_back( &f ); }
>
> to keep pointers out of my interface,

Most certainly not. This allows to use temporaries of type 'foo'
in a call to 'add', and you don't want to store pointers to any
temporaries in your list.

> or should I make it implicit that a
> pointer is being added to the list, like so
>
> 2. void add( foo *f ) { lst.push_back( f ); }

Yes, that's the ticket. You could of course, use a reference to
non-const 'foo':

void add(foo& f) { lst.push_back(&f); }

which is a tad better than the first one because it won't let
the caller to use a temporary.

> Would the first method lead the user to believe that their foo is actually
> being stored, potentially leading to a bad memory value in the list once
> the foo is destroyed?

Yes.

> Or is this discussion moot as long as I use pre and
> post conditions?

I suppose it depends on how you set up your conditions and their
verification.

Victor

Tim Partridge wrote:

> If I have an "add" method that adds a pointer to a foo to a private
> std::list, should I define add like
>
> 1. void add( const foo &f ) { lst.push_back( &f ); }
>
> to keep pointers out of my interface, or should I make it implicit that a
> pointer is being added to the list, like so
>
> 2. void add( foo *f ) { lst.push_back( f ); }
>
> Would the first method lead the user to believe that their foo is actually
> being stored, potentially leading to a bad memory value in the list once
> the foo is destroyed? Or is this discussion moot as long as I use pre and
> post conditions?

This is a technical question. The answer is to prefer weaker things to
stronger ones. Prefer references unless you need a pointer's extra features.
The only difference at an interface is the pointer could be NULL.

Can you push a NULL?

Another answer is symetry. The 'get' or 'pop' methods should, of course,
return the same type. Can they return a NULL, such as for a "not found"
situation?

Finally, you should avoid the implication that the list owns the object, or
that one can't enlist stack objects.

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces


>
> Tim Partridge
>