destructor for vector

[Agent Mulder]

Hi group,

I have a class called container with a vector of
pointers to some base class as member. Can
someone help me find the right destructor for
this class?

Thanks, Martijn Mulder


#include <vector.h>
#include <algorithm.h>
class base{};
class first:public base{};
class second:public base{};
class third:public base{};
class container
{
private:vector< base*>b;
public:containe r()
{
b.push_back(new first);
b.push_back(new second);
b.push_back(new third);
}
//?? public:virtual ~container(){fo r_each(b.begin( ),b.end(),delet e);}
};
int main(int argc,char**argv )
{
container c;
return 0;
}

[Blake Kaplan]

Re: destructor for vector

On Wed, 09 Jul 2003 01:12:04 +0200, Agent Mulder wrote:
[color=blue]
> Hi group,
>
> I have a class called container with a vector of
> pointers to some base class as member. Can
> someone help me find the right destructor for
> this class?[/color]
[snip][color=blue]
> //?? public:virtual ~container(){fo r_each(b.begin( ),b.end(),delet e);}[/color]
[snip]

You could create a functor which does what you need:
template <class T>
struct doDelete {
void operator()(T *target) { delete target; }
};

virtual ~container() { for_each(b.begi n(), b.end(), delete<base>()) ; }
--
Blake Kaplan

"War doesn't determine who's right, but who's left."

[Cy Edmunds]

Re: destructor for vector

"Agent Mulder" <mbmulder_remov e_this_@home.nl > wrote in message
news:befiqf$p86 $1@news2.tilbu1 .nb.home.nl...[color=blue]
> Hi group,
>
> I have a class called container with a vector of
> pointers to some base class as member. Can
> someone help me find the right destructor for
> this class?
>
> Thanks, Martijn Mulder
>
>
> #include <vector.h>
> #include <algorithm.h>
> class base{};
> class first:public base{};
> class second:public base{};
> class third:public base{};
> class container
> {
> private:vector< base*>b;
> public:containe r()
> {
> b.push_back(new first);
> b.push_back(new second);
> b.push_back(new third);
> }
> //?? public:virtual ~container(){fo r_each(b.begin( ),b.end(),delet e);}
> };
> int main(int argc,char**argv )
> {
> container c;
> return 0;
> }
>
>[/color]

#include "boost/smart_ptr.hpp" // see www.boost.org

class container
{

public:
typedef boost::shared_p tr<base> t_pbase;
private:
vector<t_pbase> b;
public:
container()
{
b.push_back(t_p base(new first));
b.push_back(t_p base(new second));
b.push_back(t_p base(new third));
}
// no destructor, copy constructor, or assignment operator required
};

A class which needs a destructor, an assignment operator, or a copy
constructor almost always needs all three. In this case just adding a
destructor to your class wouldn't be good enough -- any attempt to copy an
object of this type would eventually lead to the same pointer being deleted
twice. So you would have to add an assignment operator and a copy
constructor, remembering to check for x=x blah blah blah

I recommend you take it easy on yourself and use a reference counted smart
pointer as I have shown above. It has the copy semantics you want, manages
memory for you, and in most ways acts like a regular pointer.

--
Cy

http://home.rochester.rr.com/cyhome/

[Peter Gregory]

Re: destructor for vector

John Harrison wrote:
[color=blue]
>
> That's why Cy's smart pointers should be considered because they remove
> the need to write the destructor, copy constructor and assignment
> operator, thereby simplifying your task.
>
> john[/color]

I have never heard of these Cy smart pointers, but they sound very useful.
How are they used? Any code snippets that could show us?
Thanks,
pete

[Thomas Gulbrandsen]

Re: destructor for vector


"Blake Kaplan" <mrbkap@hotpop. com> wrote in message
news:pan.2003.0 7.09.01.12.40.9 76750@hotpop.co m...[color=blue]
> On Wed, 09 Jul 2003 01:12:04 +0200, Agent Mulder wrote:
>[color=green]
> > Hi group,
> >
> > I have a class called container with a vector of
> > pointers to some base class as member. Can
> > someone help me find the right destructor for
> > this class?[/color]
> [snip][color=green]
> > //?? public:virtual ~container(){fo r_each(b.begin( ),b.end(),delet e);}[/color]
> [snip]
>
> You could create a functor which does what you need:
> template <class T>
> struct doDelete {
> void operator()(T *target) { delete target; }
> };
>
> virtual ~container() { for_each(b.begi n(), b.end(), delete<base>()) ; }
> --
> Blake Kaplan
>
> "War doesn't determine who's right, but who's left."
>[/color]

class delete_pointer
{
public:
template <class __p>
void operator()(cons t _p* p)const
{
delete p;
}
};

and

virtual ~container(){st d::for_each(b.b egin(), b.end() , delete_pointer( ));}

Here the compiler will sort out witch type you want to delete.

-Thomas Gulbrandsen

[Thomas Gulbrandsen]

Re: destructor for vector


"Peter Gregory" <peter.gregory@ durham.ac.uk> wrote in message
news:begssp$hqb $1@sirius.dur.a c.uk...[color=blue]
> John Harrison wrote:
>[color=green]
> >
> > That's why Cy's smart pointers should be considered because they remove
> > the need to write the destructor, copy constructor and assignment
> > operator, thereby simplifying your task.
> >
> > john[/color]
>
> I have never heard of these Cy smart pointers, but they sound very useful.
> How are they used? Any code snippets that could show us?
> Thanks,
> pete[/color]


#include <iostream>
#include <string>
#include <set>
#include <boost\shared_p tr.hpp>
void print_smart_ptr (const boost::shared_p tr<std::string> smart_ptr)
{
std::cout << smart_ptr->c_str() << std::endl;
}
void print_ptr(const std::string* const s)
{
std::cout << s->c_str() << std::endl;
}
int main(int argc, _TCHAR* argv[])
{
//create a shared_ptr
boost::shared_p tr<std::string> smart_ptr(new std::string("sm art_ptr"));

//send it to a function
print_smart_ptr (smart_ptr);

//operator*
*smart_ptr = "smart_ptr again";
print_smart_ptr (smart_ptr);

//get the raw_pointer
std::wstring* r = smart_ptr.get() ;
print_ptr(r);

//reallocation
smart_ptr.reset (new std::string("sm art_ptr_reset") );
print_smart_ptr (smart_ptr);

//swap smart_ptr
boost::shared_p tr<std::string> swap(new std::string("sw aped"));
smart_ptr.swap( swap);
print_smart_ptr (smart_ptr);

return 0;
}

This is a litle code snippet that show some use of boost::shared_p tr

Go to this link for more info

http://www.boost.org/libs/smart_ptr/shared_ptr.htm

-Thomas Gulbrandsen

[John Harrison]

Re: destructor for vector


"Peter Gregory" <peter.gregory@ durham.ac.uk> wrote in message
news:begssp$hqb $1@sirius.dur.a c.uk...[color=blue]
> John Harrison wrote:
>[color=green]
> >
> > That's why Cy's smart pointers should be considered because they remove
> > the need to write the destructor, copy constructor and assignment
> > operator, thereby simplifying your task.
> >
> > john[/color]
>
> I have never heard of these Cy smart pointers, but they sound very useful.
> How are they used? Any code snippets that could show us?
> Thanks,
> pete[/color]

I think a book would be need to explain all the possibilities. 'More
Effective C++' by Scott Meyers has a detailed section on reference counting
which is usually what people are talking about when the say smart pointer.

john

[Default User]

Re: destructor for vector



Cy Edmunds wrote:
[color=blue]
> #include "boost/smart_ptr.hpp" // see www.boost.org[/color]


When did the Boost library get added to standard C++, the only topic of
this newsgroup?




Brian Rodenborn

[Howard Hinnant]

Re: destructor for vector

In article <3F0C423B.6BCD7 A2B@company.com >, Default User
<first.last@com pany.com> wrote:

| Cy Edmunds wrote:
|
| > #include "boost/smart_ptr.hpp" // see www.boost.org
|
|
| When did the Boost library get added to standard C++, the only topic of
| this newsgroup?
|
|
|
|
| Brian Rodenborn

Well, on April 11, 2003 the C++ standards committee voted a proposal
based on the contents of "boost/smart_ptr.hpp" into the first library
technical report. It could start appearing in your local
vendor-supplied <memory> header under namespace std::tr1 just any day
now.

That seems pretty on topic to me, especially for a newsgroup called
comp.lang.c++ (as opposed to comp.std.c++).

In fact I find Cy's post infinitely more on topic, and more helpful,
than say the following posts:

In article <3F045816.F8E86 287@company.com >, Default User
<first.last@com pany.com> wrote:

| Alexander Terekhov wrote:
| >
| > Default User wrote:
| > [...]
| > > Yeah . . . I going to need you to go into my killfile. Yeah . . . move
| > > all the way to the back. Thanks, that'll be great.
| >
| > I'm just curious: how BIG is your killfile?
|
| Don't worry Al, there's a place for you if you really need it.
|
|
|
| Brian Rodenborn

In article <3F049040.E3DEC 861@company.com >, Default User
<first.last@com pany.com> wrote:

| Alexander Terekhov wrote:
| >
| > Default User wrote:
|
| > > Don't worry Al, there's a place for you if you really need it.
| >
| > For free?
|
|
| I didn't charge you for the cheese, did I?
|
|
|
| Brian Rodenborn

In article <3F09B414.E9B32 BD3@company.com >, Default User
<first.last@com pany.com> wrote:

| Alexander Terekhov wrote:
| >
| > Default User wrote:
|
| > > I didn't charge you for the cheese, did I?
| >
| > Cheese? I had to pay for garbage recycling.
|
|
| What?! That was the finest genetically engineered Merican cheese food
| substitute. All you had to do was unwrap it and place it on the ground,
| it would have dissolved a tunnel straight down at least 500 feet (that's
| like 29657.222 kizzometrics or whatever weird measurements you use over
| there). No disposal costs were required at all.
|
| You don't know much about cheese.
|
|
|
|
| Brian Rodenborn

In article <3F045887.72AC8 119@company.com >, Default User
<first.last@com pany.com> wrote:

| "E. Robert Tisdale" wrote:
|
| > There is seldom a good reason why a legitimate post
| > to a technical newsgroup like comp.lang.c++
| > should evoke a strong emotional response in any subscriber.
| > If it does, you should suspect a troll.
|
|
| Well, I feel that way about many of your posts, especially on
| comp.lang.c.
|
|
|
|
| Brian Rodenborn

In article <3F09B20F.17F84 62A@company.com >, Default User
<first.last@com pany.com> wrote:

| David White wrote:
| >
| > E. Robert Tisdale <E.Robert.Tisda le@jpl.nasa.gov > wrote in message
| > news:3F04AD52.8 090102@jpl.nasa .gov...
| > > Has anybody heard from Neil Butterworth lately?
| >
| > No, but there is this post in Google:
|
| > He's simply playing the deputy of Mr. NeilB (he's currently on
| > vacation) and Mr. "Default User" desperately wants to become a
| > deputy of Mr. v.Abazarov@attA bi.com-Please-remove-capital-A's.
|
|
| Oh, hey, I missed this the first time! If I become deputy do I get a tin
| star?
|
| It's nice that Al thinks so highly of me.
|
|
|
| Brian Rodenborn

In article <3F09D117.F83B2 70E@company.com >, Default User
<first.last@com pany.com> wrote:

| Alexander Terekhov wrote:
|
| > Yeah. Now glide your Boeing down to earth and try to catch up on
| > the Airbus Super Jumbo.
|
|
| I don't work on that icky old commercial stuff.
|
|
|
| Brian Rodenborn

--
Howard Hinnant

[Alexander Terekhov]

Re: destructor for vector


Howard Hinnant wrote:
[...][color=blue]
> In fact I find Cy's post infinitely more on topic, and more helpful,
> than say the following posts:
>
> In article <3F045816.F8E86 287@company.com >, Default User
> <first.last@com pany.com> wrote:
>
> | Alexander Terekhov wrote: .....[/color]

Default, moral: don't mess with me. Take a hit and go away to heal
your wounds. Come back and "goto moral;".

regards,
alexander.

[Default User]

Re: destructor for vector



Howard Hinnant wrote:
[color=blue]
> Well, on April 11, 2003 the C++ standards committee voted a proposal
> based on the contents of "boost/smart_ptr.hpp" into the first library
> technical report. It could start appearing in your local
> vendor-supplied <memory> header under namespace std::tr1 just any day
> now.
>
> That seems pretty on topic to me, especially for a newsgroup called
> comp.lang.c++ (as opposed to comp.std.c++).[/color]

Sounds like they're farther along than last I checked. In fact, nothing
on their website about it that I can see yet.

My point was that it isn't (or wasn't) standard/ People who propose its
use should make that clear. For instance, anyone working in defense or
other critical industries can't just throw in a third-party library.

If it (or part of it) is now standard, that does put a different spin on
things. Of course, as far as I can tell that only refers to smart
pointers, not other Boost elements. There's still the problem of getting
a standardized version of this feature (with correct headers and such).
Right now, most people are still going to have to use Boost as if it
were a third-party library.



Brian Rodenborn

[Default User]

Re: destructor for vector



Alexander Terekhov wrote:
[color=blue]
> Default, moral: don't mess with me. Take a hit and go away to heal
> your wounds. Come back and "goto moral;".[/color]


Eh, what? Could you try that again in English? I haven't the faintest
idea what you are trying to say.




Brian Rodenborn

[Howard Hinnant]

Re: destructor for vector

In article <3F0C7F25.B685F FB9@company.com >, Default User
<first.last@com pany.com> wrote:

| Howard Hinnant wrote:
|
| > Well, on April 11, 2003 the C++ standards committee voted a proposal
| > based on the contents of "boost/smart_ptr.hpp" into the first library
| > technical report. It could start appearing in your local
| > vendor-supplied <memory> header under namespace std::tr1 just any day
| > now.
| >
| > That seems pretty on topic to me, especially for a newsgroup called
| > comp.lang.c++ (as opposed to comp.std.c++).
|
| Sounds like they're farther along than last I checked. In fact, nothing
| on their website about it that I can see yet.

http://anubis.dkuug.dk/jtc1/sc22/wg21/

Click on: News 2003-07-03: What will be in the Library TR?

| My point was that it isn't (or wasn't) standard/ People who propose its
| use should make that clear. For instance, anyone working in defense or
| other critical industries can't just throw in a third-party library.

<sigh> When a major C++ library testing ground is off topic in
comp.lang.c++, something, somewhere has gone wrong. And I'm sorry I
picked on you. You didn't start this nonsense, you just happened to be
the latest topic-Nazi on the same day when I felt I couldn't stand it
any more. This could be a great newsgroup if there weren't so many
self appointed moderators.

If you feel something isn't on topic, just don't respond.

Having said that, if you can politely redirect someone to someplace
where he might get more information, I have no problem with that.

| If it (or part of it) is now standard, that does put a different spin on
| things.

Now that's something on-topic I can contribute: No, the library
technical report (LTR1) is not normative, meaning it is not standard.
It is informational only. Informally speaking, it basically means that
the standards committee is interested in this library. It paves the
way for including such a library in a future C++ standard. But it does
not guarantee it. And inclusion in a LTR is not a requirement for a
library to be included in a future C++ standard.

The vendors have informally agreed that libraries appearing in the
first LTR, if shipped, will go into namespace std::tr1. Though there
is no standard requirement that a vendor ship anything in a LTR.
Inclusion in this namespace will allow a smoother transition if the
library is standardized but also modified at the same time (and
presumably then migrated to namespace std).

| Of course, as far as I can tell that only refers to smart
| pointers, not other Boost elements.

See http://anubis.dkuug.dk/jtc1/sc22/wg21/ for the current list (which
may change again this October).

| There's still the problem of getting
| a standardized version of this feature (with correct headers and such).
| Right now, most people are still going to have to use Boost as if it
| were a third-party library.

<nod> Changing/modifying a standard is a very big and slow process.
Boost will play a role. Other non-boost libraries probably will too.
It is my dream that discussions concerning non-std libraries, and even
non-std C++ language extensions (typeof anybody?) could take place in
comp.lang.c++ without fear of heckling from self appointed moderators.

--
Howard Hinnant

[Default User]

Re: destructor for vector



Cy Edmunds wrote:
[color=blue]
> I'd say the moral is "don't mess with Howard." His rebuttal was a
> masterpiece.[/color]


Only to a certain extent, see my rebuttal to the rebuttal. I'd have
taken a somewhat lighter tone (or not bothered) had I know the progress
of the smart pointers. However, people here have been recommending them
for quite some time where they certainly were not in any way a part of
the language.

For most people still, Boost represents a third-party library.




Brian Rodenborn

[Default User]

Re: destructor for vector



Alexander Terekhov wrote:[color=blue]
>
> Default User wrote:[color=green]
> >
> > Alexander Terekhov wrote:
> >[color=darkred]
> > > Default, moral: don't mess with me. Take a hit and go away to heal
> > > your wounds. Come back and "goto moral;".[/color]
> >
> > Eh, what? Could you try that again in English? I haven't the faintest
> > idea what you are trying to say.[/color]
>
> You need to read it backwards.
>[/color]



moral goto and back come wounds your heal to away go and hit a take me
with mess don't moral Default.


Nope, that ain't helping, Al.



Brian Rodenborn