Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 2:19 PM +0200 10/25/03, Leopold Toetsch wrote: >>Currently there is no simple way, to packout a Key that has number >>or string key members. PackFile_Constant_pack() for PFC_KEY does a >>linear lookup (find_in_const) to get at the index of the string or >>number in the constant table. This is really ugly.
> I'd always assumed that key constants, when being reconstituted from > the bytecode files, would just get strings built for them. Going with > the constant table offset works, but it has the issue of not being > able to pass keys across bytecode segments and needing entries made > in the constant tables for dynamically created keys. Constant keys refering to constant string (or number) items can't cross bytecode borders. I'm speaking of set P0, P1[I0;"key";"bla"] The key items for "key" and "bla" have to be in the same constant table. They can't be shared, because to generate such a key, you first have to generate "key" and "bla" constant string entries, which are referenced in the composite key by *index* (and might already be string constants with an assigned index). But on unpack, the key components take real strings. That effectively prohibts their packing again except with this ugly hack: 'where is the constant index of a string looking like "bla"'. > The lack of the string keyed variant is on purpose. Or, rather, the > _int variant was a fast optimization put in to drop the overhead for > array lookup. My assumption was, at the time, that hash lookups were > expensive enough that there wasn't enough win in a shortcut to > justify the extra space in all the vtables. And the assumption now is ? :) WRT vtable space: Please look at currently totally unused _same variants - not speaking of some _keyed :) leo
