Dan Sugalski wrote:At 11:57 AM +0200 6/14/04, Leopold Toetsch wrote:
1) Is there any good reason to start now malloc(3) based array classes? This leads to code duplication for all the utility vtable entries (like C<splice>). F<src/list.c> can deal with all types already.
list.c's pretty inefficient for most array usage. It's good for mixed-type, sparse, or really big arrays, but for normal arrays it's overkill. A big wad of memory's just fine there.
Well, yes. It depends on the usage of the PMC, which isn't known. What about shift/unshift? Are these allowed for fixed sized arrays?
Given that they change the size of an array... no.
I'd vote for optimizing list.c for the "small usage pattern" and switch to a different strategy for big arrays.
I wouldn't. list.c is designed for a different set of usage than the common array. Making it handle both common "wad of memory filled with a single type" arrays and the much-less-common "sparse array of multiple types" arrays doesn't make much sense.
Better to have the array have the needed smarts to upgrade itself to the more heavyweight array type if it really needs to.
Anyway, the patch #30245 Resizable*Array implements these arrays on top of fixed size.
So? I'm well aware that the implementation is suboptimal. Hell, the commit message and the messages on the list make that clear. That really, *really* doesn't matter for this. The point here is to get the types in, get their behaviour correct, and nail them down as guaranteed. How they do their thing is entirely irrelevant to that.
2) What's the difference between *PMCArray and *BooleanArray?
The PMC arrays hold PMCs. The Boolean arrays hold true/false values only.
Then it should really store just one bit instead of a word.
So fix it if you want. This is first cut code. There's plenty of time to optimzie it later.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
