[bimap] basic review
This is a basic review of the bimap library - limitted to reading the documentation so far as I don't believe it will compile on my primary compiler (Borland) due to a dependency on another unsupported libary (multi_index) My recommendation is 'accept', pending confirmation from other reviewers who can actually compile and use the code. - What is your evaluation of the design? The interface seems clean and composable, with a useful default behaviour and several extension points leading to a wide variety of supported 'advanced' behaviours. In particular, the 'tagging' feature should lead to better self-documenting code, and the ability to plug in different containers as the view for each 'side' of the bimap looks extremely powerful, allowing the user to trade off performance in time and space against required functionality. - What is your evaluation of the implementation? Not evaluated due to unsupported compiler. Strongly encouraged by the re-use of existing boost libraries as the building blocks. While this composition may lead to problems for future boost distributions (witness problems assembling the 1.34 release) this kind of re-use of existing components should lead to stronger libraries in the long run, and should become less of an issue as non-conforming compiler become rarer. - What is your evaluation of the documentation? High quality, with effrective use made of diagrams to illustrate the key points. This serves as a strong introduction to the library, both for its intended purpose and simple applications / tutorial. As I have not been able to test the library in anger, I have not made much use of the reference manual itself. - What is your evaluation of the potential usefulness of the library? I have certainly needed a library like this in various projects over the last few years. Lacking such a facility I have code up separate containers and maintained the joiing logic within my applications - a less than perfect solution. - Did you try to use the library? With what compiler? Did you have any problems? I have not tested, but my installed compiler does not support some of the dependent libraries, notably multi_index. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Around 3 hours studying the documentation. - Are you knowledgeable about the problem domain? I would describe myself as competent-but-not-expert, which should probably be the case for the majority of users of this library. I would like to thank Matias for all the hard work in bringing this library up to review standards. In particular the effort in the documentation is appreciated, as this is easily overlooked. I will certainly be looking to extend support to the Borland compiler should this library be accepted. -- AlisdairM
On 2/20/07, AlisdairM <alisdair.meredith@uk.renaultf1.com> wrote:
This is a basic review of the bimap library - limitted to reading the documentation so far as I don't believe it will compile on my primary compiler (Borland) due to a dependency on another unsupported libary (multi_index)
My recommendation is 'accept', pending confirmation from other reviewers who can actually compile and use the code.
Thanks for being the first one to vote!
- What is your evaluation of the design?
The interface seems clean and composable, with a useful default behaviour and several extension points leading to a wide variety of supported 'advanced' behaviours.
In particular, the 'tagging' feature should lead to better self-documenting code, and the ability to plug in different containers as the view for each 'side' of the bimap looks extremely powerful, allowing the user to trade off performance in time and space against required functionality.
That was one of the design goals. The idea is that you can use the basic functionality of the library just typing bimap<X,Y>, with out knowing the advance features, like tagging or controlling the constrains of the sets that compose the bidirectional mapping.
- What is your evaluation of the implementation?
Not evaluated due to unsupported compiler. Strongly encouraged by the re-use of existing boost libraries as the building blocks. While this composition may lead to problems for future boost distributions (witness problems assembling the 1.34 release) this kind of re-use of existing components should lead to stronger libraries in the long run, and should become less of an issue as non-conforming compiler become rarer.
I agree with you, that was the idea behind building this library with heavy boost code reuse in mind.
- What is your evaluation of the documentation?
High quality, with effrective use made of diagrams to illustrate the key points. This serves as a strong introduction to the library, both for its intended purpose and simple applications / tutorial. As I have not been able to test the library in anger, I have not made much use of the reference manual itself.
- What is your evaluation of the potential usefulness of the library?
I have certainly needed a library like this in various projects over the last few years. Lacking such a facility I have code up separate containers and maintained the joiing logic within my applications - a less than perfect solution.
It is not only a problem of space or time efficiency, maintaining the logic could lead to a real nightmare.
I would like to thank Matias for all the hard work in bringing this library up to review standards. In particular the effort in the documentation is appreciated, as this is easily overlooked. I will certainly be looking to extend support to the Borland compiler should this library be accepted.
Thanks again for the positive review! Best regards Matias
participants (2)
-
AlisdairM -
Matias Capeletto