From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-09-17 10:59:27
Thanks for you comments.
"Pavel Vozenilek" <pavel_vozenilek_at_[hidden]> wrote in message
> Hello Thorsten,
> I looked briefly on your library and have few notes (bellow).
> 1. Can you add
> #if _MSC_VER >= 1200
> # pragma once
> to the assign.hpp and others? This is helpful for MSVC and Intel C++.
yep. I'll use Peter's version.
> 2. assign.hpp:
> It may be better to use
> #include <boost/assign/stl.hpp>
> #include "assign/stl.hpp"
> The rules for file lookup can vary between compilers.
> 3. assign.hpp brings in the whole STL and uBlas. This would have
> impact on compilation time.
> It would be useful to have also finer granularity headers,
> something like Serialization library does.
> - assign.hpp - everything
> - assign/stl.hpp - STL
> - assign/vector.hpp - only vector<>
yep, I agree. notice that most of STL is not needed when the compiler
support ordering of function templates.
> 4. index.html: the Bjarne's joke doesn't seem well placed - I suspect
> it was told long ago when very few people had clue. He likely
> changed his opinion since.
Perhaps. I'm not trying to make fun of him, though. Do other people thinks
such a comment is misplaced?
> 5. examples at the beginning of index.html:
> #include <vector>
> there is redundant.
yes it is if the compiler supports ordering of function templates.
> Second example with map<> includes <vector> instead of <map>.
> 6. Maybe the namespace can be shortened from "assignment" to "assign".
I don't think so. According to [220.127.116.11]
"A namespacename or namespacealias shall not be declared as the name of any
other entity in the same declarative region."
so we can't have a namespace 'assign' and a function 'assign' inside that
namespace. Not all compilers seem toobey this.
> 7. index.html, "Reference" section: there should be only one font used in
> first line.
I'm not sure what you mean here.
> 11. index.html: maybe the reference section can be made more
> I mean e.g. table of functions, with effects, constrainst, exceptions
> It reads better (to some) than the 'literal' way with full sentences.
Before I do so I would like to know if other people think it is really
necessary. I mean, one should very quikly realize how thinks works and then
don't think more about about it. For example, you easily see that you can
use operator+= () and the comma and really donøt need more information. If
you need the extra info, I think it is mostly there.
> 12. index.html, portability section|: the limitations should be detailed
> - which compilers and what.
I don't know exactly yet since I haven't run the latest version on all the
compiers. I just put the text there as a place holder.
> 13. would it be possible to support mode with disabled exception handling?
> (indicated by BOOST_NO_EXCEPTIONS)
yep, and I have done so.
> 15. property_map.hpp has 0 size.
its not really intended to be used yet :-)
> 16. fixed_size_assigner.hpp:
> destructor throws!!!! This is very, very, very dangerous.
> If it is somehow safe due to uncaught_exception, it should be
> in detail explained there.
I guess I have missed something here. Won't uncaught_exception() guard my
use of throwing exceptions?
> 17. The library can consider boost::call_traits<T>::param_value.
> This way primitive types are be passed by value, instead of by
> Newest STLport (in beta) was able to gain 5-10% speedup for
I didn't do it because some small benchmarks I did some time ago showed no
difference. So I though it would be better to improve compile time. But I
take you word for it, so I'll update the code acordingly..
> 18. Support for (coming to review) circular_buffer<> library may be added.
As the documentation states, it should work "out of the box" since it is a
standard complient container.
> 19. Wish feature: would it be somehow possible to add 'dynamic
> I mean something like:
> vector<int> values;
> values += 10, 20, variable1, 40, foo();
> where the library would copy current value of 'variable1' and
> result of calling function foo() into container.
> I have no clue if that's feasible or within intentions of the library.
I thought it was obvious that this can be done already :-) I'll remove the
word "constant" from the introduction.
> 20. Question: do usual rules of automatic conversion apply in this
> I didn't find in documentation.
Yes. I've added a small paragraph to the reference section.
> 21. Are the containers (if possible) resized prior to the given amount of
> (I believe the do not and it cannot be done but better to ask.)
assign() does a .clear() first So it cannot be used with container adapters.
> 22. Support for slist, multimap, multiset, hash_map, hash_set,
> hash_multimap, hash_multiset
> may be also added (if feasible).
> Maybe also boost::tuple.
> 23. Can you add support for std::pair? I know there's make_pair() but for
multimap/multiset are already supported. the hash_stuff and slist works "out
of the box" but are not supported for compilers without partial template
there is a lot of more stuff that can be given support, but I just wanted
to get the basics right first. It should be quite trivial to add extra
support though; I'll look into it soon.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk