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 firstublic base{};
class secondublic base{};
class thirdublic base{};
class container
{
private:vector<base*>b;
public:container()
{
b.push_back(new first);
b.push_back(new second);
b.push_back(new third);
}
//?? public:virtual ~container(){for_each(b.begin(),b.end(),delete);}
};
int main(int argc,char**argv)
{
container c;
return 0;
}

 

[Blake Kaplan]

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? [snip]
//?? public:virtual ~container(){for_each(b.begin(),b.end(),delete);}

[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.begin(), b.end(), delete<base>()); }

 

[Cy Edmunds]

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 firstublic base{};
class secondublic base{};
class thirdublic base{};
class container
{
private:vector<base*>b;
public:container()
{
b.push_back(new first);
b.push_back(new second);
b.push_back(new third);
}
//?? public:virtual ~container(){for_each(b.begin(),b.end(),delete);}
};
int main(int argc,char**argv)
{
container c;
return 0;
}

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

class container
{

public:
typedef boost::shared_ptr<base> t_pbase;
private:
vector<t_pbase>b;
public:
container()
{
b.push_back(t_pbase(new first));
b.push_back(t_pbase(new second));
b.push_back(t_pbase(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.

 

[Thomas Gulbrandsen]

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? [snip]
//?? public:virtual ~container(){for_each(b.begin(),b.end(),delete);}

[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.begin(), b.end(), delete<base>()); }

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

and

virtual ~container(){std::for_each(b.begin(), b.end() , delete_pointer());}

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

-Thomas Gulbrandsen

 

[Peter Gregory]

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

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]

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

#include <iostream>
#include <string>
#include <set>
#include <boost\shared_ptr.hpp>
void print_smart_ptr(const boost::shared_ptr<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_ptr<std::string> smart_ptr(new std::string("smart_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("smart_ptr_reset"));
print_smart_ptr(smart_ptr);

//swap smart_ptr
boost::shared_ptr<std::string> swap(new std::string("swaped"));
smart_ptr.swap(swap);
print_smart_ptr(smart_ptr);

return 0;
}

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

Go to this link for more info
http://www.boost.org/libs/smart_ptr/shared_ptr.htm

-Thomas Gulbrandsen

 

[John Harrison]

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

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]

#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

 

[Howard Hinnant]

| 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:

| 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

| 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

| 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

| "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

| David White wrote:
| >
| > | > > 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. (e-mail address removed)-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

| 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

 

[Alexander Terekhov]

Howard Hinnant wrote:
[...]

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

| Alexander Terekhov wrote: .....

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]

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.

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]

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

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




Brian Rodenborn

 

[Default User]

I'd say the moral is "don't mess with Howard." His rebuttal was a
masterpiece.

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]

You need to read it backwards.

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

 

[Howard Hinnant]

| 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.

 

[Default User]

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

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

I know, I saw that. The Boost site itself just says it's in work.

<sigh> When a major C++ library testing ground is off topic in
comp.lang.c++, something, somewhere has gone wrong.

I never said it was completely off-topic. My point was that it isn't (or
wasn't in the past) standard. Discussing the Boost libraries, and their
progress, features etc. would be fine as they themselves are written in
standard C++. However, recommending Boost solutions to problems posted
here need to at LEAST have the caveat that these features are part of a
third-party libary.

And I'm sorry I picked on you.

I don't feel picked on.

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.

I'm sorry, but I can't agree with that. Newsgroup topicality is
important. If more people thought about it before posting, then
reminders/cluesticks/topic-fascism wouldn't be necessary. I know my good
buddy Al will find it hard to pass up this post!

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

Nope. That's not how it works. That's the formula for a newsgroup to
dissolve into chaos.

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.

Ok, so I'm still right, at least for the time being

| 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.

I think I explained this before, but third-party solutions work well in
some cases, but projects that are limited to standard C++ or standard
with approved extensions, can't just slurp up a library the developer
happens to find shiny. If I wanted to use Boost, I'd have to find some
way to get it peer-reviewed and approved here. Similarly, if I were an
instructor and someone did their homework using Boost I'd mark them down
heavily.

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.

Boost in general seems to get a pretty good pass here, I guess except
for me now. I've had my say on the matter, I think topicality is good,
and I think there are aspects of Boost that make it more topical than
say MFC.




Brian Rodenborn

 

[Tom]

When a major C++ library testing ground is off topic in
comp.lang.c++, something, somewhere has gone wrong.

Hear, hear. Well put. And thank you.

Best regards,

Tom

 

[Michiel Salters]

I've searched the C++ standard, and I fail to find this header. Please
don't recommend nonstandard, off-topic solutions.

It may not be in the standard, but that doesn't make it nonstandard.
boost/shared_ptr.hpp is a source file suited for inclusion (16.2/1)
containing standard C++ code (and certainly with a C++ interface).
Discussing and evaluating C++ code, from whatever source, is on
topic here.

Even if you're not allowed to use third-party solutions, boost can
be used to pick up some good ideas.

Regards,

 

[Alexander Terekhov]

Default User wrote:
[...]

I'm sorry, but I can't agree with that. Newsgroup topicality is
important. If more people thought about it before posting, then
reminders/cluesticks/topic-fascism wouldn't be necessary. I know my good
buddy Al will find it hard to pass up this post!

You were defeated by Howard, my friend.

regards,
alexander.

P.S. Chaos is Good. Moderation sucks.

P.P.S. Howard, please convey my "BOO" to Abrahams.

 

[Default User]

But one that is easily available and widely portable. And in addition they
seem to have the ear of the standards committee.

I'm aware of that.

I've never considered the topic of this NG to be the standard C++ language.
It is things that are of interest to all C++ programmers. Smart pointers
certainly qualify, and boost have a reasonable implementation.

That's obvious, but it's at odds with most other participants (except Al
of course).



Brian Rodenborn