a question of style

T

Tim Partridge

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
 
V

Victor Bazarov

Tim Partridge said:
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
 
P

Phlip

Tim said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,535
Members
45,007
Latest member
obedient dusk

Latest Threads

Top