3 ms·
Yeah, when you can't afford the cache misses I understand that you would pass by value. But often, these things are done as premature optimisations. We can alwa
by yawaramin 9y ago
Yeah, when you can't afford the cache misses I understand that you would pass by value. But often, these things are done as premature optimisations. We can always expose a struct's definition later; but we can't hide it once it's exposed.
I agree with your API redesign, in fact if we forget about trying to do OOP we would get IMO even nicer design:
typedef struct set_t* set;
typedef void* set_elem;
set set_new(void);
void set_free(set);
set_elem set_add(set, set_elem);
set_elem set_find(set, set_elem);
set_elem set_drop(set, set_elem);
int set_contains(set, set_elem);
Edit: hiding the pointer in the typdef because if we later decide to expose the set struct, we minimise the required changes to the API.
- kgabis 9y agoHiding pointer behind a typedef is a terrible idea (like non-const reference arguments in C++). You never know if something you pass into functions could be modified by them or not. I'd much rather change every place in code where set was used than deal with code that hides such important information.
- yawaramin 9y agoHa, I knew someone would say this ;-) You never know, that is, unless you just follow the type to its declaration and find out in like a couple of seconds. A modern IDE should just show the typedef on hover.
- Too 9y agoWith that argument you might as well redeclare everything with unexpected macros, your ide will do macro expansion on hover anyway. Or why write descriptive function names at all? Ctrl-click to view the implementation of the function is just one click away... Typedef pointer is a huge anti pattern.