On Fri, 5 Aug 2016 20:58:53 +0200 Felix Salfelder <fe...@salfelder.org> 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. _______________________________________________ Gnucap-devel mailing list Gnucap-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gnucap-devel
