- Boost - lists.preview.boost.org

[declval] non-ascii characters in declval.hpp
by Michel Morin 30 Oct '12

30 Oct '12

Hi Vicente, `utility/declval.hpp` contains a non-ascii character. I tried to fix this and make some improvements. Attached a patch that * removes a non-ascii character, * updates references to the C++11 standard, * fixes obvious oversights (e.g. `// common_type.hpp` --> `// declval.hpp`), * cleans up and reformats the comments (to the style you used in `add_rvalue_reference.hpp`), * renames the include guard macro (`BOOST_TYPE_TRAITS_EXT_...` --> `BOOST_UTILITY_`). May I commit it? Regards, Michel

2 2

[algorithm] non-ascii characters in boyer_moore.hpp
by Michel Morin 30 Oct '12

30 Oct '12

Hi Marshall, `boost/algorithm/searching/boyer_moore.hpp` contains a non-ascii character ("–", en dash) at line 37: 36: Explanations: boostinspect:noascii (test tool complains) 37: http://en.wikipedia.org/wiki/Boyer–Moore_string_search_algorithm Would it be better to URL-encode the dash as "%E2%80%93" rather than relying on `boostinspect:noascii`? Regards, Michel

1 0

Re: [boost] [variant] awkward recursion
by Balazs Arva 29 Oct '12

29 Oct '12

At this moment I'm developing a json library with similar approach. With variant I think the only way this: typedef boost::make_recursive_variant < int, unsigned int, long, unsigned long, float, double, bool, const char*, std::string, boost::recursive_wrapper<std::map<std::string, boost::recursive_variant_>>, std::vector<boost::recursive_variant_>, std::nullptr_t >::type value; typedef std::vector<value> array; typedef std::map<std::string, value> object; I did not find any better solution. However there is still one problem: I do not want to write down every numeric POD in tmpl parameter list. It is a major problem because value a=(unsigned int)5; could not compile. Do you have any advice? I would like do something like this: typedef boost::make_recursive_variant < any_pod_numeric_type, bool, const char*, std::string, boost::recursive_wrapper<std::map<std::string, boost::recursive_variant_>>, std::vector<boost::recursive_variant_>, std::nullptr_t >::type value; Balazs Arva

1 0

Boost.Process 0.5: Minor update
by Boris Schaeling 28 Oct '12

28 Oct '12

I've uploaded a new version of Boost.Process 0.5 to <http://www.highscore.de/boost/process0.5/>: - search_path() added which was called find_executable_in_path() in previous versions (Windows implementation changed quite a lot) - shell_path() added which returns the absolute path to a shell executable - set_args() added which is an initializer to pass command line arguments as a collection (with automatic escaping) - Minor bug fixes There is one more update planned to somewhat mitigate remaining cross-platform differences. Please keep the feedback coming (here on the mailing list or by email)! Boris

1 0

Interesting article on stack-based TMP
by Julien Nitard 28 Oct '12

28 Oct '12

Hi All, That article came out of reddit C++ section: http://pubby8.wordpress.com/2012/10/15/stack-based-template-metaprogramming… It looks like TMP made easy (finally !). I am not that sure it is though and was wondering if anybody had any comments on it. Regards, Julien

9 20

[Boost-build] Turn on _GLIBCXX_DEBUG with <runtime-debugging>on (was: Trivial issues have been neglected.)
by Matthew Chambers 27 Oct '12

27 Oct '12

I'm forwarding this from the boost-build list to get a broader perspective from boost users and probably also some Boost.Build users that don't monitor that list. How many agree with Steven that for <variant>debug: "The libraries that are built need to be ABI compatible with code that isn't compiled using Boost.Build." How many would sacrifice ABI compatibility in order for <runtime-debugging>on to actually do something for GCC? Thanks, -Matt > (2012/10/17 0:09), Matthew Chambers wrote: >> On 10/15/2012 11:29 PM, Steven Watanabe wrote: >>> AMDG >>> >>> On 10/15/2012 07:54 PM, Kohei Takahashi wrote: >>>> Hi all, >>>> >>>> Can anyone handle following two issues? >>>> >>>> <runtime-debugging>on does nothing for libstdc++... >>>> https://svn.boost.org/trac/boost/ticket/4589 >>>> >>> >>> This is /not/ a trivial issue. It may be easy to do, but: > > I understood about this is not trivial issue and I changed the subject. > > >>> a) _GLIBCXX_DEBUG was broken last time I tried it a few years >>> ago. It won't work with all versions of gcc. >> >> I've used it with 4.1.2 and it helped a lot to track down some >> mysterious failures. > I don't know about old releases but recents seem to work well for me. > Indeed, expects to work well and should work with all versions of gcc > if define it by default. > >>> b) Anything the changes the ABI of the compiled libraries needs >>> careful consideration and must be documented. The libraries that >>> are built need to be ABI compatible with code that isn't >>> compiled using Boost.Build. >> >> Is it really that important that debug builds be ABI compatible >> between disparate builds? I think it's reasonable to EXPECT trouble >> when linking a debug build to precompiled libraries. That is >> certainly the case on Windows. > > <define> is not propagated feature, that means to trigger unexpected > link failure or ABI breaking. I think that using <runtime-debugging> > make safely rather than <define>. > I think it is better that provides propagated feature (as > <runtime-debugging> or another) for such purpose at least. > > >>> c) <runtime-debugging>on is part of <variant>debug, but I don't >>> think _GLIBCXX_DEBUG is a standard part of debug builds with >>> gcc. >> >> What is a "standard" debug build with gcc? Most people would >> probably say -g and -O0 but that doesn't provide any real debugging >> support. >> >> I agree it's not trivial, but having a no-op runtime-debugging >> feature is cringe-worthy. It's as good as admitting that GCC (or >> rather, libstdc++) doesn't provide any "official" runtime debugging >> support which is unfair. >> >> In the spirit of upcoming elections, count this as a vote for >> turning on _GLIBCXX_DEBUG. :)

5 4

Relationship of Boost libraries to TR1 and C++11
by Dave Abrahams 27 Oct '12

27 Oct '12

I don't suppose anyone has written up the specific differences between Boost libraries like regex, bind and shared_ptr and their TR1 and C++11 counterparts? It would be great if the maintainers of libraries that were accepted could add a FAQ about that. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

1 0

BoostCon old videos
by Fernando Pelliccioni 27 Oct '12

27 Oct '12

Does anyone know where I can get the videos of previous years BoostCon? In particular I am looking for the following: "Cross-platform development with Qt and Boost" http://blip.tv/boostcon/joao-p-r-abecasis-cross-platform-development-with-q… Thanks and regards, Fernando Pelliccioni.

5 5

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

26 Oct '12

-------- Original Message -------- Subject: Re: [system] symbol visibility and GCC vs. Clang Date: Tue, 23 Oct 2012 10:40:42 -0700 From: James Walker <jamesw(a)frameforge3d.com> Reply-To: boost-users(a)lists.boost.org To: boost-users(a)lists.boost.org CC: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> Newsgroups: gmane.comp.lib.boost.user References: <5085BABE.9030609(a)frameforge3d.com> <50868205.6070508(a)ens-lyon.org> On 10/23/2012 4:39 AM, Mathias Gaunard wrote: > 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. OK, thanks. <https://svn.boost.org/trac/boost/ticket/7559> -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/>

2 1

[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