Re: C or C++?
On May 21, 11:49 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
James Kanze wrote:
On May 21, 1:11 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
To do export "properly", there needs to be an kernel support if you
want to support dynamic linking/exporting.
If you want to resolve templates when dynamically linking, yes.
But that's independant of export, and as far as I know, no
implementation supports this for normal templates, either.
I think your reply indicates I didn't make my point.
most familiar with the Sun compiler, and their model of template
instantiation, and that would support export without much effort
at that level---the real work is in synthesizing the separate
context in which the template is instantiated---some of that
work is already implicit in two phase look-up, but not all.
The extra processing cost
on start-up of dynamically linked libs because of exports needs to be
worked so that it is not paid for every time a program starts up. I
have yet to see an export implementation
Why not? They're readily available. Because they're not the
"standard" compiler, or the "mainstream" compiler on any
particular plateform (or are they? SGI uses the EDG front-end,
I think), it's often very difficult, if not impossible, to
convince management to use them as a production compiler, but
they are certainly available to experiment with.
The coup de gr=E2ce for export is dynamic libs where the run time dynamic
linker does it's code generation business.
Except that the dynamic linkers on the systems I'm familiar with
don't do any code generation. (OK: it's a pretty limited
sampling today: Sun Sparc under Solaris, Intel 32 bit and AMD 64
bit under Linux and Intel 32 bit under Windows.) They just
patch up offsets.
I'm also still not too sure of the relationship with templates.
If we suppose that the .dll/.so/.whatever is some sort of byte
code, =E0 la Java, rather than a classical object file (with
machine instructions), then the templates have already been
instantiated and compiled to this byte code, so not much is
changed with regards to templates.
I'm not saying that there isn't any value in instantiating
templates at dynamic load time. But I fail to see where export
makes this harder; if anything, I'd say it makes it easier.
Entire programs could need
code generation, and it would be impractical to expect that the code is
generated upon every invocation. I take back my kernel support comment
but you will need some kind of "server" that resolves templates (i.e.
instantiates them) to share the instantiated application.
I'm not sure I see your point. How does "compiling" code
generated from instantiated templates differ from compiling code
generated from classical structures. And how does export change
The BIG plus in doing this of course is that you can have (in theory)
platform independant C++ binaries - if the entire application is an
Now you've really lost me.
but I suspect that debugging
will need to be worked out as well.
It also introduces a new failure
mode, static assert on dynamic link. I'd need to think through that
one a little.
Export does *not* mean instantiating templates on dynamic link.
That's an orthogonal issue. Export means, prinicipally,
compiling templates in a "clean" environment, unpoluted by any
headers I might have included previously.
Hmm. I don't see any relevance in that comment. I think it's pointless
having non-dynamic binaries given that almost everything is a dynamic
I disagree. (I'm not 100% sure what you mean by "dynamic
binary". Certainly applications worried about quality uses
dynamic linking only in a few, special cases, where the
advantages outweigh the risks and the cost in reliability.)
But what does the type of binary have to do with the source code
used to generate it?
... It means, too, not
triggering the recompilation of the entire project just because
a small, implementation detail changes in one
template---something which makes it almost a must for large
That small implementation detail may very well require recompilation of
the entire applications.
Unless the template in which it changed was exported. That's
exactly my point.
James Kanze (GABI Software) email:email@example.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34