[boost] [containers] remarks and questions

Subject: [boost] [containers] remarks and questions
From: Pierre Morcello (pmorcell-cppfrance_at_[hidden])
Date: 2011-08-08 17:48:48

Hello Ion,

This is not a review.

I took 3 hours to read the docs, checks some tests, try to check some
sources, but I am still not used to read so few comments in the code. I
played a little with the library then, tried to encapsulate some
std::auto_ptr<X> in the new containers and things like that.

Based on that very little experience, I would like to share some thoughts
and ask a few questions on the proposed boost.containers library.

1/ I would really appreciate that the docs were more complete, at least for
the technical part.
        => ex : "flat_map : more memory friendly and with faster searches"
                => In what way? is the algorithm complexity lesser than previous systems?
                        or do you mean that contiguous memory is more cache-friendly?
                => do you provide different kernel implementations?
                => is there a paper on the subject? 		
                => Is there an evaluated algorithm complexity for the stable_vector? 
                        => is memory contiguous like a std::vector? can I use memcpy on several
elements?
        These are just examples of questions that I expect to be answered by the
docs.
        EDIT : I read proposition to embed elements of Joaquin M Lopez Munoz's
blog. This is exactly that kind of informations I am looking for.

        => For the tree class, I can't remember any tree interface in the std.
        Could you point me to some informations ? Sorry If I miss something
obvious. 

2/ I was surprised (in a good way) to see some Andrei Alexandrescu's code in
the library. Will the Loki licence be shipped now with boost? (This is not a
problem for me).

3/ A few tests might be added. ex: Test the fact the vector usually are
contiguous in memory. I can write this one if you are interested.

4/ The 'move aware' containers are nice to use but as a drawback We are
forced to use macro to define the types using the 'move' semantics.
   What other container libraries can this work be related to?
   There are some examples of containers requiring the value_type to support
only the "defaut constructor + a swap() function".
   This is a concept I would really appreciate to see in boost.containers.
   In that case, I would very happily use this library.
   Otherwise I think I will stick with other containers classes.

5/ "The aim of the library is to offers advanced features"
    Is the proposed Boost.containers also an effort towards development of
new features for containers?
    If that is the case, then what are the plans for the future ? Is there a
roadmap?

To sum up :
I am surprised that such a container library was not already integrated in
boost. This should be a nice addition. But at the moment I don't think I
would use it: my main interest would be for the value_type supporting
"defaut constructor + a swap() function" to be added to the library. I also
would like more detais in the documentation.
In my humble opinion, it would also be easier for exterior people to learn
from and to contribute to your library if there were more comments in the
code.

I congratulate you and the other authors for your work and efforts, and wish
you the best for the review.

Best regards,

Pierre Morcello 

--
View this message in context: http://boost.2283326.n4.nabble.com/boost-containers-remarks-and-questions-tp3728389p3728389.html
Sent from the Boost - Dev mailing list archive at Nabble.com.