On 18 May 2015 at 01:48, Gabriela Gibson <gabriela.gib...@gmail.com> wrote:
> I made (for my branch) a color.c and a color.h, which can be
> handy if you're looking at a wall of text and want to spot
> something in particular without straining your eyes too much.
>
> It's easy to use:
>
> printf(MAGENTA "foo = %d" RESET, 5);
>
> will give you a nice 'foo = 5' magenta output. There's also
> stuff like blue("bar") which can be stuffed into other string
> functions.
>
> I wrangled it so that this feature can be turned on with a -D
> switch at compile time, ie, in CmakeLists.txt you can do:
>
> set(CMAKE_C_FLAGS "-std=c99 -D_GNU_SOURCE -g -fPIC -DCOLOR_ON=1")
>
> otherwise it's not going to show up.
>
>
> 1) Does anyone else other than me find this kind of thing useful?
>
I had not thought of it, but it is not a bad idea....just wonder where we
have output that benefit from coloring.
>
> 2) Is it portable?
>
I dont think so, for a number of reasons...I would not know how to do color
on a vt100 terminal in Linux or a dos prompt in windows.
>
> 3) If 1 & 2, would you enjoy this dev debugging feature being
> added?
>
Yes an no.
We should never use printf or similar in DocFormats, those are bound to
give problems in a number of cases.
I discussed earlier with Peter, the idea that we make some DEBUG_PRINT
macros. The macro should contain
an #ifdef DEBUG (or similar), but most importantly it should NOT do printf.
Instead it should print via a global function pointer (parameters like
printf). That way the main program can decide to use
printf or other functions (when we define the API, we will have a setup()
call, that could then included the function ptr.
Going down that road, would open up for LOG_PRINT, WARNING_PRINT,
INFO_PRINT as well.
I am very much for the MACROS, and against a direct printf. Colors is more
a portability concern.
rgds
jan i.
> G
>
> --
> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
>
