Hi Colin, > So far, the only extra supporting code I've felt the need to write > around Gnulib's container types consists of (a) equals/hash/etc. > implementations for relevant types
Yes, these are definitely something the application package needs to provide. > (b) convenience wrappers for creating lists of strings and suchlike Yes, it would really be good to have such wrappers automatically generated (like the compiler does for C++, when you have templates). Maybe a concept of a "parameterized gnulib module" would help? It would create source code by substituting application-provided tokens into gnulib-provided template code. > (c) iteration macros; How do your macros look like? I haven't provided such macros, because all ways to define such macros I can imagine have major drawbacks. Maybe yours are better? > For what it's worth, I was taking things like gl_list_iterator_next's > handling of nodep as a partial model. It's clear that it's sometimes > acceptable to have NULL checks in similar situations in this code Apparently I didn't think as strongly at the NULL checks when I implemented these. Or maybe I found it hard to explain why we would have 2 functions gl_list_iterator_get_next (which produces the value) and gl_list_iterator_next (which ignores the value). > (d) map/omap "contains" checks. The last of those feels like it's filling > in a gap in the interface > ... > the only thing I've noticed in the > various containers APIs that really feels like an interface omission OK, I can add such a function, as an inline function in gl_map.h and gl_omap.h. > choice of function name (I prefer "contains" over "entry_exists"). 'gl_map_contains'? Hmm, one would expect that it takes the key and the value as arguments. 'gl_map_entry_exists'? Likewise. Probably I'll name it 'gl_map_haskey'. Bruno
