Andreas Huber wrote:
> Hi Aleksey,
Hi Andreas,
Sorry for the late reply, got too many things on my plate.
> I've stumbled over ETI again. Browsing through MPL I have found
> different ways to circumvent it. In my case the following workaround
> seems to be sufficient:
>
> template< class State >
> struct get_context_ptr_type
> {
> typedef typename State::context_ptr_type type;
> };
>
> template<>
> struct get_context_ptr_type< int >
> {
> typedef int type;
> };
>
> I.e. by simply specializing a given metafunction with int.
Yep, in most cases that's enough. It's _always_ enough with MSVC 6.0, but
7.0 sometimes uses another, unknown, type for the instantiation's
placeholder argument, so you cannot simply specialize the template anymore,
but have to use 'is_msvc_eti_arg' predicate instead (which is based on the
knowledge that the type is still int-convertible; most probably it's an
enum), e.g.:
template< class State >
struct get_context_ptr_type_impl
{
typedef typename State::context_ptr_type type;
};
template< class State >
struct get_context_ptr_type
: if_c<
is_msvc_eti_arg<State>::value
, identity<int>
, get_context_ptr_type_impl<State>
>
{
};
> How do you decide when to use which workaround? Have you established
> rules or do you simply work your way through them until one works?
The VC 7.0-specific case is rare enough to always try the 'int'
specialization first (which is obviously less painful than the other), and
then switch to the 'is_msvc_eti_arg'-based workaround if that doesn't help.
VC 7.0 is not our production environment here at work, so I didn't have
enough experience with it to be able to figure out when exactly these cases
occur.
HTH,
Aleksey
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
