Subject: Re: [boost] [polygon] MSVC8 portability and MSVC8 bugs
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-07-06 16:25:53
Christian Henning wrote:
> Luke, I'm sure there are plenty of projects out there, including mine,
> that make heavy use of SFINAE. Although, I understand that code can
> become quite messy and hard to read, it does work fine in most of the
> cases. For instance have a look at:
> esspecially at files like detail/read_image.hpp
> 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?
> Not all is lost. ;-)
Thank you for this kind offer. The compile time logic of your code looks very similar to what I'm doing, and you do indeed have many overloads of read_image(). I'm gussing that the default argument usage of enable_if somehow gets around some of the problems I'm having with MSVC8 and 9. I'd expect that it allows the compiler to decide that the functions are not ambiguous with its cursory examination and then if SFINAE actually gets triggered in all cases the enable_if'd argument doesn't need to be provided to call the functions. I'll have to move literally hundreds of enable_if parameters from the return type to the last argument of every SFINAE protected function. However, the operator functions cannot use this mechanism, and have to use SFINAE on the return type because they are limited to only two arguments. It is likely that I cannot get them working at all in MSVC and will need to disable them with the preprocessor and provide alternative function call syntax. I may end up separating them out into optional header files since generic operators are often prone to problems.
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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk