- Boost - lists.boost.org

Boost.log: set_channel name dynamically for a basic_composite_logger
by syvyi 20 Oct '12

20 Oct '12

Hi, how to set attribute dynamically for a composite logger? lass my_logger_mt : public src::basic_composite_logger< char, my_logger_mt, src::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>, src::features< src::severity< severity_levels >, src::exception_handler, src::channel< std::string > > > { BOOST_LOG_FORWARD_LOGGER_CONSTRUCTORS(my_logger_mt) }; -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-log-set-channel-name-dynamically-f… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 34

[thread] deprecating Mutex::scoped_lock and Mutex::scoped_try_lock and boost::condition
by Vicente J. Botet Escriba 20 Oct '12

20 Oct '12

Hi, I would like to deprecate the following features in Boost.Thread: * Mutex::scoped_lock and Mutex::scoped_try_lock so that we can make mutex types independent from locks. The user should use instead unique_lock<Mutex> and the new public class try_unique_lock. * condition: This was there for forward compatibility since 1.35. The user should use instead condition_variable_any. What do you think? Best, Vicente

4 9

boost::python feature request: unique_ptr, interfaces and factory functions
by Maxim Yegorushkin 20 Oct '12

20 Oct '12

Hi Boost, I am using boost::python to expose a C++ API into Python. The class I would like to export is: struct Subscriber { virtual ~Subscriber() = 0; static std::unique_ptr<Subscriber> create(); }; It's an interface with a factory function returning a std::unique_ptr<>. I would like to be able to export it in the following manner: BOOST_PYTHON_MODULE(pub_sub) { boost::python::class_< Subscriber , std::unique_ptr<Subscriber> , boost::noncopyable >("Subscriber") .def(boost::python::init<>, Subscriber::create) ; ; } I.e., the python wrapper would hold a std::unique_ptr<Subscriber> and use Subscriber::create() factory function as a constructor for Python Subscriber class. The above code doesn't compile with boost-1.51.0 for two reasons: * std::unique_ptr<> is not supported by boost::python. On the other hand, std::auto_ptr<> is. * The factory function can't be used used as a Python object constructor. I thought there could be a way to specialize certain boost::python traits/metaclasses to make it work with std::unique_ptr<> and factory functions as constructors, but couldn't figure it out. The workaround I managed to get working is: std::auto_ptr<Subscriber> createSubscriber() { return std::auto_ptr<Subscriber>(Subscriber::create().release()); } BOOST_PYTHON_MODULE(pub_sub) { // Expose the class. boost::python::class_< Subscriber , std::auto_ptr<Subscriber> , boost::noncopyable >("Subscriber_", boost::python::no_init) ; ; // Expose its factory function. boost::python::def("Subscriber", createSubscriber); } I.e., std::unique_ptr<> gets replaced with std::auto_ptr<>, the Python class is renamed to Subscriber_ and the factory function gets exported as Subscriber allowing for Python syntax: import pub_sub s = pub_sub.Subscriber() # however assert isinstance(s, pub_sub.Subscriber) # fails assert isinstance(s, pub_sub.Subscriber_) # succeeds So, I was wondering if there are ways to make my original Python class export syntax work? -- Maxim

1 0

[test] new features use c++11 features
by Jürgen Hunold 19 Oct '12

19 Oct '12

Hi Gennadiy, the new features introduced in revision 81010 and81011 use c++ features unconditionally. This breaks compilation of Boost.Test on all older compilers. Even the recent gcc-4.6 (Ubuntu 12.04). The critical places are: std::tuple std::shared_ptr std::false_type std::remove_cv those can be replaced with std::tr1:: equivalents using boost/tr1. See a quick patch attached. The usage of std::enable_if is critical, as I could not find it in boost::tr1. But this should be available as boost::enable_if and be detected by the appropriate Boost.Config macro. And at least gcc-4.6.3 ist missing the angle bracket hack, so closing ">>" template argument lists are interpreted as operator >>. Also patched. Could you please try your changes with an older compiler first? As I can not use c++11 at the moment (I'm stuck with gcc-4.2) I would like to use the new features with this older compiler. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 4

[iterator] Using zip_iterator with std::pair
by "Claas H. Köhler" 19 Oct '12

19 Oct '12

Hi! I would like to use the boost::zip_iterator with std::pair. Unfortunately this does not work out of the box, but there exists a namespace boost::detail::tuple_impl_specific, which apparently needs to be specialised for each tuple type. I managed to re-implement tuple_meta_transform and tuple_meta_accumulate for std::tuple, which seems to be straightforward. However, there are functions of the form template<typename Tuple, typename Fun> complex_result_type tuple_transform(const Tuple&, Fun) which have to be overloaded as well, if I am not mistaken. However, overloading this with something like template<typename... Args, typename Fun> complex_result_type tuple_transform(const std::tuple<Args...>&, Fun) is probably not going to work, since this would be a partial template specialisation of a function. What is the recommended way of proceeding here? Or am I making things to complicated and there exists a simpler solution to using the zip iterator with std::pair / std::tuple. Any support would be appreciated. Regards Claas P.S: I am using boost 1.50 with gcc-4.6 and the C++11 standard.

3 11

[graph] dijkstra_shortest_paths solution stability
by Jan Hudec 18 Oct '12

18 Oct '12

Hello All, I need to implement an algorithm, that uses dijkstra's algorithm as key component. However it has two additional requirements on it: 1. If for any two vertices u, v there is an edge and a path of the same length through additional vertices, the direct edge is always selected and 2. If for any two vertices u, v there is more than one shortest path, all calculates shortest path trees that include path u, v contain the same path between those vertices. Now the article that describes the algorithm uses additional property with random values to disambiguate the paths, but I am sure the following two simple rules will achieve the effect more easily: 1. When u is reached at the same distance through two vertices, v and w, the one with lower distance from start will be used in the shortest path tree. 2. When u is reached at the same distance through two vertices, v and w, that both have the same distance from start, the one that comes first in some arbitrary fixed total ordering will be used inthe shortest path tree. These rules are trivially implementable by: 1. Not updating the parent map if the new distance is not strictly less. 2. Using additional criterion in the heap comparing the vertices by index or descriptor if they have the same tentative distance. Now I suspect rule 1 is already satisfied though it's not documented. And if rule 2 is not satisfied, would it be more generally useful and worth, possibly optionally, implementing in the library? -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

3 2

Fix some "unused variable" warnings
by Martin Martin 18 Oct '12

18 Oct '12

Hi, I'm using boost with clang++, with some style-related warnings turned on, and got a few warnings for unused variables. Here's the patch; are you interested in these changes? If so, is there a better way to get them to you? Thanks, Martin --- boost_1_51_0/boost/date_time/dst_rules.hpp 2008-02-27 15:00:24.000000000 -0500 +++ boost_1_51_0-fixed/boost/date_time/dst_rules.hpp 2012-10-18 09:31:08.433591299 -0400 @@ -369,11 +369,11 @@ const time_duration_type&) { return is_not_in_dst; } - static bool is_dst_boundary_day(date_type d) + static bool is_dst_boundary_day(date_type) { return false; } static time_duration_type dst_offset() diff '--unified=5' -r boost_1_51_0/boost/optional/optional.hpp boost_1_51_0-fixed/boost/optional/optional.hpp --- boost_1_51_0/boost/optional/optional.hpp 2010-12-18 16:29:39.000000000 -0500 +++ boost_1_51_0-fixed/boost/optional/optional.hpp 2012-10-18 09:31:50.737591130 -0400 @@ -888,16 +888,16 @@ // none vs optional<T> cases // template<class T> inline -bool operator == ( none_t x, optional<T> const& y ) +bool operator == ( none_t, optional<T> const& y ) { return equal_pointees(optional<T>() ,y); } template<class T> inline -bool operator < ( none_t x, optional<T> const& y ) +bool operator < ( none_t, optional<T> const& y ) { return less_pointees(optional<T>() ,y); } template<class T> inline bool operator != ( none_t x, optional<T> const& y )

2 1

[container] #7531 shadowing warnings under gcc
by Jeffrey Lee Hellrung, Jr. 18 Oct '12

18 Oct '12

Ion: I just wanted to make sure you see this. I can identify and make the necessary changes to trunk then release if you want me to. https://svn.boost.org/trac/boost/ticket/7531 Thanks, - Jeff

1 0

[graph] Efficiency of index map in dijkstra_shortest_paths
by Jan Hudec 18 Oct '12

18 Oct '12

Hello, The dijkstra_shortest_paths function requires an index map that maps vertices to index in range [0, num_vertices(g)). However there are several practially important algorithms that requite calculating shortest path trees with many times from each vertex, but each tree only spanning small fraction of an otherwise huge graph. I am somewhat concerned about allocating arrays of the size of the graph (that has millions of vertices) over and over (hundred million or more times) when many scans will stop after hundreds of vertices. Note that filtering the graph is not an option, because the stopping condition is given by radius or number of scanned vertices, but you obviously don't know which vertices will be scanned. Is there an option to use associative container for the queue indices? Or would it be useful to add it? Thanks Jan -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

3 5

[pool2] Requests for comment
by DUPUIS Etienne 18 Oct '12

18 Oct '12

Greetings, I am currently working on a replacement for boost ::pool. I have a few questions regarding what would be an ideal implementation. Hopefully some members of the Boost mailing list will be able to help me answering these questions. The first question requires to look at the source code; my other questions are more general. First question : I have started by defining a pool object which manage fixed size buffers of a given object type. Documented code is found here : http://svn.boost.org/svn/boost/sandbox/pool2/boost/pool/pool.hpp. The code is short and hopefully well documented. Note that the 'ThreadSafe' template parameter is currently ignored; I have not implemented thread safety yet. My question is about the "pool growth policy". This policy defines how the pool grows when it needs to allocate more memory. This policy is given as a parameter to the pool constructor. Should this policy be a template argument instead ? Moreover, if the policy is a template argument, I could add a constant 'MaximumNumberOfTimesThePoolWillBeGrown' into the policy class. This constant would allow me to replace the std::vector() which holds allocated pointers with a static array. Is this the right solution ? Other questions : - I have defined a pool class which manage fixed sized buffers of some object T. Do we also need a pool class that can manage variable sized buffers of some object T ? - From a pool, I can implement a pool_allocator which inherits from std::allocator, exactly like it was done in the original boost::pool. Do we need something else ? Thank you for your valuable insights, Etienne Dupuis Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci de nous en avertir immédiatement. ATEME décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization. Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.

9 20