Branko Čibej <brane@xbc.nu> writes:
> >+#define SVN_VER_GEN_PROTO(name) \
> >+#define SVN_VER_GEN_IMPL(name) \
> >+#define SVN_VER_COMPATIBLE(name) \
> >+#define SVN_VER_CALLBACK_COMPATIBLE(name) \
> >
> > I do not believe we should be using the preprocessor to this
> > extent. The preprocessor is not our friend. Suppose I run into a
> > problem
> >involving svn_subr_version and I want to find out where it's defined? I
> >can't grep for it, because it was defined with SVN_VER_GEN_IMPL(subr).
> >
> I agree this could be a problem, even though GCC at least will point
> to the macro definition, and GDB will single-step through it. On the
> other hand, the svn_*_version functions are so simple that I'm
> prepared to formally prove their correctness, and I decided on the
> macro approach because we're going to have many of them, and
> definitely want them all to be the same.
These sorts of preprocessor splices really mess up tags tables, too
(this has burned me more than once in APR). I'd also prefer just to
list the functions by name.
> >The asymmetry between the two version arguments (one specified as a
> >structure pointer, the other split out into four parameters) seems
> >weird.
>
> Yes, it does. It's there because I didn't see any other way to
> generate the shorthand macros. I do see a better way now, and will
> change those prototypes.
Now, when the macro declarations are actually affecting the
prototypes, that's a sign... :-)
I had exactly the same thought about the single param vs four separate
params.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 10 22:27:10 2004