[reSIProcate] Reference Counting Smart Pointer

[kenho at bluebottle.com]

I share David's view on perfomance vs. convenience issue.
The reasons I suggested to keep its usage are:
- It makes no mistake that it's from boost
- There might be a day, we would use lots of stuffs from
   boost. When that day comes (if ever), we could either import
   a release of boost to our repository or explicitly declare
   that requirement and no application code would need to be
   changed.

I personally believe, after all, maintaining utility constructs
is not to reSIProcate community's best interest towards to a
solid protocol stack. It's certainly fun to write them, but
shouldn't we spend our effort on protocol and framework such as
DUM?

Ken

david Butcher wrote:
> Kaiduan Xie's point about thread safety trumps all arguments -- the 
> semantics
> can't be the same as boost's (non-thread safe) shared pointer.
> 
> I am partial to, ahem, borrowing. Yes, code reuse in its most primitive 
> form.
> With credit, of course.
> 
> Not that I expect to get it, but I would prefer simply resip::Shared<T>.
> 'SharedPtr' smacks of Hungarian notation.
> 
> To answer the question about VOCAL's use of smart pointer versus resip 
> non-use
> of smart pointers, it was decided early on that efficiency was more 
> important
> than convenience for the resip core.
> 
> However, I am OK with smart pointers in an application framework like 
> DUM, where
> convenience can arguably be more important than efficiency, particularly 
> in a
> user endpoint.
> 
> david
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel