lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 


Well... Do you think you can both eat and save the pie?  :/
Seriously, only the string type of the built-ins allows for variable length. If you don't want to grow Value, you'll need to do something similar to string. I bet it will make them immutable, as strings are.
So why not just use strings to store the 3D values? As binaries. You'll make C side code to create them of course: 

	local v= vec3d( 0.123, 1.234, 2.345 )
	print( v.x, v.y, v.z )		-- cannot be done since it's a string
	print( v )				-- would give binary garbage
And you cannot override add and sub and mul and... either. Meaning you want userdata. 

Case closed?  :))


Niklas Frykholm kirjoitti 11.6.2009 kello 12:30:


Yes, that would work and wouldn't be too tricky. The drawback is that
you would have to increase the size of the Value union to have room
for the biggest value type you wanted to support. Support for Vector3
would triple the size of Value and double the size of TValue. Which
would mean close to doubling the memory footprint of a running lua
application.

I'm targetting game consoles, where increasing the script memory from
30 MB to 50 MB or even 40 MB is a big deal... so I can't really go
that path.

// Niklas

2009/6/10 Asko Kauppi <askok@dnainternet.net>:
About the complex type, LNUM patch allows all Lua numbers to be complex (compile with LNUM_COMPLEX defined; C99 required for C complex support). 

The approach could of course be extended to making a native 3D vector
datatype, as well.

-asko


Niklas Frykholm kirjoitti 10.6.2009 kello 17:42:


2009/6/10 Duncan Cross <duncan.cross@gmail.com>:
On Wed, Jun 10, 2009 at 2:55 PM, Niklas Frykholm<niklas@frykholm.se> 
wrote:


2009/6/10 Olivier Hamel <evilpineapple@cox.net>:
Currently, if you want to create Complex or Vector3 type you have to 
do it as a table or a userdata. And if you do a serious ammount of
processing on them, the ammount of garbage generated by simple
arithmetic operations will soon put a significant strain on the
system. (You could use a pool of such objects, but that would mean
resorting to manual memory management with all its pains - especially 
when you are using it for something as simple as numbers.)


Perhaps I am misunderstanding, but if the pool is a table that has
been set to have weak values (i.e. its metatable's __mode field is set 
to 'v'), you should not have to do any manual memory management -
values that only exist in the pool will be eligible for garbage
collection.


My description was a bit short, but the whole point of having a pool
was to avoid generating garbage. (By using a free object from the
pool, rather than creating a new one, whenever a new object is
needed.) But this requires us to manually track which objects in the
pool are free or not (i.e., manual memory management).

If the objects in the pool are eligible for garbage collection, then
the pool doesn't really buy us anything. We will generate the same
ammount of garbage with the pool as without it.

// Niklas