- Boost - lists.boost.org

[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