texmacs-dev
[Top][All Lists]
Advanced

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

[Texmacs-dev] C++'s frustrations


From: Henri Lesourd
Subject: [Texmacs-dev] C++'s frustrations
Date: Mon, 23 Jun 2008 13:56:56 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

Abdelrazak Younes wrote:

Henri Lesourd wrote:

Read carefully: "on some platforms" means "there is no standard
solution". Thus perhaps you can do it, but it will remain a
hack depending on the particular compiler, kind of. Thus, it
is not very okay to use it.

Right, it depends on the target platform. But the reality is that, if he wants to touch a lot of users, a binary plugin developer will target wide spread platforms, Win, Linux or Mac. If the plugin developer target a more obscure platform then, most likely, he will take care of the plugin upgrade for his low number of users when the ABI is broken (if that ever happen).

Hem, I have to admit you are right, here. That's a
useful thing to know :-).


Alleluia :-)

Ahem, after 10 mns of initial enthusiasm, I went back
to my usual C++ experience: frustration.

The problem is: I don't want a solution which works
only *most of the time*, what I need is a correct,
complete solution.


In this respect, the solution you described, although
it *should* work, is in fact unreliable, because
if TeXmacs is compiled with the compiler A, and
the plugin is compiled with the compiler B, then
chances are high that things break.

This is because, as far as my knowledge of C++
compiler technology is concerned, there is no
standard in how to compile method dispatch across
different compilers.


Thus if I do like you do, i.e., I fetch a pointer
to a class instance created by the DLL (compiled
with the compiler A), and then from inside the
code (compiled with the compiler B) which loaded
the DLL, I call a method of the object, what I
am in fact doing is calling the method using the
dispatch convention of the compiler B, while the
methods have been compiled expecting compiler A's
dispatch.

In such a context, a crash is highly likely.


This is why exporting a C function wrapper for
each method is the only reliable solution, otherwise
you are forced to tell the plugin implementor that
he should use only *this* particular compiler, and
then he can compile his plugin and load it without
the need of recompiling TeXmacs from source.


As you can imagine, such an approach is quite
unreliable, for we cannot even know for sure
which compiler the distro people are using to
compile TeXmacs.

Probably under Linux it works most of the time,
and under windows it's more often broken: in
any case it seems one cannot build serious work
by means of this technique.


Or perhaps do you have some other interesting
new information about C++ which could cure my
doubts ?


Thus currently, I am lead to remain conservatively
on my previous position, namely: as an application
development system, C++ is exceedingly fragile,
and on important issues like this dynamic link
problem, it doesn't delivers reliable solutions,
at least not now (but people are waiting since
20 years already, which is IMHO not the lesser
problem of C++).




reply via email to

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