apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: build error on win32
Date Wed, 29 May 2002 20:39:09 GMT
At 03:14 PM 5/29/2002, Sander wrote:
> > While we're at it, apr_allocator_alloc and apr_allocator_free are also
> > defined inline. I don't think that makes much sense, given the size of
> > those functions.
>
>Hmm, so windows isn't smart enough to do both inlining and exporting?
>I'd like the stuff inlined in apr_pools.c (for performance), but need
>them exported for other callers than apr_pools.c.

Ummm... no.  Nor do I believe that the inline c language spec calls for it.


>Suggestions?

Yes.  First, drop the use of external inlines.

Second, map out a strategy that will work across inline and non-inlining
compilers.  Map out a strategy for building said fn's as exports as well
as inlines.

The typical win32 model on this stuff is;

foo.h

   #ifndef INLINE
   void EXPORT somefn(void);
   #else
   void INLINE somefn(void)
   {
     return;
   }

Now #define INLINE inline before including foo.h and you have the
inlined functions.

If you write a simple module that is linked in;

foo.c

   /* Toggle inline to include function bodies, but use
    * the EXPORT keywords instead to compile as fn's.
    */
   #define INLINE EXPORT
   #include "foo.h"

You now have both flavors.

Question of the hour is, WTF?  It's inline or it's not.  Why add the additional
complexity?  And remember that inlining will clobber us on binary compatibility
on otherwise perfectly safe changes to the internal guts of opaque structures.

Bill


Mime
View raw message