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