On Mon, May 10, 2004 at 02:11:55PM -0500, kfogel@collab.net wrote:
> 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.
Agreed. For these "brain-dead" types of functions which are built
according to a very specific pattern, then I think auto-generation is just
fine. If people don't like preprocessor templates, then we can always have
gen-make spit out a .c file into each library...
<duck>
> 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.
There is one per library. That will get to be very painful, and will be
more prone to error. I certainly don't see the manual writing of these
things as outweighing the need for tag lookups. But that's just me :-)
Regarding runtime checks: as Branko pointed out, we do it already. Though
I would recommend a *query* function from a library, rather than a check.
That will let the calling application decide what it wants to do. For
example, the caller might dynamically look up symbols, and it wants the
library's version number to know what is available for lookup. If you only
have a "check", then the caller cannot properly alter its behavior. It
would have to do a bunch of probes to determine what it is talking to.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 10 23:10:31 2004