On Thu, Jul 13, 2006 at 11:01:13AM +0200, Viktor Griph wrote: > On Thu, 13 Jul 2006, Dominik Vogt wrote: > >>Is it really neccessary to defene everything with FVWM_ as a prefix? If > >>it's not already defined, why not define it using the expected name? > > > >I use the "fvwm" prefix to document that we modified its meaning. > >If we had just > > > > #define O_NOFOLLOW 0 > > > >someone might rely ona that flag although it's just a dummy to > >make the compiler happy. > > > > Well, you didn't define it FVWM_O_NOFOLLOW in configure.ac, so it's just > O_NOFOLLOW in there as well. It was all the stat-wrappers that I was > concerned about. The code use many of them unwrapped already, so if there > is a chance that some of them might not be defined it would be better to > provide them, with the assumed values you did, under the name expected by > the programmer.
There's really no final word on how to handle portability issues
yet. For maintenance reasons, we need to avoid ifdef'ed code as
much as possible. If we can't cope without ifdefs in some place,
they should be only in a single wrapper file (libs/FShape.h is an
example). Ifdefs in the code can easily be replaced with
constructs like this.
in .c file:
#ifdef FOOBAR
some(code);
#endif
becomes:
in some .h file:
#ifdef FOOBAR
# define USE_FOOBAR 1
#else
# define USE_FOOBAR 0
#endif
and in the .c file:
if (USE_FOOBAR)
{
some(code);
}
A big advantage is that *all* code is compiled, regardless of the
platform's features. The compiler should be smart enough to
optimise code like "if (0) some(code);".
The latest way to go is to provide dummy functionality that
satisfies the original interfaces and put it in "if (0)" when it's
not used.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
