🚀 go-pugleaf

Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
> shankar@mti.mti.sgi.com (Shankar Unni) writes:

> >Often, an #ifdef covers just a small part of an expression that may be
> >different between different environments, or some such small differences:
> >
> >   if (some condition) {
> >#ifdef SOMEIMPL
> >	if (some other condition) {
> >#endif /* SOMEIMPL */
> >	/* code */
> >	/* code */
> >	/* code */
> >#ifdef SOMEIMPL
> >	}
> >#endif /* SOMEIMPL */
> >   }

> But with `if const', your 11 lines of code could be rewritten as either

> 	if (some condition) {
> 		if (SOMEIMPL && some other condition) {
> 			/* code */
> 			/* code */
> 			/* code */
> 		}
> 	}

> 	(7 lines of code)

Of course it's a little unfair to pick on the specific features of the 
example, but I can no longer resist the temptation to point out that all 
of these are simply awful ways to deal with this sort of target 
dependency.  What you truly want in these cases is to replace the 
platform-dependent hackery with

  if (implementation_defined_test())
  {
      ...
  }

And let implementation_defined_test() be defined in whatever place you 
like to collect portability [sic] stuff.  In C one might have to choose 
between a function-like macro that could be unsafe and a function that 
might be too costly, but in C++ you can have hte best of both worlds if 
you make it an inline function.

Again: I realize there are other applications for the proposed idea; I 
encourage its supporters to present them and make a better case for this 
feature.  But this example strikes me as an argument _against_ the 
feature on the grounds that it encourages what I am happy to call a 
simply awful coding style.

> Both of these solutions have the advantage that the test for `SOMEIMPL'
> occurs only once, so things will be easier if you later have to change it to 
> `SOMEIMPL || SOMEOTHERIMPL'.

Ditto.  Plus the advantage that if this condition is tested for elsewhere 
- and if it isn't now, what are the odds it will be before the program is 
finally retired from service? - the inline function, like the ugly C 
macro, will at least have a chance of getting the change into every piece 
of code that uses it, if only the dependencies are setup correctly.  ;-)

> >Duplicating all the code so that each half is precisely correct in its {}
> >matching is both tedious and error-prone (trying to verify that both parts
> >of the expression are fixed).

> But fortunately as shown above it would not be required.

Ditto.

> >Also, the #ifdefs serve a purpose in pointing out the fact that this piece
> >of code is system-dependent.  The syntax you propose hides its warts rather
> >too well, and make it easy for a reader to miss the significant piece of
> >information that this area of code is system-dependent.

> True, but a convention of using upper-case for SOMEIMPL and similar constants
> would make such tests stand out.

I will concede that the inline function hides this as well as you want to
- I used a long, blatant name in my example for precisely this reason. 
But then again, if you don't have to worry about writing the details of
the target-dependent code all over the place, what difference does it make
how visible it is or isn't in use? 

[ To submit articles: Try just posting with your newsreader.
		      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]