Re: [boost] [config] polygon library long long, long double portability

Subject: Re: [boost] [config] polygon library long long, long double portability
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-07-01 13:52:59

Mateusz Loskot wrote:

>> I fully
>> intend to attempt back porting to MSVC8 and I tried to make that
>> clear when I asked if anyone had words of wisdom to offer me before I
>> set out to do just that.
> 
> There is no general wisdom of Visual C++ 8.0. The only I can recommend
> is to try to build and walk through errors fixing them.

Ok, so I think I know why I was happy to get away from MSVC8.  SFINAE just isn't working for me in MSVC8--I get a duplicate definition error for practically every overload of generic functions.  The two function declarations below are an example.  They differ by conceptual type exected (and checked with compile time SFINAE logic) for the second argument.  Fixing such a syntax error is not straightforward since the syntax error is due to the failure of the compiler to support the language feature.  Only though trial and error experimenting with the quirks of MSVC8 wrt SFINAE can I potentially come up with an alternative syntax which the compiler will accept.  Since the standard cannot guide me I can draw only on my own experience of MSVC (which is that default metafunction return values seem to play an important role in when and how the compiler fails to the the right thing, as does whether the template is parameterized by a type or by a literal value) and the experience of the rest of the boost community.  For example, enable_if uses enable_if_c which is parameterized by a literal constant, which works around a bug in the way SFINAE works in complicated template instantiations.

  // enlarge rectangle to encompass the point b
  template <typename rectangle_type_1, typename point_type>
  typename enable_if<
    typename gtl_and< typename is_mutable_rectangle_concept<typename geometry_concept<rectangle_type_1>::type>::type,
                      typename is_point_concept<typename geometry_concept<point_type>::type>::type>::type,
    bool>::type 
  encompass(rectangle_type_1& rectangle, const point_type& b)

  template <typename rectangle_type_1, typename rectangle_type_2>
  typename enable_if< typename gtl_and<
    typename is_mutable_rectangle_concept<typename geometry_concept<rectangle_type_1>::type>::type,
    typename is_rectangle_concept<typename geometry_concept<rectangle_type_2>::type>::type>::type,
                       bool>::type 
  encompass(rectangle_type_1& rectangle, const rectangle_type_2& b)

Currently gtl_and looks like this:

  template <typename T, typename T2>
  struct gtl_and { typedef gtl_no type; };
  template <typename T>
  struct gtl_and<T, T> { typedef T type; };
  
I changed it to this:

  template <bool larg, bool rarg>
  struct gtl_and_c { typedef gtl_no type; };
  template <>
  struct gtl_and_c<true, true> { typedef gtl_yes type; };
  template <typename T, typename T2>
  struct gtl_and : gtl_and_c<T::value, T2::value> {};

But that didn't help MSVC8 do the right thing.  It seems MSVC8 assumes both templates can be instantiated without performing the compile time logic or invoking SFINAE and I don't know how to trick it into doing the right thing.

I'd be happy to switch from my own logic metafunctions to something in boost::mpl, especially if it improves portability.  It was already on my todo list.  I don't believe that will fix my problems with MSVC8, however.

Does someone know what specifically is different between MSVC8 and MSVC9 wrt. SFINAE conformance?  I am shooting in the dark to reverse engineer the bugs in the compiler that were fixed between MSVC8 and 9.  There is a good chance that my library won't get backported to MSVC8 without some guidance from the community.

There is apparently another problem with MSVC8 that enums are less typesafe than in MSVC9--an integral literal constant is assumed to be potentially the same type as an enum value for the purposes of template matching, which is wrong and breaks my code in numerous places as well.  This issue I can more easily handle myself.

Does lack of backward compatibility to MSVC8 (and obviously MSVC7.1) constitute a strong argument against acceptance of a library that would not likely make it into a release of boost until 2010?  By that time Visual Studio 2005 will be two major releases behind the current MS compiler version.  Do we really let compiler bugs in five year old versions of a major compiler dictate to us what features of the language we are allowed to use in boost for new libraries?

Regards,
Luke