Re: C or C++?
On May 21, 1:11 am, Gianni Mariani <gi3nos...@mariani.ws> wrote:
On May 21, 6:53 am, James Kanze <james.ka...@gmail.com> wrote:
On May 20, 12:21 pm, Gianni Mariani <gi3nos...@mariani.ws> wrote:
...
You're not implying being able to export templates are you ?
I'm not implying anything. I'm saying very bluntly and directly
that today (2007), there is no real technical reason not to
implement export.
You seem to be sitting on the fence on this one, can you tell us what
you really think ?
What I just said: there is no real technical reason for not
implementing export today. It does require a certain amount of
effort (i.e. cost), but nothing a company like Microsoft
couldn't easily afford.
... It means a bit of programming work, but the
techniques and the problems are known (thanks to the people at
EDG). ...
A simple matter of programming ?
Maybe you missed the implied smiley on my previous post however, I
think there is a little more to it to do it right.
That's true of just about anything:-). It obviously does
require preliminary design, development of tests, etc., as well
as pure programming. And like most non-trivial things, it's
easy to get wrong if you aren't careful. But that's true of a
lot of other things as well---correct implementation of two
phase lookup isn't trivial either, nor is template type
deduction.
I would not hold
doing it now on my account.
I rather suspect that it is more than a one man project. (From
what I understand, it was implemented by a single person at EDG.
But not every company has the chance to have someone that gifted
on their staff.)
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'm
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.
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. 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
projects.
--
James Kanze (GABI Software) email:james.kanze@gmail.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