#if vs #ifdef

#if vs #ifdef

[Rob Browning]

The GNU Coding Standards suggest always #defining a symbol to a value
and using #if tests rather than either defining or not defining that
symbol and using #ifdef or #ifndef.  i.e. instead of "#define FOO",
use "#define FOO 1", and use "#define FOO 0" rather than not defining
it at all.

One reason for this recommendation is that they then encourage you to
write code like this:

  if (SCM_HAVE_ARRAYS)
    {
      ...

rather than using #if/#ifdef/etc. at all.  Their argument is that all
reasonable compilers will generate the same code either way, and using
C code rather than the preprocessor can substantially improve the
readability of the code and allow the C compiler to do more thorough
analysis of all code paths.

Thoughts?  Since I just added new public defines, this seems a good
time to ask.

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: #if vs #ifdef

[tomas]

On Thu, Mar 27, 2003 at 12:18:08AM -0600, Rob Browning wrote:
> 
> The GNU Coding Standards suggest always #defining a symbol to a value
> and using #if tests rather than either defining or not defining that
> symbol [...]

So this boils down to ``use if() wherever possible, else use #if''.

Makes a lot of sense to me.

Regards
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: #if vs #ifdef

[Dale P. Smith]

On Thu, 27 Mar 2003 00:18:08 -0600
Rob Browning <rlb@defaultvalue.org> wrote:

>                                              Their argument is that all
> reasonable compilers will generate the same code either way, and using
> C code rather than the preprocessor can substantially improve the
> readability of the code and allow the C compiler to do more thorough
> analysis of all code paths.

I agree that nested #if's are a horrible thing to wade through, and it
makes sense to do this.  On the other hand, aren't there modes in emacs
that allow you to hide the #if'ed out code?  That would improve
readability far more than if (..).

I don't understand how it better for the compiler though.  I would think
using #if's effectively edits the code out of the way before the
compiler has a chance to look at it.  Using if (..) gives the compiler
useless work to do.  How is theis better?

-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith at altustech dot com     | http://cleveland.lug.net
440-746-9000 x239               |


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: #if vs #ifdef

[Dale P. Smith]

On Thu, 27 Mar 2003 16:26:12 +0100
tomas@fabula.de wrote:

> On Thu, Mar 27, 2003 at 07:48:05AM -0500, Dale P. Smith wrote:
> > I don't understand how it better for the compiler though.  I would think
> > using #if's effectively edits the code out of the way before the
> > compiler has a chance to look at it.  Using if (..) gives the compiler
> > useless work to do.  How is theis better?
> 
> The `iffed-out' code gets shaken by the compiler on a regular basis
> and some silly bugs get spotted earlier...

Ahhh.  Good point.

-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith at altustech dot com     | http://cleveland.lug.net
440-746-9000 x239               |


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: #if vs #ifdef

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> Thoughts?  Since I just added new public defines, this seems a good
> time to ask.

Sounds like a good thing to do.

There is no need to go over all of Guile and change to the 'new
style', tho.  I expect that a lot of #ifs will not be replaceable
since the code that they comment out will not be legal in all cases.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: #if vs #ifdef

[tomas]

On Thu, Mar 27, 2003 at 07:48:05AM -0500, Dale P. Smith wrote:
> On Thu, 27 Mar 2003 00:18:08 -0600
> Rob Browning <rlb@defaultvalue.org> wrote:
> 
> >                                              Their argument is that all
> > reasonable compilers will generate the same code either way, and using
> > C code rather than the preprocessor can substantially improve the
> > readability of the code and allow the C compiler to do more thorough
> > analysis of all code paths.
> 
> I agree that nested #if's are a horrible thing to wade through, and it
> makes sense to do this.  On the other hand, aren't there modes in emacs
> that allow you to hide the #if'ed out code?  That would improve
> readability far more than if (..).
> 
> I don't understand how it better for the compiler though.  I would think
> using #if's effectively edits the code out of the way before the
> compiler has a chance to look at it.  Using if (..) gives the compiler
> useless work to do.  How is theis better?

This disadvantage is at the same time the advantage (how zen-ish ;-)

The `iffed-out' code gets shaken by the compiler on a regular basis
and some silly bugs get spotted earlier...

(ISTR a funny example for this. Hmmm... Ah, yes, it was in the PostgreSQL
mailing list: the code contained an #elsif instead of an #elif. As long
as the corresponding #if was false, no one noticed, since the preprocessor
dutifully jumped to the matching #endif).

Of course sometimes you can't avoid #if -- when you are sorting out things
which have to be done at compile or link time (e.g. differences in headers,
libraries and such).

Regards
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: #if vs #ifdef

[Rob Browning]

"Dale P. Smith" <dsmith@altustech.com> writes:

> I don't understand how it better for the compiler though.  I would think
> using #if's effectively edits the code out of the way before the
> compiler has a chance to look at it.  Using if (..) gives the compiler
> useless work to do.  How is theis better?

I think the main argument is that it allows the compiler to check all
the code paths on every compile.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: #if vs #ifdef

[Rob Browning]

Marius Vollmer <mvo@zagadka.de> writes:

> Sounds like a good thing to do.

OK, I changed all of our new (or renamed) public defines to use this
convention, and added some corresponding verbage to the guidelines in
gen-scmconfig.c.  In existing code I did not change from #ifdef to if,
just from #ifdef to #if.  Also I left GUILE_DEBUG,
GUILE_DEBUG_FREELIST and the deprecated defines alone for backward
compatibility.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel