Re: [boost] call_traits/type_traits and VC6

From: Mat Marcus (mmarcus_at_[hidden])
Date: 2000-10-02 05:46:20

At 7:55 AM -0400 10/1/00, John Maddock wrote:
>Thanks to a slew of recent posts here and elsewhere regarding VC6 template
>workarounds, I've been able to get most of the type_traits library and
>hence call_traits working with VC6, in particular you can now use
>call_traits on VC6 to solve the "reference to reference" problem.

Great work. We'd been meaning to leverage our "simulated partial 
specialization" techniques to update type_traits and call_traits to 
work on VC6. Of course our employer has already cut us a fair amount 
of slack in developing and posting the initial idea, so it may taken 
us some time. We also hadn't solved the is_ref problem until David 
Abrahams recent post suggesting that the problem could be reduced to 
is_const. Anyway I'm glad to see you make use of our work. I have 
also learned some new techniques from you. The way you reduce of 
is_ref to is_const is quite elegant. I also like the trailing *const 
volatile qualifiers on your is_pointer discriminator, and the static 
T members instead of the (T*)0 casting tricks.

A couple of suggestions:

1) You probably will want to retain something like the PointerShim class below

At 3:03 PM -0700 9/29/00, Mat Marcus wrote:
>       struct PointerShim {
>          // Since the compiler only allows at most one non-trivial
>          // implicit conversion we can make use of a shim class to
>          // be sure that IsPtr below doesn't accept classes with
>          // implicit pointer conversion operators
>              PointerShim(const volatile void*); // no implementation
>          };
>
>          // These are the discriminating functions
>          char IsPtr(PointerShim); // no implementation is required
>          int IsPtr(...);          // no implementation is required

Otherwise classes with implicit conversions to pointer types  (bad 
style of course) will confuse is_ptr.
Perhaps the test suite should include something like :

struct IntegerSmartPtr{
        operator int*(); // try to confuse is_ptr
};

2) Right now is_same<int, int&>, is_ptr<int*&> return true. This 
seems undesirable. Perhaps you might make use of the is_reference 
metafunction in the implementations of the misbehaving metafunctions. 
Of course the test suite could be augmented too.

- Mat

BTW, is anyone from this list going to attend the Generative 
Programming/C++  conference in Erfurt, Germany next week?