classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removing the TARGET_* layer or not ?


From: Mark Wielaard
Subject: Re: Removing the TARGET_* layer or not ?
Date: Sun, 08 Aug 2004 23:44:18 +0200

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

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]