[Top][All Lists]
[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