< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Reference Counting Smart Pointer


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@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel