> However, I am not sure if I completely understand the other thing:
> do you prefer the solution by `N. Yoda' on StackOverflow (1) or the
> solution presented in `fterrors.h' (2)? (the latter uses the array,
> the former uses a switch/case)
I don't care. What I dislike is that the #... lines are *within* the
structure or array. There is no reason for it IMHO.
> 1. Switch/case is somewhat slower than array accesses but, IMO, the
> code is better to read (although I would exchange the lines with
> `FT_ERROR_START_LIST' and `FT_ERRORDEF' for improved readability)
> and it results in less code in total. Also no global variables.
>
> 2. Faster execution but IMO results in somewhat messier code. Also
> global variables.
Well, in (2) you can easily avoid a global variable if you use a
`static' read-only array local a function, e.g.,
const char*
FT_Error_String( FT_Error error_code )
{
#undef FTERRORS_H_
#define FT_ERRORDEF( e, v, s ) { e, s },
#define FT_ERROR_START_LIST {
#define FT_ERROR_END_LIST { 0, NULL } };
static const struct
{
int err_code;
const char* err_msg;
} ft_errors[] =
#include FT_ERRORS_H
...
}
> Efficiency is generally nice, however somewhat neglectable when it
> comes to debugging and really, it shouldn't be THAT much of a
> difference. Beauty lies in the eye of the beholder and I'll
> willingly agree to whatever you prefer.
I think it really doesn't matter. Using a switch statement is
probably less coding.
>> I can imagine to activate that automatically if tracing is active,
>> doing a call within the `FT_THROW' macro.
>
> Totally, why not :) However, for my (fuzzing) purposes, I'd
> appreciate it if `FT_Get_Error_Message' was independent of tracing
> since I usually don't use FreeType's tracing but do log all return
> values (esp. `if ( error != 0 ) ...').
Hmm. Then maybe
#define FT_CONFIG_OPTION_ERROR_STRINGS
if people want `FT_Error_String', and
#define FT_DEBUG_LEVEL_THROW
to make `FT_Error_String' be called in `FT_THROW'.
Werner
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
