On Thursday 20 November 2003 05:57 pm, Razmig K wrote:

> please name any recent C++ compiler that can handle 'export'ing
> templates for effective separate compilation.

In addition to the Comeau compiler mentioned by others, you can also
download Borland's "preview" compiler, which supports the export
keyword. You can download it from http://www.borland.com/cbuilderx/. As
a preview, it is a work-in-progress, not a supported product.
--
Ray Lischner, author of C++ in a Nutshell
http://www.tempest-sw.com/cpp

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <bpu4e8$clj$1@online.de>, Ekkehard Morgenstern
> <ekkehard.morgenstern@onlinehome.de> writes
>
>>
>> "Razmig K" <strontium90@postmaster.co.uk> schrieb im Newsbeitrag
>> news:3cad08b8.0311171811.2760c086@posting.google.com...
>>
>>> please name any recent C++ compiler that can handle 'export'ing
>>> templates for effective separate compilation.
>>> Thank you.
>>
>>
>> IBM Visual Age for C++ V3.5 (AFAIK doesn't work on Windows 2000 and
>> XP) and
>> V4.0 (which entirely eliminates isolated module compliation).
>
>
> And as such is non-conforming and cannot be made to conform. That is not
> to say that I do not like the approach that was taken by IBM, just that
> it will always result in code that can behave differently from the way
> specified by the C++ Standard.
>

I thought that the C++ standard had nothing at all to say about the
subject of linking files together?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bqkt8a$8r8$1@pump1.york.ac.uk>, chris
<chris@bubblescope.net> writes
>>   And as such is non-conforming and cannot be made to conform. That
>>is not  to say that I do not like the approach that was taken by IBM,
>>just that  it will always result in code that can behave differently
>>from the way  specified by the C++ Standard.
>>
>
>I thought that the C++ standard had nothing at all to say about the
>subject of linking files together?

But it does have a lot to say about context. The IBM implementation
makes things visible which should not be and thereby introduces subtle
differences from the separate TUs which is what the Standard deals with.


--
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

chris@bubblescope.net (chris) wrote in message news:<bqkt8a$8r8$1@pump1.york.ac.uk>...
> Francis Glassborow wrote:
> > In article <bpu4e8$clj$1@online.de>, Ekkehard Morgenstern
> > <ekkehard.morgenstern@onlinehome.de> writes
> >
> >>
> >> "Razmig K" <strontium90@postmaster.co.uk> schrieb im Newsbeitrag
> >> news:3cad08b8.0311171811.2760c086@posting.google.com...
> >>
> >>> please name any recent C++ compiler that can handle 'export'ing
> >>> templates for effective separate compilation.
> >>> Thank you.
> >>
> >>
> >> IBM Visual Age for C++ V3.5 (AFAIK doesn't work on Windows 2000 and
> >> XP) and
> >> V4.0 (which entirely eliminates isolated module compliation).
> >
> >
> > And as such is non-conforming and cannot be made to conform. That is not
> > to say that I do not like the approach that was taken by IBM, just that
> > it will always result in code that can behave differently from the way
> > specified by the C++ Standard.
> >
>
> I thought that the C++ standard had nothing at all to say about the
> subject of linking files together?

See section 2, paragraphs 1 and 2. They say that a C++ program can be
constructed from multiple translation units built from seperate source
code files, which can be linked together. Two source code files can be
part of the same translation unit only as result of one of them
#including the other, directly or indirectly. A great many of the
rules in the standard apply only within a single translation unit, or
allow things to be different in different translation units. Some of
those rules are violated by any implmentation which treats an entire
multi-file program as if it were a single translation unit.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Dear mates,

please name any recent C++ compiler that can handle 'export'ing
templates for effective separate compilation.
Thank you.

//rk

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

I think, there is only the Comeau C++. => www.comeaucomputing.com

Ralf
  www.oop-trainer.de


"Razmig K" <strontium90@postmaster.co.uk> schrieb im Newsbeitrag
news:3cad08b8.0311171811.2760c086@posting.google.com...
> Dear mates,
>
> please name any recent C++ compiler that can handle 'export'ing
> templates for effective separate compilation.
> Thank you.
>
> //rk
>
> ---
> [ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]
>


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Comeau C++ compiler.

"Razmig K" <strontium90@postmaster.co.uk> wrote in message
news:3cad08b8.0311171811.2760c086@posting.google.com...
> Dear mates,
>
> please name any recent C++ compiler that can handle 'export'ing
> templates for effective separate compilation.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

The C++ from Sun Microsytems recognizes 'export' as a keyword, but does
nothing special with it. The compiler has always supported separate
compilation of template instances, using the model introduced by Cfront
in around 1992.

You can put template definitions in a separate file that will be read
automatically, and only when needed, meaning that compilations that
don't use the template definitions don't need to process them.

If you select the compilation model that uses a template cache, only one
copy of the template instance will be created. Once created, the
compiler automatically recognizes that the instance does not need to be
created again.

The current shipping compiler also allows you to avoid using a cache,
generating template instances automatically as referenced.  That is, any
object file will have at most one copy of a template instance, but that
instance might be duplicated in other object files.  The linker discards
duplicates at program or library build time.

These template compilation models do not have semantics identical to the
export model, but I think the semantic model is easier to understand
than the export model. The export model requires synthesis of a
compilation environment that combines the environment of the template
definition and the point of template instantiation. The Cfront model in
effect inserts the template definition in the module where it is referenced.

Some people have the mistaken idea that exported templates allow you to
distribute a library of templates without providing source code for the
templates. Unfortunately that isn't the case. If a template instance
needs to be created, the source code for the template must be available.
The export model provides makes it easier to tell the compiler that a
referenced template instance is provided elsewhere.

--
Steve Clamage, stephen.clamage@sun.com

Razmig K wrote:
> Dear mates,
>
> please name any recent C++ compiler that can handle 'export'ing
> templates for effective separate compilation.
> Thank you.
>
>

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

stephen.clamage@sun.com (Steve Clamage) writes:

    [...]

|>  These template compilation models do not have semantics identical to
|>  the export model, but I think the semantic model is easier to
|>  understand than the export model.

Does the non-exported template model have the semantics required by the
standard?  Is the difference due to the different implementation of
"separate compilation", or simply that Sun (like many others) hasn't
fully implemented the subtilities of the standard model en general.

|>  The export model requires synthesis of a compilation environment
|>  that combines the environment of the template definition and the
|>  point of template instantiation.  The Cfront model in effect inserts
|>  the template definition in the module where it is referenced.

Exported or not, the standard has a complicated set of name lookup rules
which means that the compiler must consider two distinct "environments"
when it instantiates a template.  The two environments aren't quite the
same when export is involved, but other than that, the problem is in
fact the same.

Of course, the intent of export was, I think, to allow compiling
template code without the implementation sources.  Something that CFront
allowed, for example (but with radically different lookup rules, and a
somewhat different definition of the instantiation context, too, I
think).  That means somehow saving, or recreating, the instantiation
context outside of the compilation.

|>  Some people have the mistaken idea that exported templates allow you
|>  to distribute a library of templates without providing source code
|>  for the templates.

Implementers keeps saying that people are saying this, but I've never
actually heard anyone say it, or even wish it.  It's not a real problem,
and if it were, it is easily solvable, even without export.  (Sun has
delivered template libraries without human readable sources in the
past.)

What is important, of course, is that if I have 100 or more modules
using one particular template instantiation, and I modify the
implementation of that template, I don't have to recompile all of the
client code.  This IS true for the Comeau implementation, for example.

Note that the real problem here IS source code organization, and the way
makefiles work.  With the Sun implementation, there is no real reason to
compile more than what Comeau will recompile, export or not.  But the
"standard" source code organization without export means that this is
not what the makefiles will think, and that in practice, I will
recompile all of the client code.

|>  Unfortunately that isn't the case.  If a template instance needs to
|>  be created, the source code for the template must be available.

Something must be available.  Currently, in all implementations I know,
that something is the source code, albeit not necessarily in human
readable form.  (In some cases, at least with Sun CC 4.2, it was
encrypted.)  There is, however, certainly nothing to prevent using a
pre-tokenized binary format; I've not really studied the issue, but I
imagine that one could also develope some sort of byte code which would
contain enough information.

And let's face it, this sort of byte code is the way compilers are going
anyway.  To be really efficient, final optimization must be deferred to
the link phase, when all of the code is visible, and the output from the
compilation of a single translation unit will be some sort of byte code
with considerably more semantic information than most current object
file formats.

But of course, not many compilers are there yet.

|>  The export model provides makes it easier to tell the compiler that
|>  a referenced template instance is provided elsewhere.

It also changes the semantics.  I'm not sure that this is a good thing,
although if anything, all templates should have the semantics of
export. =20

But the problem goes beyond templates, and affects anything that must be
seen by more than one compilation unit.  What about the recent complaint
that including <fstream> (or was it <iostream>) in g++ defined a macro
named minor?  There is a fundamental problem in C++ here, and if we are
going to solve it (supposing it is solvable without completely breaking
everything), I would prefer to see a global solution which worked not
only for templates, but for inline functions, class definitions, and all
of the rest.

--=20
James Kanze                             mailto:kanze@gabi-soft.fr
Conseils en informatique orient=E9e objet/
                 Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France  +33 1 41 89 80 93

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Razmig K" <strontium90@postmaster.co.uk> schrieb im Newsbeitrag
news:3cad08b8.0311171811.2760c086@posting.google.com...
> please name any recent C++ compiler that can handle 'export'ing
> templates for effective separate compilation.
> Thank you.

IBM Visual Age for C++ V3.5 (AFAIK doesn't work on Windows 2000 and XP) and
V4.0 (which entirely eliminates isolated module compliation).

I don't know if the compiler is still manufactured or supported, or for
which platforms.



---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bpu4e8$clj$1@online.de>, Ekkehard Morgenstern
<ekkehard.morgenstern@onlinehome.de> writes
>
>"Razmig K" <strontium90@postmaster.co.uk> schrieb im Newsbeitrag
>news:3cad08b8.0311171811.2760c086@posting.google.com...
>> please name any recent C++ compiler that can handle 'export'ing
>> templates for effective separate compilation.
>> Thank you.
>
>IBM Visual Age for C++ V3.5 (AFAIK doesn't work on Windows 2000 and XP) and
>V4.0 (which entirely eliminates isolated module compliation).

And as such is non-conforming and cannot be made to conform. That is not
to say that I do not like the approach that was taken by IBM, just that
it will always result in code that can behave differently from the way
specified by the C++ Standard.
>
>I don't know if the compiler is still manufactured or supported, or for
>which platforms.

--
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]