Re: [Quantlib-dev] destructor performance, observables with large observer lists

[Peter C. <pca...@vo...>]

Hi,

the main reason for the map<long,pointer> approach was to avoid using
comparison between pointers, which is to my understanding comparison of
memory addresses.

What if two objects pointed to do not stay in the same memory block for
example? Is the behaviour still well defined then? Even if it works
technically, program execution will probably depend on many things not
covered by the language specifications. It may be hard to get reproducible
results then?

Thank you and regards
Peter


-----Ursprüngliche Nachricht-----
Von: Ferdinando Ametrano [mailto:na...@am...] 
Gesendet: Sonntag, 26. Juni 2011 18:58
An: Plamen Neykov
Cc: qua...@li...; lui...@gm...
Betreff: Re: [Quantlib-dev] destructor performance, observables with large
observer lists

On Sat, Jun 25, 2011 at 5:48 PM, Plamen Neykov
<pla...@re...> wrote:
> wouldn't it be simpler just to use std::set<Observer*> and save you the
trouble with the long id or am I missing something here?

great minds think alike... as a matter of fact in the trunk it has
already been switched to std:set on June 7th :-)

see
http://quantlib.svn.sourceforge.net/viewvc/quantlib?view=revision&revision=1
7788

I was more concerned with possible non-unique elements than
destructor's performance reason, and that's why I would keep it at
std::set instead of having it as template parameter.

Roland could you confirm that the trunk solution is OK for you?

BTW in the current trunk there is a MAJOR performance improvement if
you work in a real time environment with many changing rate quotes
between recalculations: I patched a bug which triggered many useless
notifications

thanks to all for the report and help: it's refreshing to have
contributors really stressing the library.

ciao -- Nando

----------------------------------------------------------------------------
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev