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 17:34:00

Simonson, Lucanus J wrote:
>> If your project has a similar level of SFINAE usage, I would think we
>> could fix your code. I'm willing helping you out. Could you provide
>> minimal code that shows your problem with MSVC9?
>> 
> It looks like I have quite a bit of work ahead of me just to get my
> library compiling in MSVC9 using mpl::and_.  I'll see if I can get
> past the initial mass failures by moving the enable_if from the
> return type to the argument list so that I can determine what other
> problems I might have.    
 
It turns out I was wrong, there were only a few instances where I needed to move enable_if from the return type to a default argument to get mpl::and_ working in MSVC9 in place of gtl_and.  Also, it looks like I am able to fix most problems in MSVC8 by moving enable_if to from the return type to a default argument and it turns out that with my workaround for MSVC8 enable_if can be induced to work on the return type for the operators that require that syntax if I take care to ensure that the argument to those enable_if instantiations is always a unique template.  I only have about 40 such operator declarations, so it is reasonable to do.  The easy way is to create a unique true type that inherits from mpl::bool_<true> for each such and add it in as an extra parameter to and_.  I may be able to work around all the MSVC bugs and have the entire library compiling in MSVC8 much easier than I had feared.  I still have to touch hundreds of declarations, but it looks like all problems I'll encounter now have a proscribed solution.

Thanks, Christian, for not giving up on me,
Luke