RE: what exactly happens with string casts?
- From: William Adams <william_a_adams@xxxxxxx>
- To: <luajit@xxxxxxxxxxxxx>
- Date: Wed, 16 May 2012 13:15:40 +0000
Thanks for the responses. That pretty much validates my assumptions.
One thing that might be really neat is to create a lua string without copying
the data.
so, if I do the following:
bytes = ffi.new("char[256]")
... fill in bytes with string data
luastring = ffi.string(bytes, strlen(bytes))
ffi would do the needful in creating the proper lua string structure, calculate
the hash, etc, but would NOT copy the bytes, but instead use the allocation
that I already did as the storage.
It's basically the analogue of what happens when you do a cast. Nothing gets
copied, but you get to leverage what's in the Lua world.
that would be the cat's meow.
It might not be "safe", because I can change the buffer underneath, after the
string hash has been calculated. But, that's no worse than what I can do once
I get a pointer to a string through a cast is it?
If this facility existed, I could then easily use the string.match function on
a buffer I get from the network, without copying the buffer, and that would be
wonderful.
-- William
===============================
- Shaping clay is easier than digging it out of the ground.
http://williamaadams.wordpress.com
http://www.thingiverse.com/WilliamAAdams
https://github.com/Wiladams
----------------------------------------
> Date: Wed, 16 May 2012 14:14:51 +0200
> From: mike-1205@xxxxxxxxxx
> To: luajit@xxxxxxxxxxxxx
> Subject: Re: what exactly happens with string casts?
>
> Arran Cudbard-Bell wrote:
> > On 16 May 2012, at 12:45, Mike Pall wrote:
> > > A cast NEVER makes a copy of anything. It converts one type of
> > > pointer to another. And a Lua string is implicitly treated like a
> > > "const char *" pointer to its first character.
> >
> > This is pretty much the same as the implicit operation that
> > occurs when you pass a Lua string to an FFI function that
> > requires a char *? Or does the string get copied to some
> > intermediary buffer?
>
> ["const char *", but not "char *".]
>
> The implicit Lua string -> "const char *" conversion works the
> same in all contexts. Whether that's a C function argument or a
> struct field you're storing to, etc.
>
> Aggregates are never copied implicitly.
>
> [
> E.g. if you reference an element in an array of structs, no copy
> is performed! You get a reference (C++ '&') to the start of the
> struct, which behaves exactly like a struct object (unlike a
> pointer to a struct, as we've recently discussed).
> ]
>
> > Is there any way to avoid interning the string, but still pass
> > it as arguments to standard Lua functions (i'm guessing no)? For
> > example using the build in io.write functions to write out the
> > contents of a char array?
>
> Well, no. The problem is that all standard library functions that
> consume a string argument only expect a single argument. But for
> cdata you'd need to pass both a pointer and a length argument.
>
> But since you're concerned about performance, you might as well
> call the C functions fwrite() or even write()/WriteFile() and
> pass the buffer and length.
>
> [
> I've tried to eliminate the temporary string interning for JIT-
> compiled code, e.g. io.write(ffi.string(p, len)). But it'd only
> work where the string interning and the C call are very close
> together, i.e. not in all contexts. So I didn't bother.
>
> It's hard to derive that the contents of 'p' aren't modified by
> unrelated C calls, e.g. the fwrite() itself. And thinking about
> it, the fwrite() may write to a memory buffer (some C libs have
> this feature) and p might be a pointer to that buffer. Ugh.
> ]
>
> --Mike
>
Other related posts:
