Boost.Containers? (WAS Re: Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB)
On Wed, Jun 24, 2009 at 10:40 AM, Christian Schladetsch<christian.schladetsch@gmail.com> wrote:
What do people think of moving boost::interprocess::containers to boost::containers? These containers are not really specific to interprocess?
I think this can easily be done through 'using' declarations: namespace boost { namespace containers { using boost::interprocess::list; using boost::interprocess::vector; /* ... */ } } I don't think it should move though to support earlier applications that are already using the interprocess namespace for the containers. -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com
On Wed, Jun 24, 2009 at 10:40 AM, Christian Schladetsch<christian.schladetsch@gmail.com> wrote:
What do people think of moving boost::interprocess::containers to boost::containers? These containers are not really specific to
interprocess?
I think this can easily be done through 'using' declarations:
namespace boost { namespace containers { using boost::interprocess::list; using boost::interprocess::vector; /* ... */ } }
This makes complete sense to me. What would the header names be? Perhaps: #include <boost/containers/list.hpp> #include <boost/containers/vector.hpp> ... #include <boost/containers.hpp> // includes all above Would the intermediate directory be called plural containers or singular container? Is interprocess::string a container? I would say yes, but then there would be <boost/container/string.hpp> which seems a little unsettling. But, does boost really want a <boost/string.hpp> ? Cheers, Christian.
On Wed, Jun 24, 2009 at 12:01 PM, Christian Schladetsch<christian.schladetsch@gmail.com> wrote:
I think this can easily be done through 'using' declarations:
namespace boost { namespace containers { using boost::interprocess::list; using boost::interprocess::vector; /* ... */ } }
This makes complete sense to me.
What would the header names be? Perhaps:
#include <boost/containers/list.hpp> #include <boost/containers/vector.hpp> ... #include <boost/containers.hpp> // includes all above
I'd think this would be a sane organization.
Would the intermediate directory be called plural containers or singular container?
Based on the guidelines, it'd most probably be plural. 'boost::containers::*' makes much more sense at least to me.
Is interprocess::string a container? I would say yes, but then there would be <boost/container/string.hpp> which seems a little unsettling.
But, does boost really want a <boost/string.hpp> ?
I'd say it's fine with me to have something like <boost/containers/string.hpp> -- it's just a file name anyway and it's descriptive enough to convey the meaning. HTH -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com
Dean Michael Berris wrote:
On Wed, Jun 24, 2009 at 10:40 AM, Christian Schladetsch<christian.schladetsch@gmail.com> wrote:
What do people think of moving boost::interprocess::containers to boost::containers? These containers are not really specific to interprocess?
I think this can easily be done through 'using' declarations:
namespace boost { namespace containers { using boost::interprocess::list; using boost::interprocess::vector; /* ... */ } }
All the work to decouple Boost containers from Interprocess is already done, except for move header <boost/interprocess/detail/move.hpp>. A quick find/replace exercise can put all these containers in boost/container without any dependence on boost/interprocess (we should put move emulation in boost move). Implementations of all Interprocess containers are now here: boost/interprocess/containers/container/ in the boost::interprocess_containers namespace Headers in boost/interprocess/containers just include previous headers implementation and hey have using declarations (e.g. boost/interprocess/containers/list.hpp): #ifndef BOOST_INTERPROCESS_CONTAINERS_LIST_HPP #define BOOST_INTERPROCESS_CONTAINERS_LIST_HPP #if (defined _MSC_VER) && (_MSC_VER >= 1200) # pragma once #endif #include <boost/interprocess/detail/config_begin.hpp> #include <boost/interprocess/containers/container/list.hpp> namespace boost { namespace interprocess { using boost::interprocess_container::list; } //namespace interprocess { } //namespace boost { #include <boost/interprocess/detail/config_end.hpp> #endif // #ifndef BOOST_INTERPROCESS_CONTAINERS_LIST_HPP
I don't think it should move though to support earlier applications that are already using the interprocess namespace for the containers.
All the work to maintain backwards compatibility is done, we just need to find/replace some includes and namespaces. I have already done the exercise with an slightly older version of containers for Boost.Move: https://svn.boost.org/trac/boost/browser/sandbox/move/boost/container My opinion is that containers should go to boost/container. All the dirty work is already done ;-) Best, Ion
Hi Ion, ----- Original Message ----- From: "Ion Gaztañaga" <igaztanaga@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, June 24, 2009 9:48 PM Subject: Re: [boost] Boost.Containers? (WAS Re: Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB)
All the work to decouple Boost containers from Interprocess is already done, except for move header <boost/interprocess/detail/move.hpp>. A quick find/replace exercise can put all these containers in boost/container without any dependence on boost/interprocess (we should put move emulation in boost move).
<snip>
All the work to maintain backwards compatibility is done, we just need to find/replace some includes and namespaces. I have already done the exercise with an slightly older version of containers for Boost.Move:
https://svn.boost.org/trac/boost/browser/sandbox/move/boost/container
My opinion is that containers should go to boost/container. All the dirty work is already done ;-)
When do you plan to release (or schedule for review) Boost.Move? Best, Vicente
When do you plan to release (or schedule for review) Boost.Move?
Best, Vicente
Not until August at least, since I'll be extremely busy for two weeks and then I'm going on holidays. Best, Ion
When do you plan to release (or schedule for review) Boost.Move?
Best, Vicente
Not until August at least, since I'll be extremely busy weeks the next two weeks and then I'll go on holidays. Best, Ion
participants (4)
-
Christian Schladetsch -
Dean Michael Berris -
Ion Gaztañaga -
vicente.botet