This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: struct interface
- To: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>
- Subject: Re: struct interface
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 06 Apr 2000 18:13:50 +0200
- Cc: Michael Livshin <cmm at verisity dot com>, clark dot mcgrew at sunysb dot edu, Guile Mailing List <guile at sourceware dot cygnus dot com>
- Cc: djurfeldt at nada dot kth dot se
- References: <Pine.LNX.4.21.0004061804490.7086-100000@marvin.ida.ing.tu-bs.de>
Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:
> On 6 Apr 2000, Mikael Djurfeldt wrote:
>
> > I don't want to introduce complexity in the user interface. One
> > should be able to write things like:
> >
> > struct foo {
> > char c;
> > SCM s;
> > }
> >
> > and rely on that this will work whatever architecture you're running
> > on.
> >
> > If we require users to do explicit padding, I think this will become a
> > common source of bugs.
>
> Except if we add a debug mode in which at runtime the alignments are
> checked with every call to the SCM_MEMORY_WORD macro.
Still, why should the user have to care about the type of alignment
used on his architecture? Why should he have to care about what size
the SCM type currently has compared to other types on his
architecture?
> However, my temporary concern is not how to care for extensions to guile
> which are in a maybe-not-too-near future. The question is, whether the
> suggested macros make sense and whether we should try to direct the
> majority of guile's current memory accesses through such a set of
> macros. Is this, for example, something helpful for the introduction of
> the new garbage collection mechanisms?
Sorry if I'm not providing helpful input. I felt that it was good to
bring up related issues on the table in case they influence design
decisions. I typically don't see whether they will or not until after
a while.
To me the SCM_MEMORY_WORD idea seems good.