Received: (from majordom@localhost) by hyperreal.org (8.8.5/8.8.5) id KAA29917; Thu, 21 Aug 1997 10:37:11 -0700 (PDT) Received: from twinlark.arctic.org (twinlark.arctic.org [204.62.130.91]) by hyperreal.org (8.8.5/8.8.5) with SMTP id KAA29898 for ; Thu, 21 Aug 1997 10:37:01 -0700 (PDT) Received: (qmail 22554 invoked by uid 500); 21 Aug 1997 17:00:55 -0000 Date: Thu, 21 Aug 1997 10:00:55 -0700 (PDT) From: Dean Gaudet To: new-httpd@apache.org Subject: Re: OS abstraction In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org On Wed, 13 Aug 1997, Paul Sutton wrote: > complex than this, and Dean has suggested we use inlineable functions > rather than complex and possibly side-effect causing macros. Where possible, inline would be great. The difficulty with inline is when you need to include the code in headers, and you need to also provide a version which is not inlined... and you want the two to be the same. How grossed out would people be if we had stuff like: foo.h: extern int inline wakka_wakka (request_req *r); #ifndef inline #include "foo_inline.c" #else foo_inline.c: int inline wakka_wakka (request_req *r) { woo! } foo.c: #include "foo.h" #ifdef inline #include "foo_inline.c" #endif ? (Recall that inline is defined to nothing if the compiler doesn't support inlining ... hence the #ifdefs up there.) Specifically I suspect foo is mostly going to be one of the os-dependant files. Dean