[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The relationship between SCM and scm_t_bits.
From: |
Marius Vollmer |
Subject: |
Re: The relationship between SCM and scm_t_bits. |
Date: |
Mon, 09 Aug 2004 23:09:01 +0200 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
Dirk Herrmann <address@hidden> writes:
> Certainly, the way we convert between scm_t_bits and SCM is
> implementation dependent. However, the definitions for scm_t_bits
> and SCM are IMO a very good way to provide an abstraction of some of
> this uncleanlyness. And, with today's definitions of scm_t_bits and
> SCM, the heap _must_ hold scm_t_bits variables. Please explain, why
> you think that it is cleaner to say it only holds scheme objects if
> in fact it does not.
The reason is that there exits code that does essentially this:
scm_t_bits heap_field;
SCM value = whatever ();
SCM *ptr = (SCM *)&heap_field;
*ptr = value;
This is quite unclean. This variant is cleaner and standards
conformant:
SCM heap_field;
SCM value = whatever ();
SCM *ptr = &heap_field;
*ptr = value;
> What is the reason to change a paradigm, which has for several years
> worked quite nicely, is easily understood, and has helped to find
> and probably also to avoid a bunch of errors?
I don't think that the paradigm has changed fundamentally. It has
been strengthened, if you will. The distinction between scm_t_bits
and SCM is still there.
We don't just cast between SCM and scm_t_bits, we use SCM_PACK and
SCM_UNPACK. Except sometimes a scm_t_bits variable is stored into via
a SCM* pointer, totally ruining the care PACk/UNPACK abstraction.
That exception has now been removed. I see that as an unconditional
improvement, don't you?
--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405
- Re: The relationship between SCM and scm_t_bits.,
Marius Vollmer <=