From: Doug Gregor (gregod_at_[hidden])
Date: 2001-05-02 21:02:07
On Wednesday 02 May 2001 07:13, you wrote:
> From: "Doug Gregor" <gregod_at_[hidden]>
> > Looks like Microsoft changed its (already incorrect) partial ordering
> > yet again.
> Heh, they never had partial ordering rules. :-)
It seems to tell the difference betwee function(const Functor) and
function(const function&), though barely...
> > The problem with:
> > function(Functor const & f)
> > is, of course, function pointers.
> There's a deeper problem here. Many compilers allow const references to
> functions (silently discarding the const since function types cannot have
> cv qualifiers) but EDG doesn't, at least EDG 2.41 that's part of Intel C++
> 5.0 doesn't - this is (arguably) correct according to the Standard. Perhaps
> this is why you define NO_PARTIAL_ORDERING for Intel (it has partial
> [Update: the online Comeau doesn't like it either.]
Only MSVC 6.0 gets the "const" because otherwise the "function(Functor)"
shadows the copy constructor. I think Comeau & Intel are correct in rejecting
the "const" for function pointers, and wouldn't be using it if it weren't
forced. Again, it's in an MSVC_INCLUDE(), so more conforming compilers won't
ever see it.
NO_PARTIAL_ORDERING is defined for Intel C++ 5.0 because of this construct:
template<typename R, typename T1>
void foo(R (*f)(T1));
void foo(const Functor &f);
Intel C++ 5.0 handles the partial ordering fine unless you try to give it a
free function with default arguments, i.e., this code will fail on Intel
because it doesn't order between the two foo() templates:
int bar(int x, int y = 2);
> > Then Functor ends up not being a pointer
> > type, so boost::function can't distinguish between a function pointer and
> > function object.
> True, but as it turns out, this at least allows me to use boost::function
> by prefixing free functions with '&' as appropriate, something that I do in
> my code anyway.
Does MSVC 7 actually handle everything if you explicitly use &? I have
nothing against documenting that people should write clearer code to make
their compiler work :).
> BTW, some of the lines in function.hpp contain fair amounts of whitespace
> at the end. :-)
Blame it on the Perl script :) I'll clean it up if it's actually a problem.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk