[boost] [vault] ctor_shared_from_this()

From: Robert Sitton (robert.sitton_at_[hidden])
Date: 2007-12-17 10:48:44

I've posted a modification to enable_shared_from_this() to support
calling shared_from_this in a constructor and destructor.  d

Any feedback?

Abrahams) 16. Re: Trac open bug summary  mailings missing new tickets
(Rene Rivera) 17. BoostCon 2008: May 4-9  (David Abrahams) 18. Re:
Reporting bugs at Trac?  (Olaf van der Spek) 19. Re: [serialization]
serialization used in multiple DLL problems (Felipe Magno de  Almeida)
20. [review] Formal Fast-Track  review of the Boost.Functional/Factory
library  begins today (John Torjo) Michael Marcin wrote: > John Torjo
wrote: >> Eames, Andrew wrote: >>> Hi, >>> >>> I apologize if this is
a FAQ -  I couldn't find much on other  compilers >>> >>> >>> >>> I am
interested in using  boost with a compiler for a DSP  - The compiler
>>> is somewhat archaic - I'm  not using RTTI or exceptions  (the
compiler >>> supports them but it is  currently broken) - the STL has
old iostreams >>> and no doubt I will find  some other musty corners.
I  don't have any >>> illusions about getting the  whole of boost to
compile but  I'm sure there >>> are some large pieces that  will work
OK. I have no problem  doing the >>> port myself. >>> >>> >>> >> RTTI
is pretty useful, and I  think quite a few libraries rely on >>
dynamic_cast at least once. >> >> For instance Boost Logging  Lib (
http://torjo.com/log2/)  relies on it >> once - I guess you could get
'round it. >> >> I guess the 1M$ question is :  why do you need that
specific  compiler? >> > > I'm in a similar situation where  I have to
use a specific compiler > because it's the only compiler  supported by
the closed SDK for  the > platform we're developing for. > > Right now
I, unfortunately, can  only use the Torjo logging library  for a >
windows port of the  application because the target  platform doesn't
> support RTTI (exceptions are  fine). This is annoying because  the >
debuggers for these  embedded devices are  sometimes flaky and logging
on > device is sometimes the only  way to fix bugs. So we have to
have another > simple homegrown logging  library for on device
logging. > > There are many other Boost  libraries that we can't use,
at  least out of > the box, because they use  RTTI in one or two
places where  they probably > don't have to. For instance
lexical_cast uses it to provide  extra > information to the
bad_lexical_cast exception but  functions just fine > without it. I
didn't dig enough  into the implementation but it  looks > like
Boost.Function and  Boost.Variant may be in a similar  boat. > > I
think shared_ptr used to  have this issue but got changed  after 1.34.
I > wish more libraries would  follow its lead if possible.  You can
raise the viability of the  issue by submitting patches.  Where RTTI
is useful, but not  essential, I'd personally rather  not remove it
entirely. Instead, the  code could respond to a macro (BOOST_NO_RTTI
perhaps) and  avoid usage when present. But  the default would be to
user RTTI on the  theory it is usually available.  --Beman  Beman
Dawes:  > Where RTTI is useful, but not  essential, I'd personally
rather  not > remove it entirely. Instead, the  code could respond to
a macro > (BOOST_NO_RTTI perhaps) and  avoid usage when present.  In
non-essential scenarios,  often the proper macro to test  is
BOOST_NO_TYPEID:   http://svn.boost.org/trac/boost/ ticket/1104  since
typeid(T) does not require  the R in RTTI and may be  supported even
when RTTI is off (under MSVC  for example).  Joaquin M Lopez Munoz
skrev: > Thorsten Ottosen  <thorsten.ottosen <at>  dezide.com> writes:
 >> I would use it as a  lightweight and more convenient  replacement
for >> boost::shared_ptr<const T>. >> >> In my application I might
have < 50 objects that needs to  by flyweights.  >> They are almost
never  identical, and if they are, the  memory occupied by >> the
factory would probably  be much larger than that of  duplication. > >
Well, then you might not need  using the flyweight idiom > after
all...  Well, it's lower overhead (if no  factory and forwarding
constructors/operations makes  it a better choice than
shared_ptrconst T>.  -Thorsten  Thorsten Ottosen:  > Joaquin M Lopez
Munoz skrev: >> Thorsten Ottosen  <thorsten.ottosen <at>  dezide.com>
writes: > >>> I would use it as a  lightweight and more convenient
replacement for >>> boost::shared_ptr<const T>. >>> >>> In my
application I might  have < 50 objects that needs to  by flyweights.
>>> They are almost never  identical, and if they are, the  memory
occupied by >>> the factory would probably  be much larger than that
of  duplication. >> >> Well, then you might not need  using the
flyweight idiom >> after all... > > Well, it's lower overhead (if no
factory and forwarding > constructors/operations  makes it a better
choice than  shared_ptrconst T>.  It might be possible to do this
using a custom factory along  the lines of:  template<class T> struct
sp_factory { typedef boost::shared_ptr<T  const> handle_type;
handle_type insert( T const & t  ) { return handle_type( new T( t  )
); } void erase( handle_type ) {} T const & entry( handle_type p )  {
return *p; } };  but there's no way to tell from  the documentation;
it never  describes how the Factory template parameter  is actually
used.   http://svn.boost.org/svn/boost/
sandbox/flyweight/libs/flyweight/ doc/reference/flyweight.html#fly
weight  As I read it, a flyweight<> can  ignore all of its template
parameters beyond T and still conform to its spec,  which is probably
not what's  intended.  Peter Dimov wrote: > Beman Dawes: > >> Where
RTTI is useful, but not  essential, I'd personally rather  not >>
remove it entirely. Instead,  the code could respond to a  macro >>
(BOOST_NO_RTTI perhaps)  and avoid usage when present. > > In
non-essential scenarios,  often the proper macro to test  is >
BOOST_NO_TYPEID: > > http://svn.boost.org/trac/boost/ ticket/1104 > >
since typeid(T) does not  require the R in RTTI and may be  supported
even > when RTTI is off (under MSVC  for example).  Good point.
--Beman  There's a file called  'madshell.phtml' in the Vault that  is
probably an exploit. I see a few other  .phtml's as well.  -- Peter
Dimov  http://www.pdimov.com  >>> So you can call it whatever  you
like and still be right :-) >>> >>> BTW I believe the min and  max
cases are basically just  mirror >>> images of each >>> other about
the location  parameter? >> >> So names aside, it's all the  extreme
value distribution, but  there >> are minimum and maximum  variations
of it.  I found this... It was a nice  overview of some of the
distribution. Section 1.2 has a nice overview  of the type 1, 2 and 3
distributions and how they relate (and how  they're related to
Weibull, for example). I wonder if I can find  this book in our math
library...   http://www.worldscibooks.com/ mathematics/p191.html
Andrew Sutton asutton_at_[hidden]  Peter Dimov wrote: > There's a file
called  'madshell.phtml' in the Vault that  is probably an > exploit.
I see a few other  .phtml's as well.  Thanks for pointing those out.
I've adjusted the cleanup filter  accordingly.  -- -- Grafik - Don't
Assume Anything -- Redshift Software, Inc. -
http://redshift-software.com -- rrivera/acm.org -
grafik/redshift-software.com -- 102708583/icq -  grafikrobot/aim -
grafikrobot/yahoo  More about   http://svn.boost.org/svn/boost/
sandbox/flyweight/libs/flyweight/ doc/reference/flyweight.html#fly
weight  I don't understand the source of  the complexity at the
flyweight<> level. A "naive" flyweight<> could look  like:
template<class T, class F =  default_factory> class flyweight {
typedef typename F::handle_type  handle_type; handle_type handle_;
public:  flyweight( ... args ): handle_(  F::insert( T( args... ) ) )
{} T const& get() const { return  F::value( handle_ ); } };  It seems
to me that this  provides the same amount of  expressive power as the
current interface.  Locking/tracking/holding can be  made parameters
of the Factory if so desired, and a  factory_core<F',L,T,H> template
may be provided as a convenience in a separate  header, but in the
majority of  the cases the user will never need it.  In fact
flyweight<> is already  implemented in a similar way, it  uses a
flyweight_core<> class as F.  Note that the above simpler  flyweight<>
allows me to pass  the aforementioned  template<class T> struct
sp_factory { typedef boost::shared_ptr<T  const> handle_type;  static
handle_type insert( T  const & t ) { return handle_type(  new T( t )
); } static T const & entry(  handle_type p ) { return *p; } };  as F;
there's no need to invent a  locking policy, a tracking policy,  a
holder, or a stateful factory.  ----- Mensaje original ----- De: Peter
Dimov  <pdimov_at_[hidden]> Fecha: Domingo, Diciembre 16,  2007 8:27 pm
Asunto: Re: [boost] [flyweight]  some minor comments Para:
boost_at_[hidden]  > Thorsten Ottosen: > > Well, it's lower
overhead (if  no factory and forwarding > > constructors/operations
makes it a better choice than > shared_ptrconst T>. > > It might be
possible to do this  using a custom factory along  the > lines of: > >
template<class T> struct  sp_factory > { > typedef boost::shared_ptr<T
 const> handle_type; > > handle_type insert( T const &  t ) { > return
handle_type( new T( t )  ); } > void erase( handle_type ) {} > T const
& entry( handle_type  p ) { return *p; } > };  This approach would
work  (except for a technical issue I  comment later) but it's
overkill because it  provides its own tracking, which is already taken
care of  by the Tracking policy. One would use then in conjunction
with the no_tracking and no_locking policies, sort of like  this:
template<class T> using  no_factory_flyweight=
flyweight<T,sp_factory<_1,_2>,n o_tracking,no_locking>;  An
alternative would be to  provide an even simpler factory:
template<typename  Entry,typename Value> struct trivial_factory {
typedef const Entry*  handle_type; handle_type insert(const Entry&
x){return new Entry(x);} void erase(handle_type p){delete  p;} const
Entry& entry(handle_type  p){delete p;} };  // default tracking is
ref_counted template<class T> using  no_factory_flyweight=
flyweight<T,trivial_factory<_1,_2 >,no_locking>;  Either of these two
alternatives  *almost* works, but for a detail: equality of flyweight
objects is defined in terms of equality of reference, i.e.  x==y iff
&x.get()==&y.get(). sp_factory (and trivial_factory)  interpret every
value as distinct for any other:  no_factory_flyweight<std:string>
x("hello"), y("hello"); assert(x!=y); //assertion passes  which
results in no value  sharing, except when a flyweight is copied from
another.  Nothing wrong with this as long as it is known and
accepted, of course.  > bu  ... This message is too long, the  rest is
truncated.

On 12/17/07, boost-request_at_[hidden]
<boost-request_at_[hidden]> wrote:
> Send Boost mailing list submissions to
> 	boost_at_[hidden]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.boost.org/mailman/listinfo.cgi/boost
> or, via email, send a message with subject or body 'help' to
> 	boost-request_at_[hidden]
>
> You can reach the person managing the list at
> 	boost-owner_at_[hidden]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Boost digest..."
>