Re: [avrdude-dev] code restructuring - using C99 or not?

[Hannes Weisbach]

> The reason of my refactoring is to have a shared lib that can be used
> e.g. in Python. To do a direct fprintf in a library is not a good
> idea. I added a hook where the application can register a callback
> function which is in the style of vfprintf. In avrdude main.c then the final 
> fprintf is done ... and if I want to do it Python, the messages can easily go 
> to a Tkinter window after registering the python callback.
My reason was just less typing and save a level of indentation ;)
> 
> >>
> >> Which one would be the preffered solution a) or b).
> > b).
> >
> > Also, I would propose that the macro prints the programmer name (if >the 
> > message is generated by a programmer) or "avrdude: " if it is >generated by 
> > "general" code.
> 
> This is a good idea, that the module identifies itself within the generated 
> message.
> 
> I also added a severity level, which is currently INFO, WARNING, ERROR
> and is also given to the callback function (so the callback implementer could 
> colorize or filter the output).
Maybe it is a good idea to introduce such levels in avrdude in general?
For example instead of writing
if(verbose > x) // x is a developer-defined constant, for example 2
  fprintf(stder, ...);
one could write
if(verbose > WARNING)
...
In my opinion, this makes code much easier to read and it would be clear(er) to 
(new) developers which verbosity level to use for a certain message.
> 
> > What do you think about printing the function name and line number by
> >directly by the macro, if the verbosity level is high enough (3 or so)?
> 
> Definitely I would like this idea. Is there a way to evaluate the current 
> function name automatically by the preprocessor? (Like the __LINE__ or 
> __FILE__ macros do?)
Yes: __func__.
> 
> 
> On 20.07.2012 20:40, Weddington, Eric wrote:
>> Why do you need to encapsulate these statements behind a macro? (That then 
>> has to be written and then interpreted by developers when modifications are 
>> made...)
> 
Well, there is no "need" as such. Apart from the argument with the usage in a 
library, I would argue less code. I don't think understanding of such a macro 
by developers poses a problem, if it's intention is documented in the source 
code (or if it is named properly).
Do you have other concerns than developers having to familiarize themselves 
with the code?
> 
>> What advantages does it bring, other than shorter typing?
> 
> Beside shorter typing, a macro is a method where you can
> decouple things, well it might be regarded as german overengineering,
> but thats why I was asking.
I think we should discuss in more detail, what is done in a macro and what is 
done in the callback.
Obviously, providing line numbers and function name (if desired) requires to be 
put in a macro.
Coloring, if desired, could be implemented in either a callback 
("print-function") or a macro.
I don't know print the programmers name, though.

Cheers,
Hannes