On Fri, Aug 21, 2020 at 01:51:57PM -0700, Elijah Newren wrote:
> > I think wrapping this kind of hackery is worth doing.
> >
> > You'd be able to use put() as usual, wouldn't you? It never deallocates
> > the util field, but just returns the old one. And the caller knows that
> > it's really an int, and shouldn't be deallocated.
>
> You can use put() as normal, if you don't mind the need to explicitly
> throw in a typecast when you use it. In fact, strintmap_set() does no
> more than typecasting the int to void* and otherwise calling
> strmap_put().
Yeah, I think hiding the type-casting is worth it alone. I was just
confused by your remark.
> I initially called that strintmap_put(), but got confused once or
> twice and looked up the function definition to make sure there wasn't
> some deallocation I needed to handle. After that, I decided to just
> rename to _set() because I thought it'd reduce the chance of myself or
> others wondering about that in the future.
Yeah, I'd agree that is a much better name. Since there's an "incr",
having a specific "set" makes it clear that we're overwriting.
> > struct strintmap {
> > struct strmap strmap;
> > };
> [...]
> I like this idea and the extra safety it provides. Most of strintmap
> is static inline functions anyway, adding a few more wouldn't hurt.
OK. Then I guess we can't cheat our way out of picking a name with
strmap_getint(). :)
-Peff
