Re: [boost] compile-time partial port of bind

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-15 18:56:37

Okay, I'll do it if you'll let me steal your code and text.

Am I right that the following pattern is what triggers the ICE?

template <class UnaryMetaFunction, class T>
struct X
{
    // VC can't handle template-argument-dependent template 'apply'
    ... UnaryMetaFunction::template apply<T>::type ...;
};

And the workaround is illegal because you're not allowed to explicitly
specialize a nested template inside an unspecialized template. Right?

----- Original Message -----
From: "Mat Marcus" <mmarcus_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, December 15, 2001 6:10 PM
Subject: Re: [boost] compile-time partial port of bind

> At 5:59 PM -0500 12/15/01, David Abrahams wrote:
> >Mat, could you describe this technique in a patch for
> >
> >www.boost.org/more/microsoft_vcpp.html
> >
> >??
> >
> >I will be very glad to be able to check it into CVS.
>
> Sure, although it might take some time for me to get to it. If it's
> any help, here is a snippet describing the technique from
> <http://groups.yahoo.com/group/boost/message/20944>
>
> Mat
>
> --- Snip ---
>
>
> At 12:18 AM -0800 11/30/01, Mat Marcus wrote:
>
> This brings us to the second porting problem. This code still won't
> compile. The heinous VC "typedef dependent template parameter"
> bug. This bug is difficult to describe but I will give it a brief
> try. The code above:
>
>       MetaFunctionWrapper::template Result<AtomicType>::type
>
> fails to compile. But other similar expressions succeed. Success seems
> to occur in the cases when the outer class is not a template
> parameter. There are a couple of workarounds for this but they are not
> legal C++. Aleksey has encapsulated one of these in ::boost::mpl as
> the BOOST_MPL_DEPENDENT_TEMPLATE_TYPEDEF macro. (Actually, the macro
> needs a slight modification to work here: the last parameter must be
> eliminated.). So we replace the above line of code with:
>
>       BOOST_MPL_DEPENDENT_TEMPLATE_TYPEDEF(MetaFunctionWrapper, \
> Result, AtomicType)
>
> This is admittedly ugly, but at least it only appears in the
> implementation, not the client code. Many of us don't like macros too
> much. We can do a little better by burying this hack away inside
> another metafunction, let's call it Apply. That is:
>
> template <class MetaFunctionWrapper, class T>
> struct Apply
> {
> #ifdef BOOST_MSVC
>   // based on the (non-conforming) MSVC trick from MPL
>
>   template<bool>
>   struct MetaFunctionWrapper_VC : MetaFunctionWrapper {};
>
>   file://illegal C++ which causes VC to admit that MetaFunctionWrapper_VC
>   file://can have a nested template:
>
>   template<>
>   struct MetaFunctionWrapper_VC<true>
>   {template<class> struct Result; };
>
>   typedef typename MetaFunctionWrapper_VC<
>     ::boost::mpl::detail::msvc_never_true<MetaFunctionWrapper>::value
>     >::template Result<T>::type type;
>   };
> #else
>    typedef typename MetaFunctionWrapper::template Result<T>::type type;
> #endif
> };
>
>
>
> Then the offending code:
>
> template <class AtomicType, class MetaFunctionWrapper>
> class GenScatterHierarchy : public
>        MetaFunctionWrapper::template Result<AtomicType>::type
> {
> };
>
> becomes:
>
> template <class AtomicType, class MetaFunctionWrapper>
> class GenScatterHierarchy : public
>    typename Apply<MetaFunctionWrapper, AtomicType>::type
> {
> };
>
>
> Info: http://www.boost.org  Send unsubscribe requests to:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>