On Mon, 08 Mar 2004 10:47:49 +0100, Daniel Frey wrote:
>  but that's just a wild guess. I just seem to remember that I read about 
>  the VC having a small problem there. If this is in fact the problem, we 
>  might be lucky as my newest version no longer uses this conversion, 
>  instead I use a get<T>-function.

I can reproduce this ICE on following code:

template<template <typename>  class F> struct constant
{
  template <typename T>  operator T() const
  {
    return F <T> ()();
  }
};

template <typename T>  struct map_type;

template <template<typename>  class F, typename T> struct constant_value
{
  T operator()() const
  {
    return F<typename ::map_type<T>  ::type>()();
  }
};

template <typename T>  struct pi_value : constant_value< ::pi_value, T >
{};
template <>  struct pi_value <float> {float operator()() const {return
3.14;}};

struct pi_t : constant <pi_value>  {} const pi = pi_t();

int main()
{
  const float f2 = pi;                 // ICE here
}

possibly it can be made smaller, I just finished cutting it at this
moment and sent to private MS newsgroup asking for support. Comeau and
GCC both happily accept this code, and it just looks OK. However it's
bit too complicated and I'm too tired to look into it deeper. I hope
someone from VC71 developers will now take a look. VC71 quite often
bulks on invalid code, but if this one is valid (I certainly think so)
then we have issue that have to be fixed . In the meantime if you can
come up with some variations of the above, just send an email and I will
test it. BTW: problem with operator() and VC71 is that it does not
always recognize operator() as function, in context of pointer to member
function. However it does not ICE on that problem.

Regards


B.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost