Before I forget (for the 20th time already!), the upcoming review of my TR1 library submission is in need of someone to act as review manager, the review is scheduled to start on September 20th, and details are as follows: Description: ~~~~~~~~ The TR1 library provides an implementation of the C++ Technical Report on Standard Library Extensions. This library does not itself implement the TR1 components, rather it's a thin wrapper that will include your standard library's TR1 implementation (if it has one), otherwise it will include the Boost Library equivalents, and import them into namespace std::tr1. Functionality supported includes: Reference Wrappers Smart Pointers Class template result_of. Function template mem_fn. Function Object Binders. Polymorphic function wrappers. Type Traits. Random Number Generators and Distributions. Tuples. Tuple Interface to std::pair. Fixed Size Array. Hash Function Objects. Regular Expressions. Complex Number Algorithm Overloads. Complex Number Additional Algorithms. Functionality in TR1 but not yet available in this implementation (because they're not in Boost): Mathematical Special Functions. Unordered Associative Set (Hash Table). Unordered Associative Map (Hash Table). C99 C language additions. This library also makes changes to Boost.Config, and adds some new functionality to Boost.Math, reviewers should start with the readme.html in the root directory of the zip file. ~~~~~~~~~~~~~ Available at: http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&directory=tr1 or at: http://boost-consulting.com/vault/index.php?action=downloadfile&filename=tr1-20050816.zip&directory=TR1& Regards, John.
"John Maddock" <john@johnmaddock.co.uk> writes:
Description: ~~~~~~~~
The TR1 library provides an implementation of the C++ Technical Report on Standard Library Extensions. This library does not itself implement the TR1 components, rather it's a thin wrapper that will include your standard library's TR1 implementation (if it has one), otherwise it will include the Boost Library equivalents, and import them into namespace std::tr1. Functionality supported includes:
Reference Wrappers Smart Pointers Class template result_of. Function template mem_fn. Function Object Binders. Polymorphic function wrappers. Type Traits. Random Number Generators and Distributions. Tuples. Tuple Interface to std::pair. Fixed Size Array. Hash Function Objects. Regular Expressions. Complex Number Algorithm Overloads. Complex Number Additional Algorithms.
Functionality in TR1 but not yet available in this implementation (because they're not in Boost):
Mathematical Special Functions. Unordered Associative Set (Hash Table). Unordered Associative Map (Hash Table). C99 C language additions.
Does it really have a TR1-compatible bind()? According to Peter, Boost.Bind is not TR1-compatible. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Does it really have a TR1-compatible bind()? According to Peter, Boost.Bind is not TR1-compatible.
I've tried to document all the incompatibilities with TR1 that I've found, for Bind I have: " Standard Conformity: The traits classes is_placeholder and is_bind_expression are not supported by the Boost implementation. " Those were the only incompatibilities I found when I wrote the concept test program from for bind from the TR1 spec, although there were some compilers (including gcc) that had other problems: I couldn't figure out whether this was a problem with Bind or the compiler. Is there anything else I should be aware of? John.
John Maddock wrote:
Does it really have a TR1-compatible bind()? According to Peter, Boost.Bind is not TR1-compatible.
It's compatible, but not fully conforming. Every valid boost::bind expression should be a valid tr1::bind expression, but the reverse is not true.
I've tried to document all the incompatibilities with TR1 that I've found, for Bind I have:
" Standard Conformity: The traits classes is_placeholder and is_bind_expression are not supported by the Boost implementation. "
Those were the only incompatibilities I found when I wrote the concept test program from for bind from the TR1 spec, although there were some compilers (including gcc) that had other problems: I couldn't figure out whether this was a problem with Bind or the compiler. Is there anything else I should be aware of?
Boost.Bind doesn't support or use result_of.
John Maddock <john <at> johnmaddock.co.uk> writes:
Before I forget (for the 20th time already!), the upcoming review of my TR1 library submission is in need of someone to act as review manager, the review is scheduled to start on September 20th, and details are as follows:
As a related issue, would it make sense to also review the hash_map/hash_set implementations at the same time (assuming Daniel et al can finish it in time)? -Thorsten
Thorsten Ottosen wrote:
As a related issue, would it make sense to also review the hash_map/hash_set implementations at the same time (assuming Daniel et al can finish it in time)?
Sorry it took me a while to answer this. I haven't done much on these recently. I can get the implementation and tests ready in time, but I haven't done much in the way of documentation. I suppose if this is a part of Boost.TR1 that won't matter so much. I think this should be up to John? It seems a little late to be adding things. Daniel
As a related issue, would it make sense to also review the hash_map/hash_set implementations at the same time (assuming Daniel et al can finish it in time)?
Sorry it took me a while to answer this. I haven't done much on these recently. I can get the implementation and tests ready in time, but I haven't done much in the way of documentation. I suppose if this is a part of Boost.TR1 that won't matter so much. I think this should be up to John? It seems a little late to be adding things.
I don't mind the hash tables being reviewed at the same time, but without documentation (which is what most folks review), it'll be harder for people to get to grips with it. Do you have a separate review scheduled yet? I don't particularly see any problem with extending TR1 to adapt to new Boost submissions that come along in the future. John.
John Maddock wrote:
I don't mind the hash tables being reviewed at the same time, but without documentation (which is what most folks review), it'll be harder for people to get to grips with it. Do you have a separate review scheduled yet?
No, I was only going to submit it once I'd finished the documentation. I'm not trying to push this. But the current state of the documentation isn't that bad - there is a little, and the library is of course fully specified by TR1. Also, since the design is already fixed by TR1, it won't really be up for review (or will it?), so the documentation is a little less important here (but just a little). I'll try to put a copy of the documentation up soon, but it'll take me a little while as I'll need to setup boostbook & quickbook first to generate it (my computer isn't great and building quickbook takes forever). Daniel
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:01ba01c5b5ee$5455a4f0$90540352@fuji...
Before I forget (for the 20th time already!), the upcoming review of my TR1 library submission is in need of someone to act as review manager, the review is scheduled to start on September 20th, and details are as follows:
I'll volunteer if no one else has, but I'm going to be on a mini-vacation until September 23rd. --Beman
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:029701c5b9de$9a4d6990$99510352@fuji...
I'll volunteer if no one else has, but I'm going to be on a mini-vacation until September 23rd.
No-one else has at present, we can delay the start of the review until the 23rd or so if that would help?
That's fine with me. --Beman
participants (6)
-
Beman Dawes -
Daniel James -
David Abrahams -
John Maddock -
Peter Dimov -
Thorsten Ottosen