guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scm_num2float() ?


From: Dirk Herrmann
Subject: Re: scm_num2float() ?
Date: Mon, 3 Sep 2001 23:25:24 +0200 (MEST)

On 2 Sep 2001, Marius Vollmer wrote:

> Martin Baulig <address@hidden> writes:
> 
> > Can we add
> > 
> > ====
> > extern float scm_num2float (SCM a, unsigned long int pos,
> >                             const char *s_caller);
> > extern double scm_num2double (SCM a, unsigned long int pos,
> >                               const char *s_caller);
> > ====
> > 
> > and the corresponding VALIDATE and VALIDATE_COPY macros and then
> > deprecate scm_num2dbl() ?
> 
> Yes, good idea!  This can go into `stable' as well.

Since 1.6 is not officially out yet, deprecating something in 'stable'
allows to immediately remove it from 1.7 :-)

But, two other points with respect to numbers and conversions:

1) Type conversion for some C type T requires the conversions T->number
and number->T.  The number->T conversion should do some range checking to
see, whether the number fits into the desired range.  From a C programmers
view, however, it should be possible to check in advance whether a
conversion number->T would work, because otherwise it is necessary to set
up an error catcher or do the range check by hand, using some scm_less_p
checks.  Since this is inconvenient, IMO together with the conversions
T->number and number->T we should provide some number_fits_into_T_p
predicate.  (Then, again, one could argue that number->T wouldn't need to
do the range checks, because the user is responsible for doing them.  
Another alternative is to provide two variants of the number->T conversion
function:  A type and range checking one, and one that does no checks.)

2) Given that we agree on 1), we end up with three (or four) functions for
type conversions for each C type.  Assuming we want to consider the C
types char, uchar, short, ushort, int, uint, long, ulong, float, double,
ptrdiff_t, size_t, long long and ulong long, this gives 42 (or 56)
conversion functions.  This is just overkill, IMO.  I think we should
restrict ourselves to the types long, ulong, double, ptrdiff_t, size_t,
long long and ulong long and have the users check themselves whether for
example a ulong value received from scm_num2ulong fits into a character
which can easily be done using the UCHAR_MAX macro.

Best regards
Dirk Herrmann




reply via email to

[Prev in Thread] Current Thread [Next in Thread]