Re: Emacs and Gnome Canvas

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> writes:

>> > I meant link-time and run-time compatibility, not syntactic
>> > compatibility.
>> 
>> I use C code on my C++ projects all the time, without those issues. Why
>> Emacs should be different?
>
> Because Emacs uses some techniques that a rare C program does.  I
> mentioned some of them in another thread.  Here's a recap:
>
>   . The "relocatable allocator" which moves memory of allocated
>     objects (such as the buffer text) when large chunks of memory are
>     allocated or freed.  Also, allocation of memory off the pure
>     space, during the build process.  These will probably need a
>     custom new/delete implementations, and various C++ techniques such
>     as smart pointers may need to be adjusted, or not used.

For this I would try to isolate the display manager's memory management
from the rest of Emacs. As far as the display manager doesn't need to
allocate or free objects created by Emacs, and vice-versa, it should
work. Right?

>   . The dump and restart process: it's possible that various C++
>     features such as static constructors will ``need some work'' to
>     survive these atrocities.  That might need hacking the libraries
>     you use, if you have the sources.

Good one. I can go without using static/global constructors, but dunno
about Qt. There are other potential issues with that: vtables, RTTI...

Thanks for the remarks.

A random thought now about something that intrigues me: AFAIK the only
purpose of dumping is to include into Emacs' executable the set of
compiled Elisp code that is required to be usable. I guess that the
approach made sense when distributing Emacs as a single executable could
be useful. But now hardly anyone installs Emacs without the extensive
Elisp library and other auxiliary files, so the "self-contained
functional Emacs executable" has little value. Of course I may be wrong
when guessing this, but if it is right, wouldn't make more sense to dump
all that Elisp bytecode to a single file that is loaded on startup? On
exchange of a startup time just a bit larger, the simplification on
other areas would be considerable.

[snip]