469,623 Members | 1,543 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,623 developers. It's quick & easy.

using list

For some "new" created objects of class A with pointers, how to put them
into a list, list<class A> l?

p1 = new A();
p2 = new A();
P3 = new A();
....

Thank you very much!



Jul 22 '05 #1
4 1342
"Stephen Waits" <st***@waits.net> wrote a few days ago in a message
about putting things in lists:
That said, perhaps you should really be doing something like this instead:

std::list<A> listA;
listA.push_back( A() );

Here we're pushing back a temporary element that we're constructing on
the stack. A copy is made and inserted into the list. Now the list
deals with the heap for you.


I've been wondering about that. I've got an application at work for a
map of structs which contain deques. A bit cumbersome of a construct,
and yet very useful:

struct TempHumData
{
time_t TimeStamp;
double Temp;
double Hum;
}

struct ZoneRTData
{
deque<TempHumData> TempHumDeque;
bool Disable;
}

map<unsigned long int, ZoneRTData> ZoneMap;

unsigned long int ZID = 3702; // separate id # for each zone; can be dozens

ZoneMap.insert(make_pair(ZID, ZoneRTData()));

So you're saying that even when I let the ZoneRTData implicit default
constructor create a new, unnamed object (which would chain to the
implicit default constructor for deque<TempHumData>), and when I let
make_pair() dynamically create a new, unnamed pair, and then store the
pair in a map, the memory will all be handled automatically? And deallocated
at the appropriate time? I've been worrying about that, because this construct
may hold a lot of data (megabytes), and memory leaks would be disastrous.
(It's a program that may run for months without being shut down, so leaks
would accumulate rapidly.)

I realize some aspects will have to be handled manually (eg, purge old data
from deques to keep size down); but as long as the memory is actually
free'd when items are pop'ed from deques or zones are erase'd from the map,
all should be well.

(I've co-workers who'd rather write it all in C and handle the memory
manually with malloc and free. I'm trying to convince them my way
is better.)

--
Cheers,
Robbie Hatley
Tustin, CA, USA
email: lonewolfintj at pacbell dot net
web: home dot pacbell dot net slant earnur slant


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Jul 22 '05 #2

"Robbie Hatley"
<lo***********@pacXbell.net.remove-Xs-include-"[ciao]"-in-subject> wrote in
message news:40**********@127.0.0.1...
"Stephen Waits" <st***@waits.net> wrote a few days ago in a message
about putting things in lists:
That said, perhaps you should really be doing something like this instead:
std::list<A> listA;
listA.push_back( A() );

Here we're pushing back a temporary element that we're constructing on
the stack. A copy is made and inserted into the list. Now the list
deals with the heap for you.
I've been wondering about that. I've got an application at work for a
map of structs which contain deques. A bit cumbersome of a construct,
and yet very useful:

struct TempHumData
{
time_t TimeStamp;
double Temp;
double Hum;
}

struct ZoneRTData
{
deque<TempHumData> TempHumDeque;
bool Disable;
}

map<unsigned long int, ZoneRTData> ZoneMap;

unsigned long int ZID = 3702; // separate id # for each zone; can be

dozens
ZoneMap.insert(make_pair(ZID, ZoneRTData()));

So you're saying that even when I let the ZoneRTData implicit default
constructor create a new, unnamed object (which would chain to the
implicit default constructor for deque<TempHumData>), and when I let
make_pair() dynamically create a new, unnamed pair, and then store the
pair in a map, the memory will all be handled automatically?
Yes. But I'd quibble about your terminology. make_pair does not create
anything dynamically, that would imply use of new, which make_pair does not
use.
And deallocated
at the appropriate time?
Yes that too.

I've been worrying about that, because this construct may hold a lot of data (megabytes), and memory leaks would be disastrous.
(It's a program that may run for months without being shut down, so leaks
would accumulate rapidly.)

I realize some aspects will have to be handled manually (eg, purge old data from deques to keep size down); but as long as the memory is actually
free'd when items are pop'ed from deques or zones are erase'd from the map, all should be well.
All will be well!

(I've co-workers who'd rather write it all in C and handle the memory
manually with malloc and free. I'm trying to convince them my way
is better.)


Old timers.

john
Jul 22 '05 #3

"John Harrison" <jo*************@hotmail.com> wrote in message news:2g************@uni-berlin.de...
(answers to my fears re. memory leaks)
Thanks for the clarification.
... Yes. But I'd quibble about your terminology. make_pair does not create
anything dynamically, that would imply use of new, which make_pair does not
use....


Ah, you mean "dynamically" in the sense of creating objects which still
exist after the code that created them goes out of scope:

void Dweevil (unsigned check)
{
double * Qbert = new unsigned double;
... (hundreds of lines of code) ...
return;
} // leave scope
// Oops! Forgot to delete Qbert ! Memory leak!

I meant "dynamic", however, in the sense of not specifying in advance
how many objects will be created or what their names will be.

This is the kind of thing I'd call "pseudo-dynamic":

struct Glurk
{
char broil;
long shot;
}
void Bard (double bubble)
{
list<Glurk> Grendel;
if (bubble > 19.7)
{
Grendel.push_back(Glurk()); // pseudo-dynamically create new Glurk
}
... (hundreds of lines of code) ...
return;
} // leave scope, free memory.

This can be a very useful concept, I'm beginning to see.

--
Cheers,
Robbie Hatley
Tustin, CA, USA
email: lonewolfintj at pacbell dot net
web: home dot pacbell dot net slant earnur slant

----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Jul 22 '05 #4

"Robbie Hatley"
<lo***********@pacXbell.net.remove-Xs-include-"[ciao]"-in-subject> wrote in
message news:40********@127.0.0.1...

"John Harrison" <jo*************@hotmail.com> wrote in message news:2g************@uni-berlin.de...
(answers to my fears re. memory leaks)
Thanks for the clarification.
... Yes. But I'd quibble about your terminology. make_pair does not create anything dynamically, that would imply use of new, which make_pair does not use....


Ah, you mean "dynamically" in the sense of creating objects which still
exist after the code that created them goes out of scope:


Right.

[snip]

This is the kind of thing I'd call "pseudo-dynamic":

struct Glurk
{
char broil;
long shot;
}
void Bard (double bubble)
{
list<Glurk> Grendel;
if (bubble > 19.7)
{
Grendel.push_back(Glurk()); // pseudo-dynamically create new Glurk
}
... (hundreds of lines of code) ...
return;
} // leave scope, free memory.

This can be a very useful concept, I'm beginning to see.


What you are calling pseudo-dynamic objects are one example of what the C++
standard calls temporaries.

Note that in your code the temporary Glurk() it not destroyed when you exit
Bard, its destroyed at the end of the statement on which it is created. What
goes into Grendel is a copy of that temporary, and it lives until it is
removed from the list or the list is destroyed.

john

Jul 22 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Random Person | last post: by
1 post views Thread by Daveyk0 | last post: by
3 posts views Thread by chellappa | last post: by
6 posts views Thread by Julia | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.