Re: [boost] function.hpp on MSVC 7.0

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
>
> rules
>
> > 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
> ordering.)
> [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));

template<typename Functor>
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);
foo(&bar);

>
> > Then Functor ends up not being a pointer
> > type, so boost::function can't distinguish between a function pointer and
>
> a
>
> > 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.

        Doug