October 2012 - Boost - lists.preview.boost.org

[thread] terminating destructor
by Andrzej Krzemienski 26 Oct '12

26 Oct '12

Hi, I can see in the release notes that in Boost 1.52 boost::thread's destructor calls terminate if joinable, in order to conform to C++11 specification. I am not sure if this is the best course of action. My understanding -- form the C++ Committee papers and informal presentations -- is that the reason for introducing a 'terminating destructor' was the lack of thread cancellation/interruption functionality. Thread interruption is supposed to be the preferred behavior for thread's destructor. std::thread does not support interruption (for some reasons), but boost::thread does (this is already a departure from C++11), so shouldn't the latter prefer to interrupt a joinable thread in the destructor? Regards, &rzej

9 41

Re: [boost] [Boost-build] another simple boost build failure
by Jürgen Hunold 25 Oct '12

25 Oct '12

Hi Ronny, On Thursday, 25. October 2012 12:55:10 you wrote: > thanks a lot. I did not know that one has to rebuild everything after > changing the requirements. It seems to work now. Good to hear that everything is up and running. > It is true, I did not read the starting guide thoroughly, I'll do that now > :-). Good, too ;-) > I am a bit confused about the library being a static library. Shouldn't it > be "boost_filesystem-vc90-mt-gds-1_50.lib" instead of > "boost_filesystem-vc90-mt-gd-1_50.lib" then? Or did I get it wrong? Ah, that is the "s" for static runtime. AFAIK the last msvc to provide a static runtime was 7.1. Don't confuse "static library" with "static runtime libraries". The static runtime opens up a new can of worms... 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 1

[Program Options] terminate parsing after first positional argument
by Evan Driscoll 25 Oct '12

25 Oct '12

This summer there was some discussion on the boost-users list about whether it is possible to use program_options to write an interface like 'xargs' (or time, or env, or nohup, or ssh, or sudo, or valgrind, or Python, or lots of other tools) where any options (--foo) that appear after the first positional arguments are considered positional arguments. In other words,'xargs foo --help' in real Unix behaves the same as 'xargs -- foo --help', rather than 'xargs --help foo', but you can't get this behavior currently from Boost. I proposed a couple patches, and there was a very small amount of discussion, but it sort of petered out (in part because I went away for a couple weeks at an inopportune time). Is there any interest in adopting them? The bug I filed just got another hit from someone else who wants it. https://svn.boost.org/trac/boost/ticket/6991 The following is a summary of the status: The ideal would be to have an 'allow_interspersed' style option which would be set by default (to give the now-usual behavior of "cmd arg --opt" being the same as "cmd --opt arg") but which a client program could unset if they wanted the xargs-like behavior. However, I don't see how to do this, because > If someone says > style_t style = allow_short | allow_slash_for_short > I can't automatically go and set allow_interspersed for them as well. And so without some ugly and not-worth-it coding tricks (changing style_t to a class), unless I'm missing something you can't pick this ideal without breaking backwards compatibility. So I instead suggested a new 'disallow_interspersed' style option, which would be off by default (keeping backwards compatibility) but you could set it to get xargs-like behavior, but this is inconsistent with all the other style flags which are allow_xxx. So what do you want to do regarding this issue? References: Trac issue: https://svn.boost.org/trac/boost/ticket/6991 (includes a patch for both of those options) The previous messages in this discussion, on boost-users: http://lists.boost.org/boost-users/2012/07/75100.php Evan

1 0

Using libc++ when compiling with clang in c++11 mode
by Marshall Clow 24 Oct '12

24 Oct '12

Has come up again: https://svn.boost.org/trac/boost/ticket/7566#comment I'm thinking that having a clang-c++11 toolset (that includes using libc++) might be a good thing. Any other opinions? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

2 1

Is there a way to specialize how a smart_ptr<T> releases the T?
by David Hagood 24 Oct '12

24 Oct '12

I am trying to wrapper around a C library (specifically, libxml2) so that I can use it within a C++ program. (yes, I am aware of libxml++ - but it doesn't play nice with libxslt). If the core libxml2 objects were internally reference counted, I could use an intrusive_ptr, and have the friend intrusive_ptr_release call libxml2's release function, and all would be well - but unfortunately libxml2 does not internally reference count the objects (at least, not in a way I have seen). If there were a way to specialize smart_ptr<T> such that instead of the destructor calling delete(), it called what I wanted, I'd be set, but I see no way to easily specialize smart_ptr<xmlDoc> in that way - or am I missing something?

8 10

Application using boost libraries (commercial)
by Dominic Amann 24 Oct '12

24 Oct '12

Application: EKKO_Project V1 R1 Company: Sensors & Software Inc, Description: EKKO_Project is the all-inclusive software solution for managing, displaying, processing and interpreting GPR data. It provides easy, highly efficient analysis and integration of GPR data. The software is optimized for Windows 7 and later operating systems. Boost Usage: filesystem, multi-array, smart pointer, date time, iterators, optional, program options, property tree, regex, test, tokenizer, type traits, uBlas. These boost libraries were used extensively in the core program functionality to make a cross-platform library that would allow a thin platform specific GUI to control all basic functionality. URL: <http://sensoft.ca/> Product page: <http://sensoft.ca/Products/Software/Details-Features.aspx#EKKOProject> Thank you, Dominic Amann Software Developer Sensors & Software Inc. 1040 Stacey Court, Mississauga ON. L4W 2X8 Toll Free: 1-800-267-6013 ext. <user ext> T: 905-624-8909 F: 905-624-9365 C: 416-270-4587 E: DAmann(a)sensoft.ca www.sensoft.ca<http://www.sensoft.ca/> subsurface imaging solutions

1 0

[atomic] unconditional cmpxchg8b support
by Tim Blechmann 23 Oct '12

23 Oct '12

hi helge & list, using boost.atomic on ia32/gcc causes me quite some headaches these days, as the cmpxchg8b instruction is enabled via the __i686__ or __x86_64__ macros. however on debian for example, the compiler defaults to generate code for i486. cmpxchg8b has been introduced with the p5 architecture, though, so compiling without specifying a -march flag won't generate the instruction. whatever, i wonder if it would be reasonable to enable cmpxchg8b by default on *all* ia32 platforms, not just on i686. advantage: less trouble, as we can be sure that the instruction is generated. boost.lockfree e.g. is not lockfree on ia32 without. disadvantage: the code won't work on i386 and i486 machines. imo, all ia32 machines without cmpxchg8b should belong to a museum, and we could introduce a macro like BOOST_ATOMIC_NO_CMPXCHG8B if we really care of compiling for any of those machines. thoughts? tim

7 16

In case you missed it
by Ioannis Papadopoulos 23 Oct '12

23 Oct '12

http://pubby8.wordpress.com/2012/10/15/stack-based-template-metaprogramming… A small stack machine using templates.

2 2

[preprocessor] question
by Jorge Lodos Vigil 23 Oct '12

23 Oct '12

This is regarding to BOOST_PP_IS_NULLARY macro. I would like to use it with only 2 types of inputs: 1. Empty parenthesis: () 2. Plain C++ identifier within parenthesis: (identifier) With this input restrictions, is it safe to use BOOST_PP_IS_NULLARY in portable code that must be compiled in different platforms? Thanks in advance. Jorge

2 1

[graph] strange behaviour of relax
by Jan Hudec 23 Oct '12

23 Oct '12

Hello All, Writing special variant of dijkstra's algorithm I wanted to reuse the `relax` function (from boost/graph/relax.hpp) that is used by dijkstra_shortest_paths_no_color_map. And I've notices what I think is mismatch in behaviour between relax and dijkstra_shortest_paths_no_color_map. When the graph is not oriented, the relax function will consider decreasing distance of either target (obiously) or source. However it returns the same true in both cases, so the caller does not know which vertex was updated and the dijkstra_shortest_paths_no_color_map does not expect having to update the source at all. It shouldn't happen, but than why is that condition there? It appears to me that one or the other is wrong. But I don't know the code well enough to tell which. Regards, Jan -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

3 2

Re: [boost] [system] symbol visibility and GCC vs. Clang
by Mathias Gaunard 23 Oct '12

23 Oct '12

On 22/10/12 23:29, James Walker wrote: > When trying to link a bunch of libraries on OS X, I got this linker > warning: > > ld: warning: direct access in > boost::system::system_error::~system_error() to global weak symbol > vtable for boost::system::system_error means the weak symbol cannot be > overridden at runtime. This was likely caused by different translation > units being compiled with different visibility settings. > > As far as I can tell, everything is compiled using the flags > -fvisibility=hidden -fvisibility-inlines-hidden. > > I'm wondering whether the problem is that some of the libraries were > built using gcc and some were built using Clang. In > boost/system/system_error.hpp, the declaration of > boost::system::system_error is decorated with BOOST_SYMBOL_VISIBLE. In > boost/config/compiler/gcc.hpp, BOOST_SYMBOL_VISIBLE is defined to be > __attribute__((visibility("default"))), whereas > boost/config/compiler/clang.hpp does not define BOOST_SYMBOL_VISIBLE. This looks like a significant bug, POSIX-style symbol visibility doesn't work with Clang. Please file a ticket. Forwarding to developers mailing list.

1 0

[tti] documentation in trunk
by Vicente J. Botet Escriba 23 Oct '12

23 Oct '12

Hi, I would like to read the doc of Boost.TTI but there are a lot of broken link in trunK; I have tried to build the doc but I get the following error bjam warning: mismatched versions of Boost.Build engine and core warning: Boost.Build engine (bjam) is 2011.04.00 warning: Boost.Build core (at /Users/viboes/boost/trunk/tools/build/v2) is 2011.12-svn Building the tti docs with automatic index generation disabled. Try building with --enable-index. ...patience... don't know how to make <p../../../bin.v2/libs/tti/doc/darwin-4.2.1/debug-object(xinclude-scanner)@1283>tti.xml Could you solve this issue? BTW, when do you plan to go to the release branch? Thanks, Vicente

2 4

[graph] dijkstra_shortest_paths_no_color_map works by accident
by Jan Hudec 22 Oct '12

22 Oct '12

Hello, I've been writing custom version of Dijkstra's shortes path algorithm because of specific constraints and I was using the dijkstra_shortest_paths_no_color_map function as template. And I've notices that it only works by accident: The inner loop (I've had 1.51, but there is no change in trunk) goes like this: BGL_FORALL_OUTEDGES_T(min_vertex, current_edge, graph, Graph) { // [visitor, negative check, not interesting now] // Extract the neighboring vertex and get its distance Vertex neighbor_vertex = target(current_edge, graph); Distance neighbor_vertex_distance = get(distance_map, neighbor_vertex); bool is_neighbor_undiscovered = !distance_compare(neighbor_vertex_distance, distance_infinity); Considering the case when the vertex is not discovered: neighbor_vertex_distance = infinity is_neighbor_undiscovered = true // Attempt to relax the edge bool was_edge_relaxed = relax(current_edge, graph, weight_map, predecessor_map, distance_map, distance_weight_combine, distance_compare); Since any sensible distance is less than infinity, the relax function will return *true*: was_edge_relaxed = true if (was_edge_relaxed) { vertex_queue.update(neighbor_vertex); So this gets executed. But the vertex is not in the queue! OOPS! The code however executes successfuly. This is because the index_in_heap property map given to the d_ary_heap_indirect is initialized to 0. But 0 is correct index pointing to top and updating top is a no-op. Correct "not-in-heap" value would be -1 (and that's what the queue stores in pop()). visitor.edge_relaxed(current_edge, graph); } else { visitor.edge_not_relaxed(current_edge, graph); } if (is_neighbor_undiscovered) { visitor.discover_vertex(neighbor_vertex, graph); vertex_queue.push(neighbor_vertex); Here finally comes the push. Obviously it should have been first. Curiously this visitor callback is called before the queue operations while the edge_relaxed above is called after. Is there any reason for this particular order of operations? (Obviously fixing the code would be easier if the order of callbacks didn't matter) } } // end out edge iteration Should this be fixed? Are there any risks doing so? -- Jan 'Bulb' Hudec <bulb(a)ucw.cz>

2 1

[release][chrono] Permission to disable a broken feature
by Vicente J. Botet Escriba 22 Oct '12

22 Oct '12

Hi, the version 2 of Boost/Chrono/IO introduce a bug on time_point<system_clock,D> i/o. There is an specialization for time_point i/o that I failed to test as the test was commented. When I have uncommented the test I have see that this was not really checked never. I have needed to fix a lot of things in the specific code, but I don't reach to make it work yet. As the release date is close I would prefer to disable the specialization for release 1.52 and take the time to fix the errors for the next release. I have created two tickets on Trac. https://svn.boost.org/trac/boost/ticket/7546 - time_point<system_clock> output version 2 fails to compile https://svn.boost.org/trac/boost/ticket/7547 - time_point<system_clock> input version 2 fails to compile Here you can see some of the modifications that I have since yesterday. The commit I have done today disable the feature. Of course I will need to document the limitation. They are mark as showstoppers, but as the default chrono/io version is yet version 1 the user should not be blocked. Another possibility is to disable the new chrono/io version 2 as a whole. Could I count with the permission to merge the code to disable the feature (https://svn.boost.org/trac/boost/changeset/81045) once the regression tests are run? Thanks, Vicente

2 4

[rfc] Java Binding library
by Felipe Magno de Almeida 21 Oct '12

21 Oct '12

Hello, I'm developing a Java Binding library and would like feedback so that it may in the future become a boost library. I know quite well the luabind library and from reading the documentation and tested a few toy examples the boost.python library. Though they are very high quality libraries, they have one thing in common that doesn't apply to Java: dynamic typing (Lua actually just uses tables). So just using a closed set of types for function prototypes is not enough to convey the information necessary to create the function descriptors for JNI binding, and constructing classes in Java with all Java/Lang/Object as parameters is not at all very useful. So, I thought that allowing the user to actually create classes in C++ that represents these objects in Java would make for these differentiations in function signature, and actually bind Java classes to C++. And for a few simple examples these worked well. For example (the syntax is not at all fixed yet): struct PrintStream_class : jvb::extends<PrintStream_class, FilterOutputStream_class> { PrintStream_class(jvb::environment e) : base_type(e, "java/io/PrintStream") {} }; struct PrintStream : FilterOutputStream { typedef PrintStream_class class_type; typedef jvb::method_overload <void(bool) , void(jvb::char_) , void(jvb::array<jvb::char_>) , void(jvb::double_) , void(jvb::float_) , void(jvb::int_) , void(jvb::long_) , void(jvb::object) , void(jvb::string) > print_overload; PrintStream(jvb::environment e, jobject obj) : FilterOutputStream(e, obj) , println(e, obj, "println") , print(e, obj, "print") , checkError(e, obj, "checkError") {} print_overload println; print_overload print; jvb::method<bool()> checkError; }; which could be used with the definition of System, et al, this way: int main() { jvb::jvm jvm; jvb::environment env = jvm.environment(); System_class system(env); system.out.println(env, "Hello World"); } Which is at https://github.com/felipealmeida/javabind/blob/master/demo/inheritance/inhe… The Hello World example is actually this: int main() { jvb::jvm jvm; jvb::environment env = jvm.environment(); jvb::jcl::java::lang::System::class_type System(env); System.out.println(env, "Hello World"); } This seemed fine, but it actually complicated a bit things when I start to expose classes in C++ to Java. This is the example that I'm trying to make work right now: struct hello_world { hello_world() { std::cout << "hello_world::hello_world" << std::endl; } void print() { std::cout << "hello_world::print Hello World" << std::endl; } }; int main() { jvb::jvm jvm; jvb::environment e = jvm.environment(); using namespace jvb::bind_placeholders; jvb::Class c = jvb::bind_class<hello_world> (e, "HelloWorld" , ( method(public_, "print", &hello_world::print) )); jvb::constructors<void()> constructor(e, c); jvb::Object object = jvb::new_<jvb::Object>(e, constructor); jvb::method<void()> print(e, object.raw(), "print"); print(e); } The problem here is that hello_world actually represents a 'peer class' in the JNI jargon. This peer class is instantiated by a native function and set into a member of the Java class as a long and this is then requested by other native calls (or just passed as parameter to the native function, by a helper java function) which then uses these peer classes as the native state of the Java class. But, this peer class doesn't represent its own class in Java, so, if I'm to use this Java class as parameter to some other function I can't really use this class. And for matters to be worse, jobject references, used for jvb::object, can be of various types and the most used jobject reference can't really be saved, because it would not be valid later, or if I make it valid (global reference) the it would pin the object and leak. Has this problem been dealt with in another language binding? Is it really important not to lose static information? Does another technique would fit better Any input would be greatly appreciated. If you have any examples of how the library should look like syntactically for some use-cases, that would be helpful too. I'm completely rewriting the library right now, so the source code can be a bit confusing right now, also, most things are still hardcoded for the evolution and to test how certain solutions might work together, as a proof-of-concept. The library's source code is available at https://github.com/felipealmeida/javabind. Thanks for the attention, -- Felipe Magno de Almeida

1 0

[thread] request for interest in new c++1y features
by Vicente J. Botet Escriba 21 Oct '12

21 Oct '12

Hi, I would like to include some of the new thread/future proposed features included in N3428: A Standard Programmatic Interface for Asynchronous (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3428.pdf) What do you think? Best, Vicente

3 7

[optional] warning removal
by Vicente J. Botet Escriba 21 Oct '12

21 Oct '12

Hi, can I commit this simple patch Best, Vicente svn diff ../../../boost/optional/ Index: ../../../boost/optional/optional.hpp =================================================================== --- ../../../boost/optional/optional.hpp (revision 81020) +++ ../../../boost/optional/optional.hpp (working copy) @@ -890,12 +890,12 @@ 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>

3 3

[thread] Integration with Chrono and DateTime (was: [release][1.52] Release Notes)
by Andrey Semashev 20 Oct '12

20 Oct '12

On Oct 13, 2012 12:10 AM, "Vicente J. Botet Escriba" < vicente.botet(a)wanadoo.fr> wrote: > > Le 12/10/12 21:51, Andrey Semashev a écrit : > >> On Oct 12, 2012 8:35 PM, "Vicente J. Botet Escriba" < >> vicente.botet(a)wanadoo.fr> wrote: >>> >>> Hi, >>> Why you don't want to depend on Boost.Chrono? >> >> Because I want to minimize dependencies (especially, binary build >> dependencies). > > Me too, I want to limit dependencies :) Fair enough. Perhaps, we could absract away Boost.Thread from both libraries? Seems like a logical solution for a case like this. For example, Boost.Thread could define an internal interface for integrating with time units from different libraries. Chrono and DateTime would support this interface, and Boost.Thread could also provide the necessary glue for std::chrono integration. I think, Boost.Thread could use its own time units internally and use ADL-found functions to convert from other time units. Boost.Thread will not depend on either timing library then. Does this look viable? >> Unlike Boost.DateTime, Boost.Chrono is not needed by my library, so this >> would really be a false dependency. > > If you don't need time related thread facilities you could set BOOST_THREAD_DONT_USE_CHRONO. Would this work for you? Yes, that's what I'm doing now. I'm using DateTime units for timed functions. >> I understand that the dual interface adds more redundancy but does it >> really require active maintenance? The code has been there for quite some >> time, it's well tested and doesn't require additional work. >> >> > Any addition code has its influence on how the library could evolve. I really would prefer to remove these interfaces for Boost 1.56. I think that 1 year and a half is enough time to move to the new interface. Then I think library decoupling is the right way even more.

5 15

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