Hello Andrei, we need it right now becuase of the current layout. And imo that's a design flaw which is why i brought it up here with an option on how to change it after discussing it. Having two different layouts allows us to not need to a pointer to the key string plus eventually allocate memory twice. But this also forces us to copy the key struct in the apply func that gives access to the key for every element.
If we have the layout proposed by me we could also provide an apply version that easily gives access to the element, the key and a parameter. Having to use the following to access the key, made most cases do the iteration inplace. Just because the following is pretty slow for two reasons. First va_args stuff is potentially slow an some machines and second having to allocate a tsrm key on some machines is especially slow. typedef int (*apply_func_args_t)(void *pDest, int num_args, va_list args, zend_hash_key *hash_key); ZEND_API void zend_hash_apply_with_arguments(HashTable *ht, apply_func_args_t apply_func, int, ...); Since normally a struct can be used very easily and efficient, where multiple arguments would be used otherwise. The next layout would imo be a nice addition: typedef int (*apply_func_key_t)(void *pDest, zend_hash_key *hash_key, void *argument TSRMLS_DC); ZEND_API void zend_hash_apply_with_key(HashTable *ht, apply_func_key_t apply_func, void *argument TSRMLS_DC); This design change suggestion of course goes especially to Andi/Zeev. marcus Thursday, March 16, 2006, 7:11:39 AM, you wrote: > On Mar 11, 2006, at 4:22 AM, Marcus Boerger wrote: > [snip] >> So now HashKey matches zend_hash_key just by pure reordering. > Why do we need both HashKey and zend_hash_key? > -Andrei -- Best regards, marcus -- PHP Unicode & I18N Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
