Re: [boost] [1.33.0] VC 7.1 vs. SFINAE/type traits

From: Mat Marcus (mat-boost_at_[hidden])
Date: 2005-08-17 04:48:01

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Paul,

Good to hear from you. Thanks for the reply.

- --On Wednesday, August 17, 2005 2:15 AM -0700 Paul Mensonides
<pmenso57_at_[hidden]> wrote:

>> -----Original Message-----
>> From: boost-bounces_at_[hidden] 
> 
>> So the big question is, "Is there no known way of safely 
>> testing whether a type is an anonymous enum?"
> 
> Hi Mat.
> 
> There shouldn't be a way to legally get it into a template to begin
> with. Template parameters cannot be bound to unnamed types.  In other
> words, there is no context in which you could have an anonymous enum
> without already knowing that it is anonymous.
> 
> Regards,
> Paul Mensonides
> 

Here is a simplified version of the context in which the problem seems
to crop up.

//---- operator.hpp

template <class T> 
struct is_foo {/*...*/}; // some appropriate compile time test 

template <class T>
typename boost::enable_if<boost::is_foo<T>, T>::type
operator| (T a, T b);

//---- client.cpp

#include "operator.hpp"

So far things are ok. But now suppose that I am using gcc 4.0 the
client later includes a new header system_header.hpp.

//---system_header.hpp

enum { kCaseInsenstiveMask = 1L << 1, 
       kReverseOrderMask = 1L << 2,
       kOverrideMask = 1L << 3};

enum { kTheWorks = kCaseInsenstiveMask | kReverseOrderMask |
kOverrideMask };

That is:

1) If gcc 4.0 is correct, then I currently conclude that operator.hpp
should break in the presence of system_header.hpp
2) I would like to "repair" operator| , and to make it robust in the
presence of constructs like those in system_header.hpp
3) I asked whether anonmyous enum detection was possible in support of
goal 2.

 - Mat

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.2 (Build 2424)

iQA/AwUBQwMH1BIZBaoznf65EQKzpwCgyEqGMd/EX579OT/Pbw0qpR3+rc4An2y7
C0vBBb00of44HRz7TtP33Ftv
=Wb+k
-----END PGP SIGNATURE-----