wilmott.com

QuoteOriginally posted by: dd3Do you really need shared_ptr? I've rarely seen a case where it's justifiably used. Usually it's down to the programmer seeing it as a silver bullet and being unable to understand the lifetimes of objects is his own software.I suppose it is an insurance policy. In a web of objects you know everything is 'OK' I suppose. Can you be 'over-insured'?However, peppering code with shared pointers makes it more difficult to read (especially with template parameters) and less portable. C++11 alias templates might offer some solace?

QuoteOriginally posted by: outrunover-insured can extra-hide bugs IMO. Instead of things crashing 100% of the time, it crashed 1% of the time.I agree.Like a HW calibrator that works for all vol except vol = 66.6%. It looks like a s/w error, but it is a model error. Putting smart ptr left, right and centre is not good IMO. SPs are not thread-safe. Probably means the code cannot be parallelized so easily.

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunover-insured can extra-hide bugs IMO. Instead of things crashing 100% of the time, it crashed 1% of the time.I agree.Like a HW calibrator that works for all vol except vol = 66.6%. It looks like a s/w error, but it is a model error. Putting smart ptr left, right and centre is not good IMO. SPs are not thread-safe. Probably means the code cannot be parallelized so easily.Good point about threads, I didn't realize that (but I've never used shared_ptr, I like accounting :d )Polter and myself on Concurrency thread had some remarks on making them thread-safe. I suppose the reference counter makes it non thread-safe. COM has exactly the same issues with AddRef(), Release() of reference count an you have to lock the count variable. I am not a compiler builder but I reckon something similar in C++11 is too late now and not desirable (locks). If you meet me in a dark lane on a Saturday night to choose between smart and raw, I would choose the latter, for parallel stuff. But boost scoped_ptr is exception safe.atomic operations in COM

yes, I like atomic. Previously you had to use silly volatiles etc. Now it is much cleaner and lightweight. What do your think of this?

how to efficiently use Shared ptr in a link list ?

I was due a reply to Cuch on this topic about changing the MSVC shared_ptr to boost to test if the debugger shows the correct types. I eventually had to do it anyway (to make it work with SWIG). But yeah, the assembler code using boost shared_ptr shows up correctly in the debug windows in visual studio. By correct I mean that the types are shown correctly and the order of constructor/destructors are also correct.w.r.t the issue with SWIG, I am exporting some c++ code to python through swig generators. Swig doesn't export all the right symbols for MSVC shared_ptr instances but works well with boost without any changes to the swig interface files. I googled the issue quite a bit but didn't come across any posts on this issue. Maybe msvc smart pointers are not supported by swig.

QuoteOriginally posted by: Cuchulainnyes, I like atomic. Previously you had to use silly volatiles etc. Now it is much cleaner and lightweight. What do your think of this?It's not great really.I'm not sure what production code would accept a lock that had :a) massive latency,b) allows for a Producer to overwrite previous items that have not yet been consumed,c) doesn't allow for clean shutdown

QuoteOriginally posted by: dd3QuoteOriginally posted by: Cuchulainnyes, I like atomic. Previously you had to use silly volatiles etc. Now it is much cleaner and lightweight. What do your think of this?It's not great really.I'm not sure what production code would accept a lock that had :a) massive latency,b) allows for a Producer to overwrite previous items that have not yet been consumed,c) doesn't allow for clean shutdownOf course. But b) and c) were not requirements. Nomally a synch queue in PPL/TBB would be used.It was to show how atomic works compared to volatile + mutex. still, it's probably a rough-and ready CV?In a barber's shop, the barber (consumer) hangs around or posts on Wilmott and reads paper when waiting for a customer (producer). look out of window.

QuoteOriginally posted by: ISayMooWhat do you think about std::shared_ptr vs boost::intrusive_ptr? The latter seems to have a smaller footprint.It's like going back to the old days of COM when you hand-crafted reference counting for each class.And the RC is not thread safe; you need atomic RC (>= C++11). Maybe for legacy systems?? BTW, why do you think it has a smaller footprint?etc.

QuoteOriginally posted by: ISayMooNo need for the control block.I understand, kindof (had a bit look and it looks complicated). Thinking out loud 1) raw pointers 2) something like Boost pool (chunking).