API design choice pointer vs. object

[Divick]

Hi,
I am designing an API and the problem that I have is more of a
design issue. In my API say I have a class A and B, as shown below

class A{
public:
void doSomethingWith B( B * b)
{
//do something with b
//possibly store in a list
listB.push_back (b);
}
private:
std::vector<B *> listB;
};

class B
{
///some declarations and /or data members
};

Now the problem is either the interface to doSomethingWith B could be

void doSomethingWith B( B * b)
or
void doSomethingWith B( B & b)

If I use pointers they come with all the mess as then I might have to
do some sort of reference counting on them to tell somebody that I am
storing the pointer to B and possibly call delete or unref on them when
I remove them from the list if the ref count goes to 0. This adds lots
of memory management overhead /code to the piece above.

If I use reference rather then pointers, then probably I am not giving
the user of the API the full flexibility. I am not very sure that what
pros /cons will it have if I don't provide a interface with pointers.

Frankly until now I almost used to use pointers everywhere for member
objects, for method parameters, method return type. And this I feel is
bad.

If people can provide reasons for/against the pointer/reference
interface then it would help a lot.

Thanks,
Divick

[Victor Bazarov]

Divick wrote:

[..]
If people can provide reasons for/against the pointer/reference
interface then it would help a lot.

Can you say, "Google"? "Pointer versus reference" discussion is such
a dead horse that I can barely see the tracks in the dust where the whip
hit it last time we were beating it.

V
--
Please remove capital As from my address when replying by mail

[Noah Roberts]

Divick wrote:

Hi,
I am designing an API and the problem that I have is more of a
design issue. In my API say I have a class A and B, as shown below

class A{
public:
void doSomethingWith B( B * b)
{
//do something with b
//possibly store in a list
listB.push_back (b);
}
private:
std::vector<B *> listB;
};

class B
{
///some declarations and /or data members
};

Now the problem is either the interface to doSomethingWith B could be

void doSomethingWith B( B * b)
or
void doSomethingWith B( B & b)

Is B polymorphic? If yes you have your answer, it must be the former.

Do you want to keep copies of B or the actual B itself? If copies then
it can be the later but otherwise must be former.

For reference counting and such if you have the option you should use
Boost's shared_ptr. If not then create one...it isn't too tough.

[Marcus Kwok]

Noah Roberts <ro**********@g mail.com> wrote:

Divick wrote:

Now the problem is either the interface to doSomethingWith B could be

void doSomethingWith B( B * b)
or
void doSomethingWith B( B & b)

Is B polymorphic? If yes you have your answer, it must be the former.

I think polymorphism works with references too:
#include <iostream>

class A {
public:
virtual ~A() { }
virtual void do_something() { std::cout << "A::do_somethin g()\n"; }
};

class B : public A {
public:
virtual void do_something() { std::cout << "B::do_somethin g()\n"; }
};

void do_it(A& a)
{
a.do_something( );
}

int main()
{
B b;
do_it(b);

return 0;
}
Output:
B::do_something ()
--
Marcus Kwok

[Axter]

Noah Roberts wrote:

Divick wrote:

Hi,
I am designing an API and the problem that I have is more of a
design issue. In my API say I have a class A and B, as shown below

class A{
public:
void doSomethingWith B( B * b)
{
//do something with b
//possibly store in a list
listB.push_back (b);
}
private:
std::vector<B *> listB;
};

class B
{
///some declarations and /or data members
};

Now the problem is either the interface to doSomethingWith B could be

void doSomethingWith B( B * b)
or
void doSomethingWith B( B & b)

Is B polymorphic? If yes you have your answer, it must be the former.

That should not be a factor in making a determiniation.
If B is polymorphic, it will work with pointers or reference type.
Author's like Herb Sutter, recommend preferring to use reference type
over pointer type, because a pointer can mean two things, and therefore
more ambiguous.

I recommend a reference type, unless you know for sure you need a
pointer.

[Mirek Fidler]

void doSomethingWith B( B * b)
or
void doSomethingWith B( B & b)

If I use pointers they come with all the mess as then I might have to
do some sort of reference counting on them to tell somebody that I am
storing the pointer to B and possibly call delete or unref on them when
I remove them from the list if the ref count goes to 0. This adds lots
of memory management overhead /code to the piece above.

If I use reference rather then pointers, then probably I am not giving
the user of the API the full flexibility. I am not very sure that what
pros /cons will it have if I don't provide a interface with pointers.

....or quite opposite. In fact, when designed right, you can gain much
more flexibility without pointers and passing ownership (actually, this
is about ownership rahter than anything else). See

http://upp.sourceforge .net/www$uppweb$over view$en-us.html

(I think the "Who owns widgets" section is the most relevant here).

Mirek

[Daniel T.]

In article <11************ **********@i39g 2000cwa.googleg roups.com>,
"Divick" <di************ @gmail.com> wrote:

Hi,
I am designing an API and the problem that I have is more of a
design issue. In my API say I have a class A and B, as shown below

class A{
public:
void doSomethingWith B( B * b)
{
//do something with b
//possibly store in a list
listB.push_back (b);
}
private:
std::vector<B *> listB;
};

class B
{
///some declarations and /or data members
};

Now the problem is either the interface to doSomethingWith B could be

void doSomethingWith B( B * b)
or
void doSomethingWith B( B & b)

If people can provide reasons for/against the pointer/reference
interface then it would help a lot.

In this particular case, because of the possibility of A storing the
object beyond the return of the function, I would use a pointer.
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[Divick]

>>..or quite opposite. In fact, when designed right, you can gain much

more flexibility without pointers and passing ownership (actually, this
is about ownership rahter than anything else). See http://upp.sourceforge .net/www$uppweb$over view$en-us.html (I think the "Who owns widgets" section is the most relevant here).

I did not really get the point that this page is referring to. Could
you please explain what this page tries to explain.

Thanks,
Divick

[Divick]

>>In this particular case, because of the possibility of A storing the

object beyond the return of the function, I would use a pointer.

What is the reason behind? Could you please elaborate this more.

Thanks,
Divick

[Ben Pope]

Divick wrote:

(I think the "Who owns widgets" section is the most relevant
here).

I did not really get the point that this page is referring to. Could
you please explain what this page tries to explain.

It's probably referring to some lifetime management issues.

You should have a clear policy of how objects are allocated and how
objects are deleted.

If you are pushing "random" pointers into a list, who manages the
lifetime of the object to which it points? Is it the list? So that all
accesses are done via the list, and if it is removed from the list it is
destroyed? Is it some other entity? Will that other enitity remove it
from the list?

You can use a smart pointer to do the reference counting for you, in
which case I suggest boost::shared_p tr.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...