Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
soc:2009:lynusvaz:journal:week10 [2009/08/02 10:48] lynusvaz |
soc:2009:lynusvaz:journal:week10 [2009/08/02 10:50] (current) lynusvaz |
||
|---|---|---|---|
| Line 66: | Line 66: | ||
| * I had some problems with passing the stack to a function. The type information is held in the union, but actually passing the union to a function needs to have the data type clearly defined. So, I passed only a pointer to a struct stack, which removed the type information. | * I had some problems with passing the stack to a function. The type information is held in the union, but actually passing the union to a function needs to have the data type clearly defined. So, I passed only a pointer to a struct stack, which removed the type information. | ||
| * Hence, I made the STACK_PUSH macro take the type of the new element, and call the push_stack function with the sizeof(type) argument. | * Hence, I made the STACK_PUSH macro take the type of the new element, and call the push_stack function with the sizeof(type) argument. | ||
| - | #define PUSH_STACK( _stack, _type ) ( _type * ) stack_push ( _stack, sizeof ( _type ) ) | + | |
| + | #define PUSH_STACK( _stack, _type ) ( _type * ) stack_push ( _stack, sizeof ( _type ) ) | ||
| This will retain the type information without the union, but it requires the user to know the type of element being pushed, and this may lead to mistakes. This stack implementation seems to add around 135B to the uncompressed code. | This will retain the type information without the union, but it requires the user to know the type of element being pushed, and this may lead to mistakes. This stack implementation seems to add around 135B to the uncompressed code. | ||
