Re: io_trace

al davis <[email protected]>
Newsgroups gmane.comp.gnu.gnucap.devel
Message-ID <[email protected]>
On Fri, 5 Aug 2016 20:58:53 +0200
Felix Salfelder <[email protected]> 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.