freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] Error Description Strings


From: armin
Subject: Re: [ft-devel] Error Description Strings
Date: Tue, 21 Aug 2018 10:56:00 +0200

>>>> https://stackoverflow.com/questions/31161284/how-can-i-get-the-corre
>>>> sponding-error-string-from-an-ft-error-code
>>>> 
>>>> is the best solution
>>>
>>> It is, but the code formatting in the link is extremely ugly and thus 
>>> hard to read and understand.
>> 
>> What don't you like about the formatting?
>
> Indented cpp lines!  AFAIK, the `#' should always be on the first line.  I
> also don't like that the cpp statements are put into the array, making it
more
> difficult to grasp what's going on.

Agreed with `#'.  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)

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.

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.

>>>> and/or if I (or someone else) should add a function like `strerror'
>>>> to FreeType's API?
>>>
>>> Not necessary, I believe.
>> 
>> Am I the first (or third) person to request/use that?
>
> IIRC, yes.

That's interesting;  I use `strerror' (and equivalent functions/methods in
other libs and languages) sooo much :D

>> I believe such a function (that minimises boilerplate on FreeType's 
>> users' end) would be nice when using FreeType in combination with 
>> loggers since strings are definitely easier to review/debug for humans 
>> than numbers.  How about a default-no-but-optional-yes-macro in 
>> `ftoption.h'?
>
> I don't object.

Thank you :)

> Do you want to provide a patch?

I do! :)  Just finishing fuzzing the bitmap handling API first, but right
after that! :)

> 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 )
...').




reply via email to

[Prev in Thread] Current Thread [Next in Thread]