By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,406 Members | 888 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,406 IT Pros & Developers. It's quick & easy.

vector of lists: anyone know how to do this?

P: n/a
I've declared the following as a "vector" of "lists" using STL

vector< list<Edge*> >

I've tried many ways to add objects to this but can't figure out how to
do it. Does anyone have any tips, or references to material that might
explain it?

Any help greatly appreciated.

Jun 17 '06 #1
Share this Question
Share on Google+
22 Replies


P: n/a
craig wrote:
I've declared the following as a "vector" of "lists" using STL

vector< list<Edge*> >

I've tried many ways to add objects to this but can't figure out how
to do it. Does anyone have any tips, or references to material that
might explain it?


And what is reason you decided to hide your code from us? How can we
figure out what you're doing wrong?


Brian
Jun 17 '06 #2

P: n/a

craig wrote:
I've declared the following as a "vector" of "lists" using STL

vector< list<Edge*> >

I've tried many ways to add objects to this but can't figure out how to
do it. Does anyone have any tips, or references to material that might
explain it?

Any help greatly appreciated.


Why not something like:

Edge *pEdge = NULL;
vector< list< Edge * > > edges( 10 );
edges[ 0 ].push_back( pEdge );
Putting pointers into STL containers is not always a good idea. Make
sure you know what you're doing.

Prefer something like this:

boost::shared_ptr< Edge > pEdge;
vector< list< boost::shared_ptr< Edge > > edges( 10 );
edges[ 0 ].push_back( pEdge );

Your choice of smart pointer depends on context though, although
boost::shared_ptr is for many uses a good one. std::auto_ptr is not
normally a good choice.
Of course including the code that doesn't work and telling us what
you're thinking about might help us to answer better.
K

Jun 17 '06 #3

P: n/a
In article <1150530822.539811.41420
@i40g2000cwc.googlegroups.com>,
ki****************@gmail.com says...

[ ... ]
Your choice of smart pointer depends on context though, although
boost::shared_ptr is for many uses a good one. std::auto_ptr is not
normally a good choice.


Let me put that more strongly. Anything you store in a
standard container needs to be copyable, and
std::auto_ptr isn't copyable, so it's simply not allowed.
In most cases, compilation will fail if you try, though
the error message(s) rarely make the source of the
problem very clear.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jun 17 '06 #4

P: n/a
Brian,..Sorry, I didn't give more info (it was late and I was tired).
But here is a bit more:

vector<Vertex*> vertices;
// array of adjecacency lists
vector< list<Edge*> > adjLists; <<<<< the focus

This is an array(vector) of "adjacency lists" for a graph. The graph
is empty at first, and then added to dynamically. I don't know if more
initialization has to be done before I add to it, but I've tried to add
elements in the following ways. (Adding an element is essentially
adding an "Edge" to the i-th adjacency list). pEdge is a ptr to an
Edge:

I tried:
adjLists.push_back( pEdge );
then:

adjLists[0].push_back( pEdge);

then:
list <Edge*> L;
adjLists[0] = L

I've tried many other things also, but most don't compile, and the ones
that do crash.

-Craig
Default User wrote:
craig wrote:
I've declared the following as a "vector" of "lists" using STL

vector< list<Edge*> >

I've tried many ways to add objects to this but can't figure out how
to do it. Does anyone have any tips, or references to material that
might explain it?


And what is reason you decided to hide your code from us? How can we
figure out what you're doing wrong?


Brian


Jun 17 '06 #5

P: n/a
Thanks, Kirit for your comments. I'm going to see if I can incorporate
your idea into what I'm doing. I've also provided a little more info
in my response to Brian. If my initial info was too vague, perhaps you
could look at this response.

Thanks,
-Craig

Kirit Sælensminde wrote:
craig wrote:
I've declared the following as a "vector" of "lists" using STL

vector< list<Edge*> >

I've tried many ways to add objects to this but can't figure out how to
do it. Does anyone have any tips, or references to material that might
explain it?

Any help greatly appreciated.


Why not something like:

Edge *pEdge = NULL;
vector< list< Edge * > > edges( 10 );
edges[ 0 ].push_back( pEdge );
Putting pointers into STL containers is not always a good idea. Make
sure you know what you're doing.

Prefer something like this:

boost::shared_ptr< Edge > pEdge;
vector< list< boost::shared_ptr< Edge > > edges( 10 );
edges[ 0 ].push_back( pEdge );

Your choice of smart pointer depends on context though, although
boost::shared_ptr is for many uses a good one. std::auto_ptr is not
normally a good choice.
Of course including the code that doesn't work and telling us what
you're thinking about might help us to answer better.


K


Jun 17 '06 #6

P: n/a
On 17 Jun 2006 10:44:38 -0700, "craig" <cr**********@comcast.net>
wrote:
vector<Vertex*> vertices;
// array of adjecacency lists
vector< list<Edge*> > adjLists; <<<<< the focus

This is an array(vector) of "adjacency lists" for a graph. The graph
is empty at first, and then added to dynamically. I don't know if more
initialization has to be done before I add to it, but I've tried to add
elements in the following ways. (Adding an element is essentially
adding an "Edge" to the i-th adjacency list). pEdge is a ptr to an
Edge:

I tried:
adjLists.push_back( pEdge );
This does not compile because you try to push a pointer to and Edge
object into a vector of lists(!) of pointers to Edges.
then:

adjLists[0].push_back( pEdge);
adjLists is empty, you access the fist element in an empty array ->
crash.
then:
list <Edge*> L;
adjLists[0] = L
again, you access to fist element in an empty array.
I've tried many other things also, but most don't compile, and the ones
that do crash.


You have an array of list <Edge*>. So, first you need an element in
your array. Since STL supports only value semantics you have to copy a
list <Edge*> into adjLists.

list <Edge*> lst;
adjLists.push_back (lst);

// alternatively: adjLists.resize(1);

Then you can access the inserted list<Edge*> (the first and only so
far) with operator[], which returns a refernce(!) to that list
<Edge*>.

adjLists[0].push_back( pEdge);

Good luck!
Roland Pibinger
Jun 17 '06 #7

P: n/a
Thanks so much Roland!! I'm deeply greatful!

I'm in a pinch and am trying to get this to work properly after
considering other alternatives. I definitely need to study templates
much more when I get a chance.

If you (or any one else) has a moment, one more question:

Currently I am trying to use this "vector of lists" in the following
graph member:

void Graph::addEdge( Vertex &v1, Vertex &v2, int weight )
{
ind = "compute index of Vertex in vertex list"
Edge *e = new Edge (v1, v2, weight );
list <Edge*> lst; <<<<<<<<< important part to
make dynamic
adjLists.push_back (lst); <<<<<<<<<important part to make
dynamic
adjLists[ind].push_back( e );
}
I need to dynamically create a new "list <Edge*> " in place of "lst"
upon each call to "addEdge". How do I do this with templates?

Thanks,....
-Craig


Roland Pibinger wrote:
On 17 Jun 2006 10:44:38 -0700, "craig" <cr**********@comcast.net>
wrote:
vector<Vertex*> vertices;
// array of adjecacency lists
vector< list<Edge*> > adjLists; <<<<< the focus

This is an array(vector) of "adjacency lists" for a graph. The graph
is empty at first, and then added to dynamically. I don't know if more
initialization has to be done before I add to it, but I've tried to add
elements in the following ways. (Adding an element is essentially
adding an "Edge" to the i-th adjacency list). pEdge is a ptr to an
Edge:

I tried:
adjLists.push_back( pEdge );


This does not compile because you try to push a pointer to and Edge
object into a vector of lists(!) of pointers to Edges.
then:

adjLists[0].push_back( pEdge);


adjLists is empty, you access the fist element in an empty array ->
crash.
then:
list <Edge*> L;
adjLists[0] = L


again, you access to fist element in an empty array.
I've tried many other things also, but most don't compile, and the ones
that do crash.


You have an array of list <Edge*>. So, first you need an element in
your array. Since STL supports only value semantics you have to copy a
list <Edge*> into adjLists.

list <Edge*> lst;
adjLists.push_back (lst);

// alternatively: adjLists.resize(1);

Then you can access the inserted list<Edge*> (the first and only so
far) with operator[], which returns a refernce(!) to that list
<Edge*>.

adjLists[0].push_back( pEdge);

Good luck!
Roland Pibinger


Jun 17 '06 #8

P: n/a
Again , thanks so much Roland and others!!!

Roland you corrections worked perfectly. One more question for anyone:
I need to dynamically create new "list <Edge*>"'s in place of "lst"
upon subsequent calls to "addEdge" (code below). How do I do this with
templates?

Do I create a list <Edge*> lists[10]; somewhere and index into it?

void Graph::addEdge( Vertex &v1, Vertex &v2, int weight )
{
ind = "compute index of Vertex in vertex list"
Edge *e = new Edge (v1, v2, weight );
list <Edge*> lst; <- how to make dynamic ??
adjLists.push_back (lst); <-how to make dynamic??
adjLists[ind].push_back( e );
}


Roland Pibinger wrote:
On 17 Jun 2006 10:44:38 -0700, "craig" <cr**********@comcast.net>
wrote:
vector<Vertex*> vertices;
// array of adjecacency lists
vector< list<Edge*> > adjLists; <<<<< the focus

This is an array(vector) of "adjacency lists" for a graph. The graph
is empty at first, and then added to dynamically. I don't know if more
initialization has to be done before I add to it, but I've tried to add
elements in the following ways. (Adding an element is essentially
adding an "Edge" to the i-th adjacency list). pEdge is a ptr to an
Edge:

I tried:
adjLists.push_back( pEdge );


This does not compile because you try to push a pointer to and Edge
object into a vector of lists(!) of pointers to Edges.
then:

adjLists[0].push_back( pEdge);


adjLists is empty, you access the fist element in an empty array ->
crash.
then:
list <Edge*> L;
adjLists[0] = L


again, you access to fist element in an empty array.
I've tried many other things also, but most don't compile, and the ones
that do crash.


You have an array of list <Edge*>. So, first you need an element in
your array. Since STL supports only value semantics you have to copy a
list <Edge*> into adjLists.

list <Edge*> lst;
adjLists.push_back (lst);

// alternatively: adjLists.resize(1);

Then you can access the inserted list<Edge*> (the first and only so
far) with operator[], which returns a refernce(!) to that list
<Edge*>.

adjLists[0].push_back( pEdge);

Good luck!
Roland Pibinger


Jun 17 '06 #9

P: n/a

craig wrote:
void Graph::addEdge( Vertex &v1, Vertex &v2, int weight )
{
ind = "compute index of Vertex in vertex list"
Edge *e = new Edge (v1, v2, weight );
list <Edge*> lst; <- how to make dynamic ??
adjLists.push_back (lst); <-how to make dynamic??
adjLists[ind].push_back( e );
}


The list is already dynamic, the push_back will add to the end. The
vector is slightly different though. I think you missed the suggestion
of the resize() somewhere.

What you need is (I'm not g'teeing it will compile directly) is
something like:

vector< list< boost::shared_ptr< Edge > > >::size_type ind = /* Your
calc */;
if ( adjLists.size() < ind + 1 ) // Remember it is zero indexed
adjLists.resize( ind + 1 );
adjLists[ ind ].push_back( boost::shared_ptr< Edge >( new Edge( v1, v2,
weight ) ) );

Things to note:
* The if statement checks to see that the vector is big enough _before_
you access the index.
* The use of the smart pointer. Don't get in the habit of using raw
pointers.
* The use of the type vector<>::size_type for the index. Your compiler
vendor has gone to a lot of trouble making sure you won't have any
unexpected overflows etc. when they chose this type. Use it rather than
make your own guess about what is right.
* The vector is zero indexed so index 1 means it must be at least size
2
K

Jun 18 '06 #10

P: n/a
On 17 Jun 2006 20:00:27 <ki****************@gmail.com> wrote:
craig wrote:
void Graph::addEdge( Vertex &v1, Vertex &v2, int weight )
{
ind = "compute index of Vertex in vertex list"
Edge *e = new Edge (v1, v2, weight );
list <Edge*> lst; <- how to make dynamic ??
adjLists.push_back (lst); <-how to make dynamic??
adjLists[ind].push_back( e );
}
The list is already dynamic, the push_back will add to the end. The
vector is slightly different though. I think you missed the suggestion
of the resize() somewhere.

What you need is (I'm not g'teeing it will compile directly) is
something like:

vector< list< boost::shared_ptr< Edge > > >::size_type ind = /* Your
calc */;
if ( adjLists.size() < ind + 1 ) // Remember it is zero indexed
adjLists.resize( ind + 1 );
adjLists[ ind ].push_back( boost::shared_ptr< Edge >( new Edge( v1, v2,
weight ) ) );


Why shared_ptrs here? They behave like real pointers but obfuscate the
code, create a dependency to Boost, add the overhead of one
dynamically allocated counter for each Edge object (e.g. 1000 Edges
means 1000 superfluous dynamic allocations), ...
The usual way is to let the destructor do the cleanup.
Things to note:
* The if statement checks to see that the vector is big enough _before_
you access the index.
* The use of the smart pointer. Don't get in the habit of using raw
pointers.
On the contrary. Get the habit to avoid "smart" pointers!!
* The use of the type vector<>::size_type for the index. Your compiler
vendor has gone to a lot of trouble making sure you won't have any
unexpected overflows etc. when they chose this type. Use it rather than
make your own guess about what is right.
* The vector is zero indexed so index 1 means it must be at least size
2


The code may now look like this:

void Graph::addEdge( Vertex &v1, Vertex &v2, int weight )
{
ind = "compute index of Vertex in vertex list"
Edge *e = new Edge (v1, v2, weight );
if (! (ind < adjLists.size()))
{
adjLists.resize(ind + 1);
}
// push_back dynamically grows the list
adjLists[ind].push_back( e );
}
// destructor
Graph::~Graph()
{
for (vector<list<Edge*> >::size_tye ind = 0;
ind < adjLists.size(); ++ind)
{
for (list<Edge*>::iterator it = adjLists[ind].begin();
it != adjLists[ind].end(); ++it)
{
delete *it;
}
}
}

Jun 18 '06 #11

P: n/a
Roland,..wow it works!
Again thanks so much,,.I owe you one.

-Craig

Roland Pibinger wrote:
On 17 Jun 2006 20:00:27 <ki****************@gmail.com> wrote:
craig wrote:
void Graph::addEdge( Vertex &v1, Vertex &v2, int weight )
{
ind = "compute index of Vertex in vertex list"
Edge *e = new Edge (v1, v2, weight );
list <Edge*> lst; <- how to make dynamic ??
adjLists.push_back (lst); <-how to make dynamic??
adjLists[ind].push_back( e );
}


The list is already dynamic, the push_back will add to the end. The
vector is slightly different though. I think you missed the suggestion
of the resize() somewhere.

What you need is (I'm not g'teeing it will compile directly) is
something like:

vector< list< boost::shared_ptr< Edge > > >::size_type ind = /* Your
calc */;
if ( adjLists.size() < ind + 1 ) // Remember it is zero indexed
adjLists.resize( ind + 1 );
adjLists[ ind ].push_back( boost::shared_ptr< Edge >( new Edge( v1, v2,
weight ) ) );


Why shared_ptrs here? They behave like real pointers but obfuscate the
code, create a dependency to Boost, add the overhead of one
dynamically allocated counter for each Edge object (e.g. 1000 Edges
means 1000 superfluous dynamic allocations), ...
The usual way is to let the destructor do the cleanup.
Things to note:
* The if statement checks to see that the vector is big enough _before_
you access the index.
* The use of the smart pointer. Don't get in the habit of using raw
pointers.


On the contrary. Get the habit to avoid "smart" pointers!!
* The use of the type vector<>::size_type for the index. Your compiler
vendor has gone to a lot of trouble making sure you won't have any
unexpected overflows etc. when they chose this type. Use it rather than
make your own guess about what is right.
* The vector is zero indexed so index 1 means it must be at least size
2


The code may now look like this:

void Graph::addEdge( Vertex &v1, Vertex &v2, int weight )
{
ind = "compute index of Vertex in vertex list"
Edge *e = new Edge (v1, v2, weight );
if (! (ind < adjLists.size()))
{
adjLists.resize(ind + 1);
}
// push_back dynamically grows the list
adjLists[ind].push_back( e );
}
// destructor
Graph::~Graph()
{
for (vector<list<Edge*> >::size_tye ind = 0;
ind < adjLists.size(); ++ind)
{
for (list<Edge*>::iterator it = adjLists[ind].begin();
it != adjLists[ind].end(); ++it)
{
delete *it;
}
}
}


Jun 18 '06 #12

P: n/a

Roland Pibinger wrote:
On 17 Jun 2006 20:00:27 <ki****************@gmail.com> wrote:
* The use of the smart pointer. Don't get in the habit of using raw
pointers.


On the contrary. Get the habit to avoid "smart" pointers!!


Hmmm. Not sure that is great advice. Obviously there are places where
raw pointers are appropriate, but once you have the level of skill to
know where they are, then you should know how to use them safely too.

Smart pointers are much safer for use by beginners. I suppose that we
could argue about this until the cows come home. I am somewhat
surprised though. I would have thought recommending smart pointers to
be particularly non-contentious.
K

Jun 19 '06 #13

P: n/a
craig wrote:
I've declared the following as a "vector" of "lists" using STL

vector< list<Edge*> >


The elements of a vector must be copyable and assignable.
If you copy a list<Edge*> you will get another list that has
all the same pointers in it. If you then 'delete' the pointers
in one list then the other list will have dangling pointers.

What is your reason for not using a list of Edges?

vector< list<Edge> >

Jun 19 '06 #14

P: n/a
Some of the possible reasons are:
- Each edge object might take lots of memory and if the graph is big,
you might end up using lot of memory
- If you have multiple lists each with a different object, if you
modify one object, the same object in other list does not get updated.
This is because these are two different objects now. It will be hard to
track down bugs that can arise because of this.

Best solution for a situation like this is to use auto/smart pointers
for Edge class. That will allow you to make as many copies of
list<Edge*> and only when the last one is deleted is when your object
will be really deleted.

Atul

Old Wolf wrote:
craig wrote:
I've declared the following as a "vector" of "lists" using STL

vector< list<Edge*> >


The elements of a vector must be copyable and assignable.
If you copy a list<Edge*> you will get another list that has
all the same pointers in it. If you then 'delete' the pointers
in one list then the other list will have dangling pointers.

What is your reason for not using a list of Edges?

vector< list<Edge> >


Jun 19 '06 #15

P: n/a
* Kirit Sælensminde:
Roland Pibinger wrote:
On 17 Jun 2006 20:00:27 <ki****************@gmail.com> wrote:
* The use of the smart pointer. Don't get in the habit of using raw
pointers.

On the contrary. Get the habit to avoid "smart" pointers!!


Hmmm. Not sure that is great advice. Obviously there are places where
raw pointers are appropriate, but once you have the level of skill to
know where they are, then you should know how to use them safely too.

Smart pointers are much safer for use by beginners. I suppose that we
could argue about this until the cows come home. I am somewhat
surprised though. I would have thought recommending smart pointers to
be particularly non-contentious.


If you read this group for a while you'll discover that Roland, for some
unknown reason, takes a very dim view of template-based stuff, including
smart pointers and the Boost library.

Both smart pointers and the Boost library (which contains a number of
smart pointer classes) are highly recommended by most experts, for both
novices and professionals -- although the professionals generally
don't need the recommendation, since most professional C++ programmers
are already using smart pointers and Boost.

The only reason I can think of why Roland recommends against is that
he's stuck with a code base that requires some old compiler that doesn't
handle templates well. Happily that isn't a problem for a novice. Nor
is it a problem in general, but it's an issue one does not control
(except by making sure one isn't made responsible for such old code...).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jun 19 '06 #16

P: n/a
On Mon, 19 Jun 2006 06:30:37 +0200, "Alf P. Steinbach"
<al***@start.no> wrote:
If you read this group for a while you'll discover that Roland, for some
unknown reason, takes a very dim view of template-based stuff, including
smart pointers and the Boost library.
The reasons are anything but dim.
Both smart pointers and the Boost library (which contains a number of
smart pointer classes) are highly recommended by most experts, for both
novices and professionals
Really? Look for 'smart pointer' in the following articles:
http://www.research.att.com/~bs/DnE2005.pdf
http://www.accu-usa.org/Slides/ACrit...pPractices.pdf
-- although the professionals generally
don't need the recommendation, since most professional C++ programmers
are already using smart pointers and Boost.
Being a 'professional', do you really recommend to put smart pointers
into a Standard container?
The only reason I can think of why Roland recommends against is that
he's stuck with a code base that requires some old compiler that doesn't
handle templates well.
Nope
Happily that isn't a problem for a novice. Nor
is it a problem in general, but it's an issue one does not control
(except by making sure one isn't made responsible for such old code...).


Usability is the problem that interests me most. When users have
difficulties because a library (any library, not particularly Boost)
has complex and inconvenient interfaces or produces intangible error
messages (dozens of lines) then you have two alternatives:
1. Blame the user for not being smart enough to grasp the 'ingenious'
library.
2. Blame the library for not providing convenient interfaces and/or
simple handling.
I prefer the latter.

Regards,
Roland Pibinger
Jun 19 '06 #17

P: n/a
* Roland Pibinger:
* Alf P. Steinbach:
Both smart pointers and the Boost library (which contains a number of
smart pointer classes) are highly recommended by most experts, for both
novices and professionals


Really? Look for 'smart pointer' in the following articles:
http://www.research.att.com/~bs/DnE2005.pdf


Thanks, you have hit on what seems to be a typo: after starting out
writing "shared_ptr" Bjarne then continues, in the same paragraph,
writing "smart_ptr" where the discussion is about "shared_ptr" (and the
idea that one size fits all, shared_ptr is not that idea).

CC: Bjarne Stroustrup

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jun 19 '06 #18

P: n/a
On Mon, 19 Jun 2006 20:23:27 +0200, "Alf P. Steinbach"
<al***@start.no> wrote:
* Roland Pibinger:
Really? Look for 'smart pointer' in the following articles:
http://www.research.att.com/~bs/DnE2005.pdf


Thanks, you have hit on what seems to be a typo: after starting out
writing "shared_ptr" Bjarne then continues, in the same paragraph,
writing "smart_ptr" where the discussion is about "shared_ptr" (and the
idea that one size fits all, shared_ptr is not that idea).


Yes, it's a typo. But the message is clear, isn't it?
Jun 19 '06 #19

P: n/a
* Roland Pibinger:
On Mon, 19 Jun 2006 20:23:27 +0200, "Alf P. Steinbach"
<al***@start.no> wrote:
* Roland Pibinger:
Really? Look for 'smart pointer' in the following articles:
http://www.research.att.com/~bs/DnE2005.pdf

Thanks, you have hit on what seems to be a typo: after starting out
writing "shared_ptr" Bjarne then continues, in the same paragraph,
writing "smart_ptr" where the discussion is about "shared_ptr" (and the
idea that one size fits all, shared_ptr is not that idea).


Yes, it's a typo. But the message is clear, isn't it?


The message is very clear: think about what you're doing, don't use
memorized mechanical rules.

And in that paragraph, don't use shared_ptr for everything.

Essentially that's why Boost provides a number of other smart pointer
classes. The addition of shared_ptr to the standard library doesn't
mean we no longer need to use other smart pointers. And it doesn't mean
we don't need to use raw pointers here and there.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jun 19 '06 #20

P: n/a
Kirit Sælensminde wrote :
Prefer something like this:

boost::shared_ptr< Edge > pEdge;


You shouldn't use boost::shared_ptr for that. Actually I still wonder
why you should ever use it.

If you really want a container of pointers (because of polymorphism),
then use boost pointer containers.
Otherwise just use a container of Edge, not of Edge*.

Jun 20 '06 #21

P: n/a
at**********@gmail.com wrote :
- Each edge object might take lots of memory and if the graph is big,
you might end up using lot of memory


If he wanted to make a graph he should just use boost.graph.
Jun 20 '06 #22

P: n/a

loufoque wrote:
Kirit Sælensminde wrote :
Prefer something like this:

boost::shared_ptr< Edge > pEdge;


You shouldn't use boost::shared_ptr for that. Actually I still wonder
why you should ever use it.

If you really want a container of pointers (because of polymorphism),
then use boost pointer containers.
Otherwise just use a container of Edge, not of Edge*.


Without knowing more about the context it is of course hard to know
which smart pointer to use. An edge normally would have no pointers
back out (BOCTOE) so there should be no chance of circular dependancies
making boost::shared_ptr a reasonable choice. I did say that it was
_often_ a good choice, not that it was _always_ a good choice.

Is there a better general purpose smart pointer around? (This is a
genuine question)
K

Jun 21 '06 #23

This discussion thread is closed

Replies have been disabled for this discussion.