Support for export keyword ?

J

James Kanze

Because you can emulate export templates to a degree with
manual instantiation.

No you can't. Almost by definition. If you're doing it, it's
not the compiler which is doing it. And the whole point of C++
templates is that the compiler does it. I've played that game
of manual instantiation with <generic.h>, before we had
templates, and I can assure you that it isn't viable for
anything but the simplest uses of templates. And of course, the
semantics of an exported template are different than those of a
non-exported template.
In other words, in the header file you can simply have the
declaration of the template class or template function (ie.
not its definition), and then in a source file you can
implement the definition and then in that file instantiate it
manually for each type with which the template is being used
in the program.
I have done that in practice and it works.

In the very limited cases you've tried, perhaps. A compiler has
to work for every legal case.
It's quite simple to do, at least for simple template types.

For simple uses of simple types, yes. The standard requires
export to work for all legal uses. That's a big difference.
[...]
The above example compiles at least with gcc and Visual C++.

But it doesn't solve the problem. You've shown that in one
simple case it can be made to work. That's not what's required.
It has to work in all legal cases.
 
J

James Kanze

I don't think you understand how export templates work. Export
templates are no different from regular templates.

Yes they are. They eliminate a lot of undefined behavior, for
example.
They are not (and cannot be) compiled to object files prior to
their actual instantiation. They are compiled *after* they
have been instantiated, just like regular templates.

Not quite like regular templates. When a regular template is
instantiated, the instantiation occurs at a specific place in
the source code, with all of the preceding context present.
It's possible to implement export this way as well, but it sort
of defeats the purpose, and it still requires additional work,
because the instantiation must be compiled as if parts of the
preceding context are not present.
Yes, the linker stage has to call the C++ compiler in order to
instantiate export templates with the proper types, after
which they are compiled more or less like regular templates.

That's not necessarily true. First, if it calls the C++
compiler, it must be able to synthesize the correct context for
the instantiation (which is far from trivial). And better
compilers will still have the intermediate representation
present at link time (since it is necessary for advanced
optimization), and all the instantiation needs is some form of
the intermediate representation.
 
J

Juha Nieminen

James said:
But it doesn't solve the problem. You've shown that in one
simple case it can be made to work. That's not what's required.
It has to work in all legal cases.

That's why I asked for examples of export templates which are
difficult for compilers to implement. All you have said is that export
templates are difficult, without giving any actual examples.
 
V

Vladimir Jovic

Jerry said:
[ ... ]
Why do people bother to even mention/talk about such pathetic excuses
for a compiler ?

Producing C as its output doesn't make Comeau any less a compiler
than producing object code would. Your claim only shows that you
don't know what you're talking about.

From a practical viewpoint, its use of C as an intermediate language
isn't normally visible at all. You run the compiler, and you get an
executable file as output.

Sorry for my ignorance, but how do you debug with such compiler?
 
J

James Kanze

That's why I asked for examples of export templates which are
difficult for compilers to implement. All you have said is
that export templates are difficult, without giving any actual
examples.

I mentionned several cases in another posting. All it needs is
for some dependent symbol to be defined elsewhere in the
translation unit. A typical example (simplified to the minimum
necessary to show the problem) might be:

Type.hpp:
class Type {};

TypeIO.hpp:
std::eek:stream operator<<( std::eek:stream&, Type const& );

User.cpp:
#include "Type.hpp"
#include "TypeIO.hpp"

void f( std::eek:stream& dest, std::vector< Type > const& objs )
{
std::copy( objs.begin(), objs.end(),
std::eek:stream_iterator< Type >(dest) );
}

What does the compiler have to include to compile the
instantiation of std::eek:stream_iterator< Type > at a later point?
 
J

Jerry Coffin

Jerry said:
[ ... ]
Why do people bother to even mention/talk about such pathetic excuses
for a compiler ?

Producing C as its output doesn't make Comeau any less a compiler
than producing object code would. Your claim only shows that you
don't know what you're talking about.

From a practical viewpoint, its use of C as an intermediate language
isn't normally visible at all. You run the compiler, and you get an
executable file as output.

Sorry for my ignorance, but how do you debug with such compiler?

Just about like usual -- it inserts #file and #line directives into
the C file it produces, and the C compiler passes those through to
object files, so the debugger knows what parts of what source files
are associated with what object code, so it can display the
appropriate lines in the source file as it executes.
 
N

Nick Keighley

ie. they compile C++ to C

because its one way to implement a compiler?
Producing C as its output doesn't make Comeau any less a compiler
than producing object code would. Your claim only shows that you
don't know what you're talking about.
From a practical viewpoint, its use of C as an intermediate language
isn't normally visible at all. You run the compiler, and you get an
executable file as output.
Not likely -- especially since (as far as I can see) Sun specifically
says their most recent compiler does NOT implement export. See:
According to Sun: "This feature is not yet implemented, but the
export keyword is recognized."
So, people talk about Comeau and Intel as the only ones that
implement export, because nothing else implements export. They talk
about Comeau, because it's the ONLY one that really supports export.

don't quote .sigs
I well know C++ compilers are actually translators from C++ to
assembly language, but still there is a big difference between a cheap
C++ to C translator and a real C++ compiler. Big difference !

what is this argument by repetition? Are compilers that compile C
significantly cheaper than native code compilers. It wouldn't surprise
me if native code C++ compilers often share a back-end with the
implementor's C compiler. Do gcc write a fresh back end for both C and
C++ every time they port?
This is exactly why such a good-looking, standards-conforming pseudo
"compiler" is not really wide-spread as others, real ones, are,
despite being less conforming and more expensive :).

I would like to try Comeau but they have no free version for their
cheap translator, they actually charge money for it !

maybe this "cheap" thing is in your head?

So if I just want to see the export keyword live in action I can only
try the free Linux version of Intel C++ compiler.

er, comeau?
The Intel compiler is also awkward in that it requires Microsoft
Visual C++ or at last some SDK in order to run !
why?


The Linux version is
somewhat better: it requires gcc ...

what? Intel's compiler requires gcc?
 
N

Nick Keighley

Same for a search engine and yet they don't cost money to use.

there are historical reasons for that. possibly to do with trying to
establish a monopoly
 
A

Anand Hariharan

Also, of course, the semantics of an exported template aren't
the same as those of a template which isn't exported.  Many
cases of undefined behavior with todays templates are well
defined if the template is exported.

Could you give an example, please?

thank you,
- Anand Hariharan
 
J

James Kanze

Could you give an example, please?

Just the difference between separate compilation and not
separate compilation. The exported template is defined and
instantiated in a controled environ, and so is not affected by
the source code in which it is used, except for dependent names.

For one obvious example: an exported template can use helper
functions in an unnamed namespace. And will not be affected by
unnamed namespaces which precede the template in the file which
uses it.
 
B

Brian

It's partly to do with the fact that search engines can make far more
money by selling to advertisers than selling to us - they do get paid
for their work, just (helpfully) not by us.

http://anthonywang.com/2009/07/16/y...7/17/where-does-google-get-97-of-its-revenue/

I guess compiler writers have far less to offer potential advertisers
than search engine companies - the number of people who want to compile
free code on the web is substantially smaller than the number who want
to e.g. find their nearest pizza outlet. Since somebody has to keep the
compiler writers off the street, that therefore ends up being us (for
want of a better alternative).

I think it boils down to who you can trust that is in power.
In saner times, 20+ years ago, there was some measure of
equity around the world. Today whether it is Red China or
Red USA though, it is increasingly difficult to have a
traditional free enterprise. There just isn't the integrity
of leadership needed to sustain that. Pols feel the heat
of past mistakes today and generally wind up making poor
decisions that don't really help matters. In my view,
the on line model is a good way to fight back against
the creeps in Washington and Beijing. It is true that
the number of programmers is small compared to the total
population. That's only part of the story though.
Advertisers love to reach niche markets with above average
incomes.


Brian Wood
http://webEbenezer.net
(651) 251-9384
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,150
Messages
2,570,853
Members
47,394
Latest member
Olekdev

Latest Threads

Top