gnucap-devel
[Top][All Lists]
Advanced

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

Re: [Gnucap-devel] io_trace


From: al davis
Subject: Re: [Gnucap-devel] io_trace
Date: Fri, 5 Aug 2016 22:47:08 -0400

On Fri, 5 Aug 2016 20:58:53 +0200
Felix Salfelder <address@hidden> wrote:

> now theres gnucap-conf. starting to build things...
> 
> i have become used to a slightly different trace header (in -uf). not
> all changes make sense, but i think these (see traces branch on sv).

I saw that in -uf, was thinking of incorporating it.  So much to do!

> - catch stale traces. by defining trace* to ignore the arguments, a lot
>   of cruft will accumulate and make it harder to switch them back on.
>   also, unused variable warnings show up for variables that are used for
>   traces. my "solution" is to define inactive traces as
> 
>   #define trace(x) (1)?(void)(0):(void)(x),
> 
>   instead of nothing. this way, the compiler checks x, without actually
>   doing anything. maybe there is a simpler way, this one does not look
>   dangerous...

I see what you are doing, and as you say "does not look dangerous".  My
concern, that is easy to check, is if it has any impact on speed.

I also noticed your USE(x) macro.  For others reading the list ..  it
"uses" a variable, suppressing a warning "x is unused", which is
significant when x is used in a macro that may or may not actually use
it, like assert or trace.

> - use ostreams instead of printf. i have used this to debug non-numeric
>   objects, or matrices/vectors. this seems fully backwars compatible and
>   harmless to me. but useful.

.. was thinking of incorporating it, because it's a good idea.

printf here is only because of lingering code from when ACS,
predecessor to gnucap, was written in C.



reply via email to

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