guile-devel
[Top][All Lists]
Advanced

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

Re: C level variants of make-vector / make-string


From: Dirk Herrmann
Subject: Re: C level variants of make-vector / make-string
Date: Fri, 9 Feb 2001 11:31:48 +0100 (MET)

On 9 Feb 2001, Marius Vollmer wrote:

> > After all, the corresponding functions could as well be made into
> > inline functions (as soon as the new C standard is out), [...]
> 
> You mean, as soon as all important compilers support this construct,
> which is already now, because GCC, well... :-)

Hmmm?  Does GCC already support inline functions as defined by the
proposed standard?  I know that they supported some sort of inline
functions for a long time, but the semantics were quite different from the
way they are defined for the new C standard.  Thus, the GCC folks would
have to change the way inline functions work.  Has that already happened?

> Based on this argument, almost all functions should be made inline.  I
> don't think we want that.

Not really :-)  But, for many functions it is an option we could then
think about.  Whether the _c_ variants of make-vector/make-string are
sufficiently important / small is questionable, I admit.

> > > First, I suggest to introduce scm_c_make_string to replace scm_makstr
> > > (which would be deprecated).  The function scm_c_make_string would take
> > > the size argument as an unsigned long int or scm_sizet.
> > 
> > This makes sense.  If nobody objects, I will do it.

Well, for scm_makstr I have already done it locally.  However, I would
like to be sure about the right naming.  scm_makstr did _not_ initialize
the string, thus scm_makstr does not have a char parameter for
initialization.  (scm_makstr does have a second argument, but that is not 
a char and is not used any more since some cleanups in symbols.c.)  The
replacement function for scm_makstr should IMO also do no initialization.

The question is, is it a good idea to name this function scm_c_make_string
if it does not do any initialization, while scm_make_string potentially
does?  Or should it rather be named like 
  scm_make_uninitialized_string,
  scm_make_string_noinit,
  scm_make_string_nofill
or something else?  I'd like to be sure about the name before committing.
(I also like long names :-)

> Yep, you should probably also consider scm_makfrom* and scm_take0str
> when you are at it.

What should be done with them?

Best regards,
Dirk Herrmann




reply via email to

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