Re: [boost] [polygon] MSVC8 portability and MSVC8 bugs

Subject: Re: [boost] [polygon] MSVC8 portability and MSVC8 bugs
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-07-06 14:47:29

Christian Henning wrote:
> The following compiles and uses mpl::and_. Your problem is very
> similar to a problem I once had. Steven Watanabe was able to fix by
> just leaving out the ::type references. For instance

I tried replacing gtl_and and gtl_yes/no everywhere with mpl::bool_ and mpl::and_ and I get compile errors in MSVC9.  I have managed to work around bugs in MSVC9 with the way I have implemented gtl_and to return false by default and return true only in the case where I want the template to instantiate.  Because gtl_and_ has a complex default case MSVC9 incorrectly makes assumptions when optimizing its instantiation of multiple templates that cause it to ignore the SFINAE behavior I want under certain circumstances.  I don't fully understand what those circumstances are, but it is similar to the problems in MSVC8 where simple SFINAE tests work, but realistic code breaks down.  I don't believe it is feasible for me to use mpl::and_ and support even MSVC9.  

At this point I feel that the prospects for ever supporting MSVC8 are very dim.  SFINAE just doesn't work in MSVC well enough to use it to overload large numbers of generic functions.  This is why Barend and Bruno abandoned SFINAE, support for it in MSVC is so bad (inconsistent) it might as well not exist at all.  Porting my code to MSVC9 was extremely difficult and consumed several weeks for sustained (including overtime) effort.  If I would port to MSVC8 in 120 hours of programming effort comparable to what the port to MSVC9 took I might consider it, but I have no assurance that after 120 hour I would have SFINAE based code that works in MSVC8.  Since generic operators require SFINAE to not side swipe the stl and operator calls on enum types I have to use SFINAE, so changing to tag dispatching with static assert is not an option unless I defeature the operators.  I don't think supporting MSVC8 warrents re-writing the entire set of interfaces including defeaturing a significant number of them.

Regards,
Luke