Re: memory.text

[Marius Vollmer]

Rob Browning <address@hidden> writes:

> 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.

Yes, but is it really hard to find definitions?  I don't think one
usually goes around guessing for something might be and opening file
after file.  I tend to use TAGS and grep.

This main motivation for putting it into one file is to concentrate on
the mechanism that makes these functions work for compilers that don't
know how to inline.

> 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.

Noble goal, but is it worth the complexity?  Hmm, maybe we can just
use the snarfer...