Re: [boost] [scope_exit] Boost.ScopeExit capturing 'this'

Subject: Re: [boost] [scope_exit] Boost.ScopeExit capturing 'this'
From: adam.butcher_at_[hidden]
Date: 2009-03-10 08:13:40

Peder Holt wrote on 10/03/2009 09:40:01:
> >
> > <snip>
> >
> > All is not lost though -- the general-purpose sizeof() based approach
> > for the other VC versions works fine for VC71 for determining the
> > typeof 'this'.  As such my patch includes a VC>=1300 specific
> > workaround for typeof 'this' determination.  This is unfortunate but I
> > couldn't think of any other non-intrusive way of doing it.
> >
> 
> The reason for using typeid instead of sizeof was to remove a limitation 
of
> the number of typeof instances you can have in a single compilation unit
> (~1000),
> but it should not not restricts the use of BOOST_TYPEOF, so I have 
reverted
> the use of typeid for BOOST_TYPEOF on VC7.1.
> It now uses the same sizeof solution as the other VC versions.
> 
I don't think that this will allow use of 'this' with BOOST_TYPEOF as is. 
I expect the following

   #include <boost/typeof/typeof.hpp>

   struct X
   {
      void f()
      {
         BOOST_TYPEOF(this) y = this;
      }
   };

would still fail due to the Microsoft bug cited earlier in this thread. It 
is to do with 'this' causing an erroneous compilation error when appearing 
inside an expression used as a template argument (even if that argument is 
only a sizeof() or typeid()).  The work-around is to store, at 
compile-time, the result of the expression involving 'this', then use that 
compile-time constant as the argument to the template.

This is why I needed to use the sizeof() approach in my ScopeExit msvc 
workaround -- as I don't know how one would 'store' the result of typeid 
(since it's the compile-time constant returned from typeid that is the 
significant value).  With sizeof() its easy, just capture the result in an 
enumerator and then use the enumerator in place of the expression.

I'm not sure how to make this generally useful for with BOOST_TYPEOF 
though since it requires a stand-alone statement to capture the type index 
(as far as I can tell).  If this is necessary, I imagine it would restrict 
usage since you wouldn't be able to use BOOST_TYPEOF() 'inline' (for 
example in a template argument list).

For BOOST_TYPEOF(this) to work on msvc (MS may fix it in vc10) I would 
imagine the msvc BOOST_TYPEOF would need to expand to something like:

   enum  { boost_typeof_local_typeindex__LINE__ = 
...expression-that-may-involve-this-to-get-type-index... };
   ...expression-using-type-index-to-get-type...

rather than

   ...expression-to-get-type...

In Boost.ScopeExit 'this capture' the specific MSVC work-around to handle 
this was to have BOOST_SCOPE_EXIT_TYPEDEF_TYPEOF_THIS start a typedef 
resulting in something like:

   enum  { boost_se_typeof_local_typeindex__LINE__ = 
...expression-involving-this-to-get-type-index... };
   typedef ...expression-using-type-index-to-get-type...

which can then be followed with whatever identifier you want to capture 
the 'typeof(this)' into.

If there is a way to combine the capture and usage into one expression 
then it'd be okay; or you could just say that msvc users are restricted to 
doing BOOST_TYPEOF(...) as a stand-alone statement.

Bring on auto and decltype!

Regards,
Adam.

------------------------------------------------------------
This email and any attached files contains company confidential information which may be legally privileged. It is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein.  If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies.  It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose.

In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel.
SELEX Communications Limited is a Private Limited Company registered in England and Wales under Company Number 964533 and whose Registered Office is Lambda House, Christopher Martin Rd, Basildon, SS14 3EL. England.