guile-devel
[Top][All Lists]
Advanced

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

Re: proposal: scm_string2str() and scm_symbol2str()


From: Dirk Herrmann
Subject: Re: proposal: scm_string2str() and scm_symbol2str()
Date: Wed, 21 Nov 2001 21:54:24 +0100 (MET)

On Mon, 19 Nov 2001, stefan wrote:

> > > > >  * To have sane memory allocation interface between C and libguile
> > > > >    put scm_c_free(), scm_c_malloc() and scm_c_realloc() into 
> > > > > `gc.[ch]'.
> > > > 
> > > > What would these functions do?
> > > 
> > > /* Memory allocation functions: Used within the `SCM -> C array type' 
> > >    conversion functions.  These should be used instead of the standard
> > >    malloc(), free() and realloc() functions provided by any underlying
> > >    libc implementation.  It avoids problems with applications using a
> > >    installed Guile library (libguile) and which use a different libc 
> > >    implementation.  */
> > > 
> > > Thus these functions are very simple wrappers for free(), malloc() and
> > > realloc().
> > 
> > Sorry, I don't get it.  If guile allocates the memory using malloc, then
> > it would use the libc implementation of malloc, wouldn't it?  How could
> > there be a conflict if the user used free on that memory?
> 
> I must admit that I've never seen this on a Unix platform.  But
> unfortunately it is common use on M$-Windows platforms to replace a
> written "free()" to different kinds of heap allocation free()'s depending
> on the "memory model".  Is this reason enough to have such functions?

I still don't get it.  How can those functions be named 'free' and these
people not getting conflicts with the standard library's free?  Don't they
use a different name for their 'personal free'?  I mean, if we allocate
our memory with 'malloc', then there has to be some appropriate 'free'
linked into the application, doesn't it?  Since we don't use a different
name than 'free' for the memory that guile frees, how can people get a
different one?

Sorry, but I feel more and more that this support for M$ platforms
influences our code base in a bad way.

> Yet another pointer might be c++.  If you use Guile inside c++ code you
> could define a class::free()...  This a reason?

Not really.  In C++ you may introduce new 'free' functions, but all of
those are distinguishable by using a class or namespace prefix.

Best regards
Dirk Herrmann




reply via email to

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