This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: struct interface


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]