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]

"DarkSpy" <co****@21cn.co m> wrote in message
news:aa******** *************** ***@posting.goo gle.com...

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.

--
Peter van Merkerk
peter.van.merke rk(at)dse.nl

[Greg Comeau]

In article <bg************ @ID-133164.news.uni-berlin.de>,
Peter van Merkerk <me*****@deadsp am.com> wrote:

"DarkSpy" <co****@21cn.co m> wrote in message
news:aa******* *************** ****@posting.go ogle.com...

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.

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/d...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.
--
Greg Comeau/ 4.3.0.1: FULL CORE LANGUAGE, INCLUDING TC1
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[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]

co****@panix.co m (Greg Comeau) wrote:

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.
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.co m/>

[tom_usenet]

On 30 Jul 2003 04:21:05 -0700, di***********@y ahoo.com (Dietmar Kuehl)
wrote:

co****@panix.c om (Greg Comeau) wrote:

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.

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

Tom

[Greg Comeau]

In article <5b************ **************@ posting.google. com>,
Dietmar Kuehl <di***********@ yahoo.com> wrote:

...
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.
--
Greg Comeau/ 4.3.0.1: FULL CORE LANGUAGE, INCLUDING TC1
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[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.. :-)

co****@panix.co m (Greg Comeau) wrote in message news:<bg******* ***@panix5.pani x.com>...

In article <5b************ **************@ posting.google. com>,
Dietmar Kuehl <di***********@ yahoo.com> wrote:

...
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.

[Dietmar Kuehl]

to********@hotm ail.com (tom_usenet) wrote:

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.
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.co m/>

[Greg Comeau]

In article <5b************ **************@ posting.google. com>,
Dietmar Kuehl <di***********@ yahoo.com> wrote:

to********@hot mail.com (tom_usenet) wrote:

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
correspondin g gcc mailing list.

I would really like to see another export implementation,
for a number of reasons, so get a team going! :)
--
Greg Comeau/ 4.3.0.1: FULL CORE LANGUAGE, INCLUDING TC1
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?