Karsten Blees <karsten.bl...@gmail.com> writes: >> Because I had an experience under my belt of a painful refactoring >> of "the_index" which turned out to be not just a single array, I >> simply suspect that the final data structure to represent a "set of >> config-like things" will not be just a single hashmap, hence I do >> prefer to have one layer of abstraction "struct config_set", which >> would contain a hashmap and possibly more. Doesn't "is the hashmap >> initialized" bit belong there, for example? > > Would an additional > > int hashmap_is_initialized(constr struct hashmap *map) > { > return !!map->table; > } > > API help? (Note that hashmap_free() already does memset(0), so the > usual notion of "zero memory means unitialized" applies).
It may remove the need for the separate "hashmap_initialized" bit that was implemented as a file-scope global in the patch. I however am not convinced that it will be the _only_ thing other than the hashmap we would need to use to keep track of the in-core "set of config-like things", and usually a blanket statement "these are the only thing we would ever need" tends not to hold for long, so... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html