[review] Review of Unordered library begins today December 7
Hi all, The formal review of the Unordered library, proposed by Daniel James, begins today : *Description*: An implementation of the unordered containers specified in TR1, with most of the changes from the recent draft standards. *Author*: Daniel James *Download*: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filename=unordered.zip&directory=Containers The documentation is in the zip file. I've put documentation online here: http://igaztanaga.drivehq.com/unordered http://tinyurl.com/yw8wjp What to include in Review Comments ================================== Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Unordered containers are likely to become one of the most used Boost libraries so I encourage you to review the library in order to see if Unordered fulfills all your expectations. Ion Gaztañaga - Review Manager -
* What is your evaluation of the design? 7 out of 10. * What is your evaluation of the implementation? 8 out of 10. * What is your evaluation of the documentation? 8 out of 10. * What is your evaluation of the potential usefulness of the library? 10 out of 10. * Did you try to use the library? With what compiler? mingw, cygwin, gcc, msvc visual studio 2005, and no. * How much effort did you put into your evaluation? A quick reading. * Are you knowledgeable about the problem domain? Hmm not really. And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? I do not think it should be accepted, and my only small gripe with it its how the library is organize. Most boost library have "boost" as the top folder for organization of jam file and jam.v2...., when I used unordered library, unordered seems to be like the top folder structure...thats my only gripe. Its small but it destroys the uniformity of boost library". Clearer words.. when you unzip boost library. boost is top level structure. When you unzip unordered library, it is unordered --> boost --> unordered.... On Dec 7, 2007 2:05 AM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Hi all,
The formal review of the Unordered library, proposed by Daniel James, begins today :
*Description*:
An implementation of the unordered containers specified in TR1, with most of the changes from the recent draft standards.
*Author*:
Daniel James
*Download*:
The documentation is in the zip file. I've put documentation online here:
http://igaztanaga.drivehq.com/unordered
What to include in Review Comments ==================================
Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers.
Here are some questions you might want to answer in your review:
* What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain?
And finally, every review should answer this question:
* Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion.
Unordered containers are likely to become one of the most used Boost libraries so I encourage you to review the library in order to see if Unordered fulfills all your expectations.
Ion Gaztañaga - Review Manager - _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
chun ping wang wrote:
I do not think it should be accepted, and my only small gripe with it its how the library is organize. Most boost library have "boost" as the top folder for organization of jam file and jam.v2...., when I used unordered library, unordered seems to be like the top folder structure...thats my only gripe. Its small but it destroys the uniformity of boost library". Clearer words.. when you unzip boost library. boost is top level structure. When you unzip unordered library, it is unordered --> boost --> unordered....
That's just an artefact of the way I packaged the library. While developing it I've been storing it in a separate directory from boost, and using boost.build to handle this. If accepted into boost it will follow the same directory structure as the rest of boost. Thanks for the review, Daniel
Ion Gaztañaga wrote:
Hi all,
The formal review of the Unordered library, proposed by Daniel James, begins today :
*Description*:
An implementation of the unordered containers specified in TR1, with most of the changes from the recent draft standards.
*Author*:
Daniel James
*Download*:
The documentation is in the zip file. I've put documentation online here:
What is the difference of this library from hash_map in some STL extention libraries? Is it just a new name for hash_map/hash_set?
gchen wrote:
What is the difference of this library from hash_map in some STL extention libraries? Is it just a new name for hash_map/hash_set?
Hash containers were not standardized so there are different implementations with different guarantees and features (some used incremental hashing or bidirectional iterators) and C++ unordered containers have been standardized to support a broad range of implementations adding new features, like bucket iterators. You shouldn't use hash_map and other similar containers if you want to write portable code just because they are not standard. Unordered aims to be the Boost implementation of standard C++ hash containers. For more information about the rationale and the evolution of unordered containers design see Matthew Austern's proposal: A Proposal to Add Hash Tables to the Standard Library (revision 4) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1456.html Regards, Ion
--- Ion Gaztañaga wrote:
Hi all,
Hello!
What to include in Review Comments ==================================
Your comments may be brief or lengthy, but basicallythe Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers.
Here are some questions you might want to answer in your review:
* What is your evaluation of the design?
The design is excellent, as it should be. I can see how everything works at a glance.
* What is your evaluation of the implementation?
The implementation rationale is detailed enough; however, I am curious as to the purpose of BOOST_UNORDERED_LOCAL_CBEGIN.
* What is your evaluation of the documentation?
It's pretty thorough. A few nits and issues: * Since the documentation assumes prior knowledge of STL containers, it would be nice for the Introduction to provide a link to SGI's website (or whichever STL reference documentation you guys prefer). * It should be stressed that either writing your own hash function or extending/specializing boost::hash is *essential* to get Boost.Unordered containers to work with UDTs (not just *pointers* to UDTs). * Sometimes I see "T" where "Value" was meant to be. This appears in the reference documentation for all containers. * I read the return types of equal_range() and equal_range() const as the same, when the return type of the const variant should be std::pair<const_iterator,const_iterator>. This applies to the reference documentation for all containers. * s/elment/element
* What is your evaluation of the potential usefulness of the library?
At work, we use std::map to hold nodes in our tile search algorithms simply because std::hash_map is not a standard container. As soon as compiler and library vendors start incorporating Boost.Unordered into their TR1 implementations (or even sooner, if I can convince my boss that Boost is worth the download), we will definitely switch over.
* Did you try to use the library?
I haven't had the time to run the test programs, but I've replaced std::map with boost::unordered_map in a few of my own examples.
* With what compiler?
MinGW (GCC 3.4.5)
* Did you have any problems?
None so far.
* How much effort did you put into your evaluation?
Four hours of in-depth reading, one minute of coding (search-and-replace works because I try to keep things generic).
* Are you knowledgeable about the problem domain?
I'm proficient with data structures in general, not so much with particular hash functions.
And finally, every review should answer this question:
* Do you think the library should be accepted as a Boost library?
Oh, yeah. Cromwell D. Enage ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
On 15/12/2007, Cromwell Enage <sponage@yahoo.com> wrote:
The implementation rationale is detailed enough; however, I am curious as to the purpose of BOOST_UNORDERED_LOCAL_CBEGIN.
To be honest, it's something I'd forgotten about. A while ago, the 'cbegin' and 'cend' members were added to all the standard containers in the draft standard for accessing 'const_iterator' regardless of whether the container is const or not. But they weren't added for the unordered containers' local iterators (the iterators for single buckets). If that macro is defined they are included in the implementation. I think the best thing to do is include the methods as an extension and document and test them properly. I might add a macro to turn off extensions. Joaquín asked about this on comp.std.c++ but didn't get any reply: http://groups.google.com/group/comp.std.c++/browse_thread/thread/ee508661207...
* What is your evaluation of the documentation?
It's pretty thorough. A few nits and issues:
Thanks for these, I'll try to fix all of them. Just one point:
* Sometimes I see "T" where "Value" was meant to be. This appears in the reference documentation for all containers.
In unordered_set/unordered_multiset it's only in the swap functions, and they're incorrect. (I think I copied and pasted them from the map documentation). In unordered_map/unordered_multimap, the use of 'T' is deliberate, as 'Value' should be the same as the value_type typedef, but value_type is defined as std::pair<Key const, T>. 'T' is what the standard uses but I think I'll replace it with 'Mapped' which is hopefully more descriptive. Thanks for the review, Daniel
----- Mensaje original ----- De: Daniel James <daniel_james@fmail.co.uk> Fecha: Domingo, Diciembre 16, 2007 10:56 am Asunto: Re: [Boost-users] [review] Review of Unordered library begins todayDecember 7 Para: boost-users@lists.boost.org
On 15/12/2007, Cromwell Enage <sponage@yahoo.com> wrote:
The implementation rationale is detailed enough; however, I am curious as to the purpose of BOOST_UNORDERED_LOCAL_CBEGIN.
To be honest, it's something I'd forgotten about. A while ago, the 'cbegin' and 'cend' members were added to all the standard containers in the draft standard for accessing 'const_iterator' regardless of whether the container is const or not. But they weren't added for the unordered containers' local iterators (the iterators for single buckets). If that macro is defined they are included in the implementation.
I think the best thing to do is include the methods as an extension and document and test them properly. I might add a macro to turn off extensions.
Joaquín asked about this on comp.std.c++ but didn't get any reply:
I think it's already safe to include them unconditionally: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2482.html#691 Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
On 16/12/2007, "JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote:
I think it's already safe to include them unconditionally:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2482.html#691
Okay, I will. Thanks. Daniel
participants (1)
-
"JOAQUIN LOPEZ MU?Z" -
chun ping wang -
Cromwell Enage -
Daniel James -
gchen -
Ion Gaztañaga