Re: memory.text

[Rob Browning]

Dirk Herrmann <address@hidden> writes:

> Why so?  Would you prefer macros being put in a place of their own
> as well?  Essentially, you have implemented SCM_NEWCELL as an inline
> function, which has been a macro before.  IMO, it fitted quite
> nicely in gc.h.  With the new HAVE_INLINE macro, combining inlined
> with non-inlined code should be easy.

If it's not too hard to manage, I tend to agree with Dirk here.  Right
now, it's pretty easy to figure out where to go look for something.
Moving all the inlines to a single file makes it harder to predict
where something might be.

However, if we need inline.h to deal with platform issues, then fine.
I'd always thought about having some kind of macro magic that would
allow you to do something like this in an arbitrary .h header:

  SCM_BEGIN_INLINE
  int foo(int bar)
  SCM_MARK_BODY
  {
    do_something();
  }
  SCM_END_INLINE

For systems with real inlining, the markers would almost be no-ops,
but on systems without real inlining, the body would be shuttled off
to a separate .c file that would be included by the main .c file for
this header.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD