On Sat, Nov 13, 2010 at 6:23 PM, Edward Diener <eldiener@tropicsoft.com>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