
The Boost.MPI library is now available in Boost CVS. We are still working on some aspects of the library, addressing review comments, updating documentation, and ramping up testing. However, at this time the library is usable and should be relatively stable. Cheers, Doug

Hi Doug, That's great. I'll update the formal review schedule to indicate this. Cheers, ron On Dec 12, 2006, at 10:45 AM, Douglas Gregor wrote:
The Boost.MPI library is now available in Boost CVS.
We are still working on some aspects of the library, addressing review comments, updating documentation, and ramping up testing. However, at this time the library is usable and should be relatively stable.
Cheers, Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost

"Steven Watanabe " wrote:
Do you intend to make boost::any a typedef then?
That would do it unless there is some non-obvious ambiguity that this may cause.
Meaning boost::apply_visitor(printer, a) I assume?
Yep but an apply_visitor function isn't reallly necessary.
Do you mean
struct deref_print : boost::dynamic_visitor<std::vector<int>::const_iterator> { void operator()(std::vector<int>::const_iterator iter) const { std::cout << *iter; } };
std::vector<int> v(1); boost::any a = v.begin(); boost::apply_visitor(deref_print(), a);
Basically what i meant was you have 4 cases of: cosntant visitor visits constant and non-constant visitee non-constant visitor visits constant and non-constant visitee constant visitee accepts cosntant & non-constant visitor non-constant visitee accepts cosntant & non-constant visitor
For this last I don't think there is a good non-intrusive solution.
Are you talking about the complete solution or catch-all part? i don't see exactly how this is an intrusive solution so please elaborate/clarify.
If the default is to throw an exception then it effectively limits the contained type to those enumerated. In this case it is probably better to use variant in the first place.
I don't see what the problem is since a user can override the default or later extend there original visitor to support new (set) type(s), as well as override the definition of the old supported types if he/she wishes. This solution seems to be much better than type casting (for every type wanted) & type switching code that you have to do with boost::any::. If no one likes the idea of a default catch-all/generic visit and have a better alternative then i'm open to it since this isn't set in stone and isn't diffcult to change since the implementation is so trivial :) Actually when i think about it the "catch-all" isn't even really need/necessary, the original reason why i put it in in the first place was as a constrast to generic visits of with boost::variant visitors. Anyways it looks as if no one is interested, even just to make a comment of any form :( Thanks Korcan Hussien. _________________________________________________________________ Think you're a film buff? Play the Movie Mogul quiz and win fantastic prizes! http://www.msnmoviemogul.com
participants (3)
-
Douglas Gregor
-
Korcan Hussein
-
Ronald Garcia