Re: C++ vs. GCPRO
At 1:48 AM -0800 3/5/2000, Martin Buchholz wrote:
I encourage you to try and succeed where so many others have failed.
The code already compiles with a C++ compiler, so just add some new
constructors and destructors for Lisp_Object and see what happens.
Keep in mind that GCPROing uses a stack to keep protected pointers to
lisp objects. If Fcons returned a protected lisp object, then all
conses would have to be allocated and freed using a stack, but's
that's not how general memory allocation works.
Unfortunately I have a real job that keeps me coding 50 to 60 hours a
week so I don't have the time to tackle this right now, although it
sounds like it might be worthwhile and fun.
I took a quick look at it this afternoon and discovered that XEmacs
won't build in C++. It may have worked at one time, but it certainly
doesn't work now, at least not in the MSVC compiler. The source
mixes char * and unsigned char * with gay abandon and it uses C++
reserved words like "class" and "new" as variable and parameter names
in several places. I fixed these problems in about 4 out of the
first 6 files that it tried to compile when it became clear that this
was a bigger job than I have time for now.
I still think it would be possible to use a smart pointer style class
for Lisp_Object and make this work if we could build in C++. The
existing GCPRO stuff would disappear completely so it doesn't really
matter that it uses a stack. Instead you could (and probably should)
use a std::map<> to record the objects that are currently GC
protected. I took a look at how gcprolist is currently used and it
would be extremely easy to replace it with a map<>. The only thing
that is even slightly tricky is the implementation of catch and there
are several ways to handle this. The simplest, although not most
space efficient, is to make a copy of the map in internal_catch and
condition_case_1 and restore it in unwind_to_catch. You could also
record the catch level in the map entries and use that to delete the
irrelevant ones in unwind_to_catch. This would take some more time
and space than the current calls to GCPROn and its friends, but maps
are pretty efficient and meant to be used for things like this.
You imply that this has been tried before and given up. What
problems were discovered? It looks like it must not have been
recently since it looks like the code hasn't compiled in C++ for a
while. Perhaps the improvements in C++ and the standard library
might make things easier than they were when it was last tried.
Mike