0100,0100,0100Courier NewOn 3 Mar 2001, at 14:13, David Abrahams wrote: 7F00,0000,0000> The Intel compiler is having some problems with rational.hpp which are > showing up when I try to compile the Python library. Subtraction of two > rationals is trying to go through this function instead of using the one > generated by the subtractable<<> template: > > // Reversed order operators for - and / between IntType and rational > template < > inline rational< > operator- (T i, const rational<& r) > { > IntType ii = i; // Must be able to implicitly convert T -> IntType > return rational<(ii) -= r; > } > > It seems to me that the compiler is probably in error here, but all the > same, I'm curious as to why we're not using IntType as one of the > parameters, rather than using a free T parameter. Can somebody fill me in? I'm trying to recall... Found it. Attached is the message where I described the issue. I guess there should be a comment in the code. ArialHow about // It is necessary to use a free type T for the first parameter, in order // to work around a (possible) bug in Microsoft C's implementation // of template type deduction. As this form of the code should work // correctly on any compiler, there is no need to conditionalise it // for MSVC only. Could you add this comment to CVS for me, Dave? (You have CVS access, don't you?) (The "should work correctly" comment is a bit harsh, in the light of your comments on the Intel compiler, if you can think of a better wording, or a better implementation given that the obvious one doesn't work, let me know). Courier NewPaul ---------- 0100,0100,0100On 22 Jan 2001, at 16:44, Moore, Paul wrote: 7F00,0000,0000> From: Peter Dimov [mailto:pdimov@mmltd.net] >> From: "Moore, Paul" < >> >> [...] >> >>> template < inline 7F00,0000,0000rational< >>> operator- >>> (boost::call_traits<::param_type i, >>> const rational<& r) 7F00,0000,0000>>> { >>> return rational<(i) -= r; >>> } >>> >>> The problem is that, for a user-defined integer >>> type MyInt,Arial 7F00,0000,0000Courier New>>> >>> 4 - rational<(9,2) >>> >>> doesn't compile. >> >> It's MSVC. >> >> boost::call_traits<::param_type is non- >> deducible. 7F00,0000,0000However, when faced with such a >> situation, MSVC 'creatively'7F00,0000,0000 deduces the first >> template parameter (in this case IntType) 7F00,0000,0000>> from the type of the first argument (in this case an >> int.) 7F00,0000,0000>> This is probably a hack in the compiler. > > Well, it's partly me. I should have realised that > param_type would be7F00,0000,0000 non-deducible. On the other hand, > replacing that with a simple IntType still 7F00,0000,0000> gives the error. It looks like MSVC is deducing > IntType from the first7F00,0000,0000 argument, and then complaining > about the second, instead of having another7F00,0000,0000 go by > deducing based on the second argument, and then > applying conversions7F00,0000,0000 to make the first work. > > Isn't this a specific named behaviour (something > about "partial ordering")?7F00,0000,0000 I bet there's a standard > reference (I'll look when I get home). Looks like7F00,0000,0000 it's > something else MSVC gets wrong. Maybe I'll pass it on > to David Wolfram...Arial 7F00,0000,0000Courier New> > Thanks for the help, > Paul.