about "export" keyword

[DarkSpy]

many c++ compilers including "gcc" have not implemented the "export"
keyword, but the comeau compilers made it (just i knew).
i want to know about: is it too difficult to implement "export"
keyword? if it is, i know the history that is without "export" keyword
of C++ compilers with five years (sorry about my poor english ),
in five years still have no some idea to implement it ?
my project and many C++ programmers need this important keyword
but........

who can tell me why ?

thanks a lot and a lot !

 

[Peter van Merkerk]

many c++ compilers including "gcc" have not implemented the "export"
keyword, but the comeau compilers made it (just i knew).
i want to know about: is it too difficult to implement "export"
keyword? if it is, i know the history that is without "export" keyword
of C++ compilers with five years (sorry about my poor english ),
in five years still have no some idea to implement it ?
my project and many C++ programmers need this important keyword
but........

Many people seem to be able to do well without.

who can tell me why ?

Probably because it is difficult to implement and offers little
advantages. My guess is that many compilers have other issues w.r.t.
language compliance which are much more important to most people.

 

[Greg Comeau]

Many people seem to be able to do well without.


Probably because it is difficult to implement and offers little
advantages. My guess is that many compilers have other issues w.r.t.
language compliance which are much more important to most people.

Many compilers (still) don't implement many features.

Also, many controversial features were added to C++ over the
years, and during standardization. export was one of these.
export is difficult to implement and has a much larger than
normal cost to implement. It also forces implementations to
be correct in other areas that they might not be.

People were and are able to "do well" w/o templates at all,
or C++, etc etc. So that people seem to be able to do
well without it is not by itself a reason, just a
statement of itself.

For some technical discussion, see:

http://www.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1426.pdf

I disagree with some of the statements therein, so,
for one (partial) response to this see:

http://www.comeaucomputing.com/iso/promises.html

Note that at the April C++ committee meeting, there
was overwhelming support that export should continue
as a C++ feature.

 

[DarkSpy]

thanks above.
i need a compiler that was support "export" keyword, as i knew just
comeau made it, so i need it, because my project is: a template trace
tools.
but where can i got it ? can i buy it ? i was visit the website of
comeau that the compiler just compiling C++ code online...
thanks a lot to tell me where can i buy and how can i buy this
compiler ? and which platform support ? i am living in China.
thanks again.

 

[Dietmar Kuehl]

Note that at the April C++ committee meeting, there
was overwhelming support that export should continue
as a C++ feature.

Although it is correct, that there was overwhelming support for export,
essentially all compiler vendors who have not implemented this feature yet
were in favour of removing this feature or at least making it optional
(surprise, surprise...). That is, although there is strong support for
keeping export, those who still have to implement it are not in the camp
supporting the feature.

Actually, I'm still wondering whether export itself is indeed the hard
feature to implement: from what I see and hear, getting two phase name
lookup right seems equally hard. Although it was introduced as part of the
separation model, it changes the semantics even if the separation model is
not used. ... and there was no motion to remove this feature, too. I can
see that merging symbol table etc. makes implementation of export non-trivial
it seems to me that it is not really that hard by itself.

 

[tom_usenet]

Although it is correct, that there was overwhelming support for export,
essentially all compiler vendors who have not implemented this feature yet
were in favour of removing this feature or at least making it optional
(surprise, surprise...). That is, although there is strong support for
keeping export, those who still have to implement it are not in the camp
supporting the feature.

Actually, I'm still wondering whether export itself is indeed the hard
feature to implement: from what I see and hear, getting two phase name
lookup right seems equally hard. Although it was introduced as part of the
separation model, it changes the semantics even if the separation model is
not used. ... and there was no motion to remove this feature, too. I can
see that merging symbol table etc. makes implementation of export non-trivial
it seems to me that it is not really that hard by itself.

Ahh, you're volunteering to implement it for GCC 3.6 then?

Tom

 

[Greg Comeau]

...
Actually, I'm still wondering whether export itself is indeed the hard
feature to implement: from what I see and hear, getting two phase name
lookup right seems equally hard. Although it was introduced as part of the
separation model, it changes the semantics even if the separation model is
not used. ... and there was no motion to remove this feature, too. I can
see that merging symbol table etc. makes implementation of export non-trivial
it seems to me that it is not really that hard by itself.

Some of this is part of what I address in my "promises" response
to n1462: that many features are interconnected, that many features
are hard (to implement and to use), etc. I find export being
used as a scapegoat, straw man, and mnay other things all wrapped
up into on. I'm not saying there are not problems, but there
should be a general assessement done of C++ en masse, not just
a quick and dirty effort to put out a local fire (which can often
be just as bad or worse, if the source of the fire is not located)
since it does not exist in isolation. But that said, export
does take the cake, whether direct requirements or not.

 

[DarkSpy]

i think the export keyword's difficult to implement point is:
1, if the .cpp code implement the specialization of the template
functions, where is the entry of the function ?
2, if the .cpp code implement the partial specialization of the
template functions, where is the entry of the function ?
if we can create some temporary objects file to save the
implementation .cpp code, and compiling other unit of the code which
using this "export" template file, we can searching the temporary
objects file to find the matching functions.
the problem is: if we are not specialization the template functions,
it just check the grammar not making the real code when the compiler
compiling the template code until we using this template code. so
where and what time is fit to create a temporary objects file ?
my idea is: can we find a way to remember the source code(include src
filename) where is implement the "export" template functions, and then
when we compiling other unit of the source file, we can pop_up the
remember source code and *just* re_compiling that code where point of
the template implement .cpp file, and linking to current source code.
it just an idea of kid.
hope we can implement the "export" early.

sorry again with my poor english..

 

[Dietmar Kuehl]

Ahh, you're volunteering to implement it for GCC 3.6 then?

I actually looked into it, yes. I'm not really volunteering to do it because
I'm not an expert on how gcc is implemented and the task is too big to do it
alone in my spare time, at least, this is what I suspect. As far as I can
tell, there are essentially two parts involved in implementing this feature:

- Dumping the information about the template definition including its context
at the point of template definition. There are two tricky issues to this
portion: omitting unnecessary stuff from the dump and sharing information
between different template definitions (I suspect the second part is
necessary for practical reasons). A major problem with this portion is the
lack of documentation. Of course, rather than complaining about this lack
I should remove it
- Loading the dump for a template definition and merging the context
information of involved types when instantiating a template. Once this is
done the stuff can be handed off to the existing instantiation mechanism
as far as I can tell.

Neither of these sounds too complex and I think it should be doable... Of
course, the right forum to discuss this issue and to volunteer is the
corresponding gcc mailing list.

 

[Greg Comeau]

I actually looked into it, yes. I'm not really volunteering to do it because
I'm not an expert on how gcc is implemented and the task is too big to do it
alone in my spare time, at least, this is what I suspect. As far as I can
tell, there are essentially two parts involved in implementing this feature:

- Dumping the information about the template definition including its context
at the point of template definition. There are two tricky issues to this
portion: omitting unnecessary stuff from the dump and sharing information
between different template definitions (I suspect the second part is
necessary for practical reasons). A major problem with this portion is the
lack of documentation. Of course, rather than complaining about this lack
I should remove it
- Loading the dump for a template definition and merging the context
information of involved types when instantiating a template. Once this is
done the stuff can be handed off to the existing instantiation mechanism
as far as I can tell.

Neither of these sounds too complex and I think it should be doable... Of
course, the right forum to discuss this issue and to volunteer is the
corresponding gcc mailing list.

I would really like to see another export implementation,
for a number of reasons, so get a team going!

 

[Greg Comeau]

i think the export keyword's difficult to implement point is:

[argument removed]

Getting at something representing the source is part of the problem but I
doubt that this is the hard part: when the compiler processes a C++ file it
can dump the source or some preprocessed form thereof into an appropriate
location be it a database, some directory structure or involved object
files. From what I have heard EDG's compiler does something like this and
it is even in a form which makes backward engineering not that trivial (one
argument in favour of the separation model was protection of intellectual
properties in template libraries).

As with many things in C and C++, said is allowed, but not
required.

Well, actually Greg actually confirmed my suspicion and he was one of the
first to ship a compiler supporting export (although he didn't implement
all of it: his compiler is based on EDG's front end): export per se is not
the hard part. It ain't trivial, for sure, but the actual complexity lies
in the interaction of various features with export being just one of them.

To the best of my understanding of what EDG, it was hard in its
own righ too.

Surely, to get export right it is necessary to get an aweful lot of other
stuff right, too.

Yup. And it's mutual. For instance, your can't implement
argument dependent lookup w/o also having implemented export.

In the perspective of removal of export from the standard
(a corresponding motion was discussed at the last standardization meeting
in Oxford) the point is basically that it is plain nonsense to remove an
individual feature: although it would make implementation of a C++ compiler
easier, it wouldn't be the big win.

Something like that.

Greg didn't address the complexity of export in detail. From what I hear
about the front end issues (I have no idea what lies behind this), the big
problem lies in getting the instantiation contexts right: names within a
template are looked up by looking at the namespaces where the types involved
in expressions are defined (ie. argument dependent lookup). Without export,
there is just one such context during instantiation of a template. With
export, it is necessary to merge the contexts from different translation
units. Even worse, the lookup contexts don't stay the same but become
extended depending on the location of a type definition within a file.

My hope was that Greg had additional details on managing the template sources
because I suspect that this is done in the back end part of the compiler. On
the other hand, most of the infrastructure is probably already available in
the front end...

Yes, and the problem is that the context needs to consider
the needs of the instantiations, perhaps making the context
even more complicated. Obviously managing all that while also
trying to keep it efficient is a task.

 

[Howard Hinnant]

| Actually, I'm still wondering whether export itself is indeed the hard
| feature to implement: from what I see and hear, getting two phase name
| lookup right seems equally hard. Although it was introduced as part of the
| separation model, it changes the semantics even if the separation model is
| not used. ... and there was no motion to remove this feature, too. I can
| see that merging symbol table etc. makes implementation of export non-trivial
| it seems to me that it is not really that hard by itself.

Data point: Metrowerks has a full and correct implementation of two
phase name lookup. Metrowerks does not have export.

 

[tom_usenet]

| Actually, I'm still wondering whether export itself is indeed the hard
| feature to implement: from what I see and hear, getting two phase name
| lookup right seems equally hard. Although it was introduced as part of the
| separation model, it changes the semantics even if the separation model is
| not used. ... and there was no motion to remove this feature, too. I can
| see that merging symbol table etc. makes implementation of export non-trivial
| it seems to me that it is not really that hard by itself.

Data point: Metrowerks has a full and correct implementation of two
phase name lookup. Metrowerks does not have export.

Have you looked into implementing export? How hard would it be given
your codebase? Have you now implemented every other standard feature?

Tom

 

[Howard Hinnant]

| >Data point: Metrowerks has a full and correct implementation of two
| >phase name lookup. Metrowerks does not have export.
|
| Have you looked into implementing export?

Yes.

| How hard would it be given your codebase?

Hard.

| Have you now implemented every other standard feature?

To the best of my knowledge, yes.