"Robbie Hatley"
<loneXwolfintj@pacXbell.net.remove-Xs-include-"[ciao]"-in-subject> wrote in
message news:409b395d$1_1@127.0.0.1...[color=blue]
> "Stephen Waits" <steve@waits.net> wrote a few days ago in a message
> about putting things in lists:
>[color=green]
> > That said, perhaps you should really be doing something like this[/color][/color]
instead:[color=blue][color=green]
> >
> > 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.[/color]
>
> 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[/color]
dozens[color=blue]
>
> 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?[/color]
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.
[color=blue]
> And deallocated
> at the appropriate time?[/color]
Yes that too.
I've been worrying about that, because this construct[color=blue]
> 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[/color]
data[color=blue]
> 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[/color]
map,[color=blue]
> all should be well.[/color]
All will be well!
[color=blue]
>
> (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.)
>[/color]
Old timers.
john
