Hi, On Wed, 2004-08-04 at 10:27, Andrew Haley wrote: > I guess as long as we're stuck with C90 we can't use inline. > Am I right in thinking that GNU Classpath targets C90?
Yes. More accurately would probably be that we try to support platforms that still depend on gcc-2.95. This is not that uncommon. And it is what the GNU Coding Standards recommend: http://www.gnu.org/prep/standards_10.html We are currently compiling our C code with: dnl We want ISO C90 pedantic ansi, but with longlong (jlong) support dnl and modern POSIX and BSD C library functions/prototypes. AM_CFLAGS='-ansi -pedantic -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wall -Wno-long-long -D_BSD_SOURCE ' I didn't know that would prevent inlining in general. But even if it does then we are probably better of with a little slower code that is easier to debug. GNU Classpath is still very much in rapid prototyping mode and we should be careful about premature optimization. > IMO, we shouldn't really be designing Classpath around the > infelicities of unfree compilers. > > > > Note, that with this system we would avoid the use of macros altogether > > > (You see, I don't like them ;) I better go with a well-thought-out > > > design). Sure, there is the 'overhead' of 1 additional function call. > > Macros are bad for a bunch of reasons, esp. debuggability and type > safety. I think this is the thing that most people found at this last year. That the use of C macros makes debugging very difficult. There are other inconveniences that come from the use the a extra layer of indirection, but I believe we can work around most of them as long as we get rid of C #defines in so many places or make it possible to more easily debug code that uses them. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
