Re: Patch for Review: JvGetStringUTF and JvTempCString

[Mohan Embar <gnustuff at thisiscool dot com>]

Hi Bryce,

>In this case (natFile*), I think there is a better approach. Since the 
>path of a given File object never changes, we can cache the path in UTF 
>format when each File object is constructed.

>(setUtfpath could just as well be implemented in Java code, though the
>native version is probably a little more efficient).

If you do this in Java instead of natively, the same code can be
leveraged for the Win32 implementation as well :).

Off-topic: there is also another issue with the file implementations
that could be folded in with your idea:

http://gcc.gnu.org/ml/java-patches/2003-q2/msg00328.html

>I do agree that we need a string-conversion solution for CNI that is 
>simpler to use than what we have now. But we need to think carefully 
>about what is the most simple and useful way to do it - once people 
>start to use these functions there is no going back!

I was pretty content with the _Jv_TempUTFString (a.k.a JvTempCString)
approach. In one line, it addresses a common need, uses stack-based allocation
for the majority of cases and also handles the heap-based fringe cases where
a larger buffer size is needed, and uses the stack-based destructor
to transparently do any necessary cleanup. (Don't you wish Java had
stack-based destructors? (Sound of harp music as Mohan lapses into a
daydream....)) The implementation may not be perfect, but I'm scratching
my head as to a more simpler or useful approach....

>Its also worth remembering that the stack-allocation tricks we use in libgcj
>are a special case because in these places we are willing to sacrifice a 
>little simplicity for efficiency - but realistically, most people want 
>ease of use more than absolute efficiency, so might be happy with a 
>function returning, say, a malloc() or GC allocated, null-terminated 
>char *.

For me, the efficiency that the highly probable stack-based allocation of
this helper class could give me is icing on the cake. More important for me was
that it is easy to use:

- a malloc-ed() temporary string has to be freed sometime
- a GC-allocated string seems to me to needlessly bring extra GC
  bookkeeping into the picture when we know that we can free it
  within the method

Regardless of the underlying implementation (which could also be tweaked
and improved upon as time goes on), I see the benefit in encapsulating
this by a C++ class. Yet I sense a hesitation on your part which I'm
not fully understanding. I appreciate the effort you're taking to discuss
this with me.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/