Boost logo

Boost :

Subject: Re: [boost] JNI library
From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2012-06-28 09:05:45

On Thu, Jun 28, 2012 at 9:14 AM, Dave Abrahams <dave_at_[hidden]> wrote:
> on Tue Jun 26 2012, Felipe Magno de Almeida <> wrote:
>> On Fri, Jun 22, 2012 at 3:02 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>>> on Sun Jun 17 2012, Felipe Magno de Almeida <> wrote:
>> [snip]
>>>> This class file could be generated by the javabind library, but I
>>>> thought it would be overkill for what I needed and might actually make
>>>> the loading time longer, since it would have to be generated.
>>> You don't have to generate it at (java) runtime.
>> Do you mean what I already do: generate it by writing java code and
>> compiling. Or at compile-time? Or something else?
> I mean that you can build the generation of the Java code into the
> capabilities of your binding library.  Doesn't the C++ binding
> description contain all the information you need to generate the Java
> code?  If so, you could generate it from C++,

Yes it does, and yes I can. But generating from C++ might be costly
at initialization-time if I had to do it for hundreds of methods, which is
the case for me. I will give this a try next week and see if it really
performs wells.

If you know how to create a contiguous buffer composed with data
from c-style strings strictly at compile-time without constexpr that
surely would solve any problems I could have with initialization time.

You may know how from this code:

  function("Foo", &my_class::foo)
  , function("Bar", &my_class::bar)

I can create a contiguous buffer of size N with these strings without
copying at runtime? It is easy to learn the sizes at compile-time, which
eliminates strlen calls and I can at least allocate the buffer at compile-time,
but I really don't know how to avoid copying.
Or the compiler just optimizes these copies away at compile-time?

> --
> Dave Abrahams
> BoostPro Computing

Thanks in advance,

Felipe Magno de Almeida

Boost list run by bdawes at, gregod at, cpdaniel at, john at