Re: [boost] Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)

Subject: Re: [boost] Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2010-11-13 21:14:04

On Sat, Nov 13, 2010 at 6:23 PM, Edward Diener <eldiener_at_[hidden]>wrote:
>
> What is the necessary C++0x support needed for Boost.Generic and
> Boost.Auto_Function ? What compilers currently provide that support ? I am
> guessing that to replace BCCL a compiler that largely supports C++0x is
> needed and that there may not be many right now that do. That is not meant
> to be discouraging at all but it needs to be denoted in the docs what
> current compiler(s) can be used.
>

I thought I had a note in the docs, but I may have forgotten. I'll be sure
to add more detailed information about that. Right now I am only testing it
with GCC 4.5.1 and it can only handle a subset of features, albeit a subset
large enough to not sacrifice much functionality. So GCC 4.5.1 is the only
compiler I personally know of that can support it in any way at all. I know
I have a list of some of the 0x features required in the support section of
the docs, though it is not complete. If whatever compiler you are testing
with supports such features, you're more than welcome to give it a try,
though I'm a bit pessimistic. With respect to Boost.Auto_Function, "do"
arguments aren't supported yet in GCC since it can't yet fully handle
lambdas in the way I'm using them (inside a decltype in a trailing return
type). For the same reason, Boost.Generic "for" arguments can't be
supported, though given that I don't even have an implementation of
Boost.Generic up on the sandbox yet that's sort of a moot point.

If you are looking to use the libraries in practice, I'd hold off on that,
though I encourage you to play around with Boost.Auto_Function in GCC if you
want. I'm more putting work into these libraries now in the hope that soon
more compilers will be able to handle them. The majority of this work is
sort of theoretical.

That said, if you play around with Boost.Auto_Function keep in mind that it
is in a state that will be changed shortly -- the "if" family of arguments
will soon have their predicates be the variadic macro equivalent of
Boost.Preprocessor sequences. All of the arguments passed this way are
"anded" together. This is particularly useful when some of your predicates
are values and others are types, since you don't have to manually combine
them with && or mpl::and_. It also makes the to-be-implemented "break if"
construct, as mentioned in the future direction section, able to report more
fine-grained errors. This change also has the side-effect that I can make
the parameter IDs "if" and "if not" instead of "if" and "not", for reasons
I'm sure no one cares about other than people in the business of making
crazy macro hacks, which I'd imagine is a small subset of programmers even
in the Boost community.

With this thread I'm mostly hoping that others who are keen on the standard
will be able provide some suggestions concerning the problems mentioned in
my first post. Anyone with ideas for features are also more than welcome.
I'm just worried that the problems already mentioned may prove to be road
blocks, though I'm not tossing my hands up yet.

-- 
-Matt Calabrese