JV> Martin Buchholz <martin(a)xemacs.org&gt; writes: JV> I am still thing it might be a big win to use a C++ compiler to catch JV> GCPRO mistakes (if we really switched to C++ we could even have objects JV> GCPRO themselves). In fact I think a C++ compiler could catch mistakes JV> like the above at compile time. The idea is to make function arguments JV> and return values to have different classes with no implicit JV> conversion between them. In the same way you could catch most if not all JV> calls to functions that can GC from functions that cannot. [I still JV> haven't tried this so there may be some snag somewhere.] It is possible to have an object type (in the C++ sense) that would be an automatically GCPRO'ed Lisp_Object pointer, which would UNGCPRO on passing out of scope, but ... I don't think you can do anything do prove GCPROing at compile time, and I think in general the semantics of GC protection cannot be captured by a C++ object. Consider: Lisp_Object bar (Lisp_Object); ... bar (Fcons (Qnil, Qnil)); Temporary variables can't be handled. On the other hand, if we could switch to C++ permanently, at least GCPROing would be less painful. BEFORE: { Lisp_Object foo, ret; struct gcpro gcpro1; foo = Fcons (Qnil, Qnil); GCPRO1 (foo); ret = bar (foo); UNGCPRO; return ret; } AFTER: { Protected_Lisp_Object foo = Fcons (Qnil, Qnil); return bar (foo); } What's going on is just as tricky - merely less annoying to code. You still must resist the urge to write { return bar (Fcons (Qnil, Qnil)); } A function can't return a Protected_Lisp_Object, only a Lisp_Object. I'd like you to prove me wrong - in this case I would support the permanent switch to C++.

MA> In the XEmacs case the data being encapsulated would be a lisp object MA> so that Protected_Lisp_Object could be used interchangeably with MA> Lisp_Object (more precisely there would be trivial conversion methods MA> that would allow this). If Fcons returns a Protected_Lisp_Object and MA> bar takes a Lisp_Object (or a Protected_Lisp_Object) as a parameter, MA> your example above should work ok. When the temporary that holds the MA> return value of Fcons goes out of scope the destructor for the MA> Protected_Lisp_Object would unprotect the object. If bar made a copy MA> of its parameter in a Protected_Lisp_Object that outlives the call to MA> bar, then the object would still be GC protected, otherwise it MA> wouldn't be (which is what you want). MA> This is an example of using "smart pointers" in C++ (although what is MA> being encapsulated isn't really a pointer so the name is a bit MA> misleading). There is a brief discussion of this in section 11.10 MA> and 11.11 of the third edition of Stroustrup's "The C++ Programming MA> Language". Implementing protected lisp objects this way wouldn't be MA> exactly trivial, but it wouldn't be really hard either. If all lisp MA> objects in C (really C++) code were changed to Protected_Lisp_Object, MA> GC protection would probably be essentially automatic. In fact the MA> best way would probably to just make Lisp_Object the class name so it MA> would mostly require no source code changes. MA> I'm designing this off the top of my head here, so I'm probably MA> missing something obvious, but it seems like this could be made to MA> work. 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.

MA> At 1:48 AM -0800 3/5/2000, Martin Buchholz wrote: MA> Unfortunately I have a real job that keeps me coding 50 to 60 hours a MA> week so I don't have the time to tackle this right now, although it MA> sounds like it might be worthwhile and fun. MA> I took a quick look at it this afternoon and discovered that XEmacs MA> won't build in C++. It may have worked at one time, but it certainly MA> doesn't work now, at least not in the MSVC compiler. The source MA> mixes char * and unsigned char * with gay abandon and it uses C++ MA> reserved words like "class" and "new" as variable and parameter names MA> in several places. I fixed these problems in about 4 out of the MA> first 6 files that it tried to compile when it became clear that this MA> was a bigger job than I have time for now. The XEmacs I use for everyday work is always built with a C++ compiler. For Unix, of course. Kirill has compiled XEmacs for C++ for Windows. Perhaps Kirill should submit some compilation patches. Here's a code fragment from config.h.in that should help: #if defined (__cplusplus) && !defined (NOT_C_CODE) /* Avoid C++ keywords used as ordinary C identifiers */ #define class c_class #define new c_new #define this c_this #define catch c_catch #endif /* C++ */ The above likely belongs in nt/config.h. You can take it from there. If we're going to be serious about C++, we should rewrite those C++ keywords. With the one exception that `class' is used in X11. Xlib.h: typedef struct { XExtData *ext_data; /* hook for extension to hang data */ VisualID visualid; /* visual id of this visual */ #if defined(__cplusplus) || defined(c_plusplus) int c_class; /* C++ class of screen (monochrome, etc.) */ #else int class; /* class of screen (monochrome, etc.) */ #endif unsigned long red_mask, green_mask, blue_mask; /* mask values */ int bits_per_rgb; /* log base 2 of distinct color values */ int map_entries; /* color map entries */ } Visual; MA> I still think it would be possible to use a smart pointer style class MA> for Lisp_Object and make this work if we could build in C++. The MA> existing GCPRO stuff would disappear completely so it doesn't really MA> matter that it uses a stack. Instead you could (and probably should) MA> use a std::map<> to record the objects that are currently GC MA> protected. I took a look at how gcprolist is currently used and it MA> would be extremely easy to replace it with a map<>. The only thing MA> that is even slightly tricky is the implementation of catch and there MA> are several ways to handle this. The simplest, although not most MA> space efficient, is to make a copy of the map in internal_catch and MA> condition_case_1 and restore it in unwind_to_catch. You could also MA> record the catch level in the map entries and use that to delete the MA> irrelevant ones in unwind_to_catch. This would take some more time MA> and space than the current calls to GCPROn and its friends, but maps MA> are pretty efficient and meant to be used for things like this. MA> You imply that this has been tried before and given up. What MA> problems were discovered? It looks like it must not have been MA> recently since it looks like the code hasn't compiled in C++ for a MA> while. Perhaps the improvements in C++ and the standard library MA> might make things easier than they were when it was last tried. Not for XEmacs. I've seen other people using C++ on other projects give up on precise GCPROing for the stack using the Protected_Lisp_Object foo; foo = Fcons (Qnil,Qnil); bar (foo); /* _not_ bar (Fcons (Qnil, Qnil)) */ technique and switch to conservative GC, because of the failures when having temporary Lisp_Objects generated by nested function calls. If they had automatic, precise, safe, efficient GC protection for the stack, they would have eagerly adopted that route. There are always concerns that conservative GC can be defeated by increasingly clever compiler optimizations.