Re: C++ vs. GCPRO

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.