From: Douglas Paul Gregor (gregod_at_[hidden])
Date: 2002-08-25 09:03:26
On Sun, 25 Aug 2002, John Maddock wrote:
> OK I accept that the syntax you propose is cleaner - but the lib isn't
> broken with Borland's compiler - it just needs a workaround applying in use.
I think this is a classic case of the cure being worse than the disease.
The workaround doubles the amount of effort, for what purpose?
Boost.Function still supports the numbered versions for compilers broken
in this respect, e.g.:
function2<int, int /*x*/, double /*y*/> foo;
> Seriously, almost no compilers support the syntax you are using, will anyone
> actually use boost.function or boost.signals if it just looks as though it
> is broken on all the major compilers?
EDG-based compilers are fine (tested on Comeau, SGI, Compaq, and Intel),
as are all versions of GCC from 2.95 on (check the Function tutorial in
CVS for a list of compilers that have been tested).
I think this is the case for XFAIL, or at least some form of test
annotation that can say "this test checks for a specific feature X; the
library can work without X, but you've been warned". For instance with
Boost.Function, allocator_test has always failed under MSVC but nobody
particularly cares because allocators are rarely used (in my
experience...). Now, function_test will fail on a few compilers, but it
doesn't hurt users much because they can still use the older alternative
> One other question: is the syntax you
> are using actually legal - I refer to the placement of a named parameter
> within a typename:
> boost::function<int (int, double)> // no quibbles
> boost::function<int (int a, double b)> // is this really legal?
Yeah, it's legal. 8.3.5/8 says:
"An identifier can optionally be provided as a parameter name; if
present in a function definition (8.4), it names a parameter (sometimes
called formal argument )...."
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk