[rrd-developers] [PATCH] Suggestion for API extension (rrd_dump)

[Tobias Oetiker]

Hi Benny,

Today Benny Baumann wrote:

> > the implementation in rrd_dump does not strike me as all that
> > elegant ...
> >
> I know it's not that elegant right now, especially because of the string
> literals ...

> > snprintf(somestring_buf, 255, ...)
> > cb(somestring_buf, strlen(somestring_buf), ...)
> >
> > apears about 1000 times ...
> > how about making a function or at least a #define to make this look
> > a bit less repetitive ...
> >
> I thought so too, but didn't do this for now to minize the changes in
> the patch to as trivial ones as possible. Adding 2 #defines to cancel
> out the repeatition should be the next step IMHO.
>
> #define cb_strlit(str) cb(str, strlen(str), user)
> #define cb_strbuf() cb(somestring_buf, strlen(somestring_buf), user)
>
> Those macros should do (as local shortcuts). Pushing the snprintf into
> the cb_strbuf macro isn't a good idea, because snprintf is a VarArgs
> function, thus unnecessarily complicating the macro if we would pass
> things through.

the goal is to have the boilerplate not hide what is happening in
the code ... whatever you deem best ...

> > also I think the new function should go into librrd.sym.in.in
> >
> I wasn't sure where this should be registered as I don't programm Linux
> libraries that often. Just add it there.
>
> But besides the rrd_dump_cb_r; what about adding the rrd_dump_opt_r
> function too? I mainly ask because when writing an API wrapper you often
> already have preprocessed information about what you want the final
> function call to do thus you can skip some unnecessary conversion steps
> in between.

well there is a greater scheme about makeing the api more c-ish ...
but this is not for 1.4 ...

looking forward to your next iteration.

cheers
tobi

> > cheers
> > tobi
> >
> Regards,
> BenBE.
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900