Are there any compilers that support the 'export' keyword?

John Daniel


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Don't I have to include vector.cc somehow in my project (maybe via a
library)?

Andrei



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote in message ...
>Why did the standard committee deem the keyword [export] necessary?
I'm not on the committee, but  Dr. Stroustrup in section 15.10 of THE DESIGN
AND EVOLUTION OF C++ describes at length some of the difficulties involved
in having the template definition and the template declaration in different
files.

>[...]
>All I can think of is this.  At link time, the compiler will look
>for definitions of functions declared in the file
>   /usr/include/STL/vector
>in the corresponding cpp file
>   /usr/include/STL/vector.cc


Actually, there is no requirement that functions declared in x.h be defined
in a file named x.c.  They could be defined in any source file.
Therefore, the compiler/linker might have to scan every definition in every
file to find the match.

On 8 Dec 1998 18:20:34 GMT, Andrei Alexandrescu

>Don't I have to include vector.cc somehow in my project (maybe via a
>library)?

No.  See Stroustrup III, 13.7.  One strategy for dealing with template
functions defined in .c files is to include the .c file in each
translation unit.  This is how I'm doing things right now.  Another
strategy is to include the .h files only.  Stroustrup writes: "The
definition (in out.c) is compiled seperately, and it is up to the
implementation to find the definition of out() when needed".  So
it seems that we have the ideal compile method here: client code
never ever needs to mention the file out.c or vector.c.

We can think of the file out.c and vector.c as object files.  At
least they define the templates from which we can create real
object files out.o and vector.o.  So just as the MAKEFILE mentions
*.o files, it should mention *.c files.  Although, it seems to me,
if we follow the design rule that stuff declared in vector.h
should be defined in vector.c, we don't need to tell the MAKEFILE
anything new.  The linker knows exactly where to look for the
definitions.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrei Alexandrescu wrote:
>
> Hi,
>
> Could someone provide a concise explanation on the "export" keyword? It's so
> new, I haven't seen any paper on it yet. Thanks.
>
> Andrei

I don't know if this counts as concise; it's everything the standard has
to say on the subject:

Section 14:
"6 A namespace-scope declaration or definition of a non-inline function
template, a non-inline member function template, a nono-inline member
function of a class template, or a static data member of a class
template may be preceeded by the export keyword. If such a template is
defined in the same translation unit in which it is declared as
exported, the definition is considered to be exported. The first
declaration of the template containing the export keyword must not
follow the definition

7 Declaring a class template exported is equivalent to declaring all of
its non-inline function members, static data members, member classes,
member class templates and non-inline function member templates which
are defined in that translation unit exported.

8. Templates definined in an unnamed namespace shall not be exported. A
template shall be exported only once in a program. An implementation is
not required to diagnose a violation of this rule. A non-exported
template that is neither explicitly specialized nor explicitly
instantiated must be defined in every translation unit in which it is
implicitly instantiated (14.7.1) or explictly instantiated (14.7.2); no
diagnostic is required. An exported template need only be declared (and
no necessarily defined) in a translation unit in which it is
instantiated. A templated function declared both exported and inline is
just inline and not exported.

9 [Note: an implementation may require that a translation unit
containing the definition of an exported template be compiled before any
translation unit containing an instantiation of that template.] "


The third sentence of paragraph 8 shows the problem that 'export' is
intended to solve. Templates cannot be seperately compiled, at least not
in the conventional sense. Each template represents an infinite
collection of related classes or functions. Also, the meaning of the
template must be checked for validity each time it is instantiated,
because the validity depends upon which types (and non-type values) it
is instantiated with. A traditional linker could not deal with this.

One way around the problem is to put the entire implementation of a
template in the header file. The 'export' keyword will reduce the size
and complexity of header files, by allowing the more complex code to be
exported.

The export keyword allows the compiler to create a partially compiled
template definition for the one module in which the template is defined,
and to reference that definition in each module where that template is
used (hence paragraph 9). In principle, a C++ aware linker could do this
seperately from the compiler; however, that would mean that the linker
would have to return error messages related to template instantiation
errors.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrei Alexandrescu wrote in message <366867d1.0@10.1.1.65>...
>
>Hi,
>
>Could someone provide a concise explanation on the "export" keyword? It's
so
>new, I haven't seen any paper on it yet. Thanks.


Dr. Stroustup's explanation is "The keyword 'export' means 'accessible from
another translation unit'."  It allows you to declare and use a template in
one source file, but define the template in a different source file.  See
section 9.2.3 of THE C++ PROGRAMMING LANGUAGE Third Edition.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 8 Dec 1998 00:05:31 GMT, Matt Seitz <mseitz@meridian-data.com> wrote:
>Andrei Alexandrescu wrote in message <366867d1.0@10.1.1.65>...

>>Could someone provide a concise explanation on the "export" keyword? It's
>>so new, I haven't seen any paper on it yet. Thanks.

>Dr. Stroustup's explanation is "The keyword 'export' means 'accessible from
>another translation unit'."  It allows you to declare and use a template in
>one source file, but define the template in a different source file.  See
>section 9.2.3 of THE C++ PROGRAMMING LANGUAGE Third Edition.

This doesn't explain what the poster asked.  Why did the standard
committee deem the keyword necessary?  After all, the 'export'
keyword does not appear in any translation unit.  Here's a typical
example.  File /usr/include/STL/vector declares class std::vector
and defines a few inline functions.  File /usr/include/STL/vector.cc
defines the non-inline functions, each with the 'export' keyword.
Now clients will only include <vector>, <list>, and so on.  They
will never include vector.cc, list.cc, and so on.  And this means
that the 'export' keyword will never be seen.  So what good is the
keyword?

All I can think of is this.  At link time, the compiler will look
for definitions of functions declared in the file
   /usr/include/STL/vector
in the corresponding cpp file
   /usr/include/STL/vector.cc
Actually, the suffix can be any of a bunch of common extensions,
like '.cc' or '.C' or '.cpp'.  Note that this design principle
is written down in Lakos, section 3.2 .  It says that a function
declared in FILENAME.h should be defined in FILENAME.cc.

The 'export' keyword tells the linker-compiler which template
functions in the file 'vector.cc' should be considered as
definitions of functions in the file 'vector'.  After all, there
may be helper functions and helper classes in 'vector.cc'.
These definitions are not exported.

So the to find the definitions of functions defined in 'vector',
the linker-compiler looks at the file 'vector.cc', at functions
defined with the 'export' keyword.  But the 'export' keyword is
still not necessary.  For example, if the linker-compiler is
looking for the definition of
   std::vector<T>::operator=(const std::vector<T>&);
then it can scan every function in vector.cc -- not just
functions prefixed with the 'export' keyword -- and it must
eventually find the one and only definition.  So the
question remains: why is the 'export' keyword even in the
language?

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,

Could someone provide a concise explanation on the "export" keyword? It's so
new, I haven't seen any paper on it yet. Thanks.

Andrei




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]