Boost Workshop at OOPSLA 2004

[Thorsten Ottosen]

Re: Is export "useles s and broken"?

"Hyman Rosen" <hyrosen@mail.c om> wrote in message news:1092781403 .644981@master. nyc.kbcfp.com.. .
| Walter wrote:
| >From my readings on export, the benefits are supposed to be:
|
| The benefits of export are the same as the benefits of
| separate compilation of non-templated code.

| With
| export, users include the header file and they are done.

ok, but with separate compilation we get faster compilation. How much faster will/can the export version be?

Currently is also seriously tedious to implement class template member functions outside the class. I hope experience with
export can help promote class namespaces as described by Carl Daniel (see
http://www.open-std.org/jtc1/sc22/wg...2003/n1420.pdf ).

br

Thorsten



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Walter]

Re: Is export &quot;useles s and broken&quot;?


"Hyman Rosen" <hyrosen@mail.c om> wrote in message
news:1092781403 .644981@master. nyc.kbcfp.com.. .[color=blue]
> The benefits of export are the same as the benefits of
> separate compilation of non-templated code. That is, for
> normal code, I can write
>
> In joe.h:
> struct joe { void frob(); double gargle(double); };
> In joe.c:
> namespace { void fiddle() { } double grok() { return 3.7; } }
> void joe::frob() { fiddle(); }
> double joe::gargle(dou ble d) { return d + grok(); }
>
> And users of the joe class only include joe.h, and never
> have to worry about joe.c.[/color]

They would for templates, since the compiler will need to precompile it at
some point. You'd still have to put a dependency on joe.c in the makefile,
etc., since there's now an order to compiling the source files. Furthermore,
there's no indication to the compiler that the template implementation is in
joe.c, so some sort of cross reference would need building or it'd need to
be manually specified. That's all doable, of course, and is not that big an
issue, but I wished to point out that it isn't quite as simple as object
files are. A similar procedure is necessary for precompiled headers.
[color=blue]
> Without export, if joe were a
> template class, then every compilation unit which uses a
> method of joe would have to include the implementation of
> those methods bodily.[/color]

Yes, that's right. But just what are the benefits of separate compilation?
They are the 3 I mentioned. There is no semantic benefit that namespaces
can't address. (The old problem of needing to separate things because of
insufficient memory for compilation has faded away.)
[color=blue]
> This constrains the implementation;
> for example, that anonymous namespace wouldn't work.[/color]

I don't understand why namespaces wouldn't do the job. Isn't that kind of
problem exactly what namespaces were designed to solve?
[color=blue]
>With export, users include the header file and they are done.[/color]

So, we have, for the user:
export template foo ...
v.s.
#include "foo_implementa tion.h"

and they're done in either case. Sure, the former is slightly prettier, but
if we're going to overhaul C++ for aesthetic appeal, I'd do a lot of things
that are a LOT easier to implement before that one <g>.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Walter]

Re: Is export &quot;useles s and broken&quot;?


"tom_usenet " <tom_usenet@hot mail.com> wrote in message
news:9kg6i01j7j nhjrui14sf5sn37 ph5pkqu7v@4ax.c om...[color=blue]
> On 17 Aug 2004 18:03:15 -0400, "Walter"
> <walter@digital mars.nospamm.co m> wrote:[color=green][color=darkred]
> >>From my readings on export, the benefits are supposed to be:[/color]
> >
> >1) avoid pollution of the name space with the names involved in the
> >implementati on details of the template, sometimes called "code hygene"
> >
> >2) template source code hiding
> >
> >3) faster compilation[/color]
>
> 4) avoid pollution of the lookup context in which the template
> definition exists with names from the instantiation context, except
> where these are required (e.g. dependent names).[/color]

Shouldn't namespaces should cover this? That's what they're for.
[color=blue]
> 5) reduce dependencies[/color]

I think that is another facet of 1 and 4.
[color=blue][color=green]
> >Examining each of these in turn:[/color]
>
> Hmm, this is all rehashing I think.
>[color=green]
> >1) Isn't this what C++ namespaces are for?[/color]
>
> That ignores macros[/color]

I'll concede that it can help with macros, though I suggest that the
problems with macros remain and would be far better addressed with things
like scoped macros. Export is a particularly backwards way to solve problems
with the preprocessor, sort of like fixing rust by putting duct tape over it
<g>. Good practice with macros is to treat them all as having potentially
global effect.
[color=blue]
> and argument dependent lookup, which transcend
> namespaces (or rather operate in a slightly unpredictable set of
> namespaces in the case of the latter).[/color]

I don't see how this would be a problem.

[color=blue][color=green]
> >2) Given the ease with which Java .class files are "decompiled " back into
> >source code, and the fact that precompiled templates will necessarilly
> >contain even more semantic info than .class files, it is hard to see how
> >exported templates offer secure hiding of template implementations . It is
> >not analagous to the problem of "turning hamburger back into a cow" that
> >object file decompilers have. While some "security through obscurity" may[/color][/color]
be[color=blue][color=green]
> >achieved by not documenting the file format, if the particular compiler
> >implementati on is popular, there surely will appear some tool to do it.[/color]
>
> Precompiled templates don't need more semantic information than class
> files. In particular, all code involving non-dependent names can be
> fully compiled,[/color]

There's very little of that in templates, otherwise, they wouldn't need to
be templates. Realistically, I just don't see compiler vendors trying to mix
object code with syntax trees - the implementation cost is very high and the
benefit for a typical template is nil.
[color=blue]
> or at the very least, the names can be removed from
> the precompiled template file.[/color]

Removing a few names doesn't help much - .class files remove names from all
the locals, and that hasn't even slowed down making a decompiler for it.
[color=blue]
> In other words, the file format might
> consist of a combination of ordinary object code intermingled with
> other more detailed stuff.[/color]

Consider that within the precompiled template file, the compiler will need
to extract the names and offsets of all the members of the template classes,
coupled with the syntax trees of all the template functions, waiting to be
decorated with names and types. That is much more than what's in a .class
file. Another way to see this is that template files will necessarilly be
*before* the semantic stage of the compiler, whereas .class files are
generated *after* the semantic stage; more information can be thrown away in
the latter case.

[color=blue][color=green]
> >3) The faster compilation is theoretically based on the idea that the
> >template implementation doesn't need to be rescanned and reparsed every[/color][/color]
time[color=blue][color=green]
> >it is #include'd. However, many modern C++ compilers already support
> >"precompile d headers", which already provide just that capability without
> >export at all. I'd be happy to accept a compilation speed benchmark
> >challenge of Digital Mars DMC++ with precompiled headers vs an export
> >implementation .[/color]
> The compilation speed advantages also come from dependency reductions.
> If template definitions are modified, only the template
> specializations need to be recompiled. If the instantiation context
> (which I believe only consists of all extern names) is saved in each
> case, then the instantiation can be recompiled without having to
> recompile the whole TU containing the implicit template instantiation.[/color]

I'll still be happy to do the benchmark <g>. In my experience with projects
that attempted to maintain a complex dependency database, the time spent
maintaining it exceeded the time spent doing a global rebuild. Worse, the
dependency database was a rich source of bugs, so whenever there were
problems with the result, the first thing one tried was a global rebuild.
(For an example, consider "incrementa l linker" technology. You'd think that
would be a fairly easy problem, but incremental linkers suffered from so
many bugs that the first step in debugging was to do a clean build. Also,
Digital Mars' optlink does a full build faster than the incremental linkers
do an incremental one. Another example I know of is one where the dependency
database caused a year delay in the project and never did work right,
arguably causing the eventual failure of the entire project.)

[color=blue]
> So, ignoring implementation difficultly, I think export does just win
> as a useful feature. With the implementation difficultly, it's not so
> clear.[/color]

My problem is with the "ignoring implementation difficulty" bit. I attended
some of the C++ meetings early on, and a clear attitude articulated to me by
more than one member was that implementation difficulty was irrelevant, only
the user experience mattered. My opinion then, as now, is that
implementation difficulty strongly affects the users, since:

1) hard to implement features take a long time to implement, years in the
case of export, so users have to wait
2) hard to implement features usually result in buggy implementations that
take a long time to shake out
3) compiler vendors implement features in different orders, leading to
incompatible implementations
4) spending time on hard to implement features means that other features,
potentially more desirable to users, get backburnered

And we've all seen 1..4 impacting the users for years on end, and is still
ongoing.

There's another issue that may or may not matter depending on who you talk
to: hard to implement features wind up shrinking the number of
implementations . Back in the 80's, I once counted 30 different C compilers
available for just the IBM PC. How many different implementations of C++ are
there now? And it's still shrinking. I venture that a shrinking
implementation base is not good for the long term health of the language.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Hyman Rosen]

Re: Is export &quot;useles s and broken&quot;?

Walter wrote:[color=blue]
> "Hyman Rosen" <hyrosen@mail.c om> wrote[color=green]
>>And users of the joe class only include joe.h, and never
>>have to worry about joe.c.[/color]
>
> They would for templates, since the compiler will need to precompile it at
> some point. You'd still have to put a dependency on joe.c in the makefile,
> etc., since there's now an order to compiling the source files.[/color]

If this comes to you from a library provider, they could ship
compiled versions of the implementation file, just as they now
ship object files (assuming the compiler vendor supplied such
support). If it's your own templates, you simply make your
overall project depend on the implementation files if your
vendor uses the freedom given by 14/9 to force you to compile
the implementations first.

[color=blue]
> Furthermore, there's no indication to the compiler that the
> template implementation is in joe.c, so some sort of cross
> reference would need building or it'd need to be manually
> specified. That's all doable, of course, and is not that big
> an issue, but I wished to point out that it isn't quite as
> simple as object files are.[/color]

How is it different from object files? For normal source files
you must specify which object files are part of your program,
what their source files are, and what other files they depend
on. Some of this is done automatically by various development
platforms, but it is always done. How are exported templates
different?
[color=blue]
> But just what are the benefits of separate compilation?
> They are the 3 I mentioned. There is no semantic benefit
> that namespaces can't address.[/color]

I will believe this once you agree that C++ should require
definitions of all functions, template or not, to be included
in every compilation unit which calls them. If you do not
agree that this is a good idea for plain functions, I do not
see why it's a good idea for function templates.
[color=blue]
> I don't understand why namespaces wouldn't do the job.
> Isn't that kind of problem exactly what namespaces were
> designed to solve?[/color]

No. By requiring that implementations be bodily included
where instantiations are needed, the implementations are,
first, subject to the various pollutions of the instantiation
space, not least of which are macros, and secondly, are not
able to use anonymous namespaces since that will break the
ODR. As I said, unless you can convince me that the inclusion
model is good for ordinary methods, I have no reason to believe
that it's good for template methods.

[color=blue]
> So, we have, for the user:
> export template foo ...
> v.s.
> #include "foo_implementa tion.h"
> and they're done in either case.[/color]

You fail to see that the second case exposes the implementation
to the vagaries of the instantiation environment while the first
does not. Think of macros if nothing else.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Hyman Rosen]

Re: Is export &quot;useles s and broken&quot;?

Thorsten Ottosen wrote:[color=blue]
> ok, but with separate compilation we get faster compilation.
> How much faster will/can the export version be?[/color]

Faster by a factor of 3.7. The point is not to have faster
compilation, although that would be nice, but to have cleaner
compilation, so that implementations do not intertwine with
the usage environments any more than required by the lookup
rules.
[color=blue]
> Currently is also seriously tedious to implement class
> template member functions outside the class.[/color]

Huh? Why? Just because you have to repeat the template
header part? That's not that much more onerous than
repeating ClassName:: in front of ordinary methods.
Make a macro if it's that bothersome. With export, you
won't have to worry about the macros colliding with
client code!

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Hyman Rosen]

Re: export (WAS: Boost Workshop at OOPSLA 2004) (WILL BE: Save Andrei)

Andrei Alexandrescu (See Website for Email) wrote:[color=blue]
> What is the few-words good explanation of export?[/color]

Here's my attempt:
Because of historical reasons having to do with how templates are
implemented, template methods (and static data members) are
effectively considered inline, and so their definitions must be
included in any compilation unit which requires an instantiation.

The export keyword breaks this requirement. When a template method
is marked as export, its definition does not get included into
compilation units which use it. Instead, it goes into its own source
file(s), and is compiled separately.

The C++ standard permits an implementation to require that the
definition of an exported method or object must be compiled before a
reference to such an object is compiled.
[color=blue]
> 2. export failed horribly at doing what was initially supposed to do. I
> believe what it was supposed to do was true separate compilation of templates.[/color]

Compilation of templates is obviously not like compilation of ordinary
source, since template instantiation requires information from the
instantiation context and from the template parameters. But what do you
mean by "true" separate compilation? What kind of separate compilation
is not true? I understand that some people wish that export should be a
way to prevent people from examining template implementation code, but
that's hardly something for the standard to worry about. I understand
that some people either think or wish that export should affect how
temnplates are instantiated, but export has nothing to do with that.

To express it as simply as possible, imagine that C++ required that every
function be declared inline, and that therefore the implementation of every
function must be included in any compilation unit that used it. This is the
model that unexported templates labor under, and is what export is designed
to avoid.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Walt Karas]

Re: Boost Workshop at OOPSLA 2004

jeremy.siek@gma il.com (Jeremy Siek) wrote in message news:<21925601. 0408090845.4a6d 6a7c@posting.go ogle.com>...[color=blue]
> CALL FOR PAPERS/PARTICIPATION
>
> C++, Boost, and the Future of C++ Libraries
> Workshop at OOPSLA
> October 24-28, 2004
> Vancouver, British Columbia, Canada
> http://tinyurl.com/4n5pf[/color]

I don't have the time to pursue it myself, but maybe someone else might.

I have written a prototype for an alternative approach to generic
ordered containers.

http://www.geocities.com/wkaras/gen_cpp/avl_tree.html

For someone who says: "I have some instances of a type that I want
to keep in order; I don't mind if the instances are copied in and
out of the heap as the means of storing them in order", STL map/set
are what they're looking for.

For someone who says, "I have some 'things' that I want to keep in
order; the 'things' are unique identified by 'handles'; I am willing
to 'palletize' my 'things' so that each one can store the link 'handles'
necessary to form the container; I don't (necessarily) want to copy
the 'things', and I don't want the container to rely on the heap; I'm
willing to provide more 'glue logic' than what's needed when using
map or set", this alternative type of ordered container is what
they're looking for.

This approach has similarities with the approach that relies on
the items to be collected having a base class with the links
needed to form the container. But it is significantly more
flexible.

On the other hand, given the existence of the WWW, I'm not sure
it's worth the effort to add more templates to the standard lib.
when they can easily be implemented in a portable way. It seems like
the standard lib. is becoming like the Academy Awards for good
code, rather than a way of making it easier to write portable
code.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Jerry Coffin]

Re: export (WAS: Boost Workshop at OOPSLA 2004) (WILL BE: Save Andrei)

"Andrei Alexandrescu \(See Website for Email\)"

[ ... ]
[color=blue]
> I'd say, a good feature, like a good business idea, can be explained in a
> few words. What is the few-words good explanation of export? (I *am*
> interested.)[/color]
[color=blue]
>From what I've heard, the good explanation is that it prevented a[/color]
civil war in the C++ committee, so without it there might not be a C++
standard at all (or at least it might have been delayed considerably).

As to why people thought they wanted it: so it would be possible to
distribute template code as object files in libraries, much like
non-template code is often distributed. I don't believe that export,
as currently defined, actually supports this though.
[color=blue]
> Does it do what it was intended to do? (Again, I *am* interested.)[/color]

It's hard to say without certainty of the intent. Assuming my guess
above at the intent was correct, then I'm quite certain it does NOT do
what's intended.

If, OTOH, the idea is that template code is still distributed as
source code, and export merely allows that source code to be compiled
by itself, then it does what was intended, within a limited scope.

OTOH, if that was desired to speed up compilation, then I think it
basically fails -- at least with Comeau C++, compiling the templates
separately doesn't seem to gain much, at least for me (and since I
have no other compilers that support, or even plan to soon support
export, Comeau is about the only one that currently matters).

[ ... ]
[color=blue]
> 2. export failed horribly at doing what was initially supposed to do. I
> believe what it was supposed to do was true (not "when"s and "cough"s and
> "um"s) separate compilation of templates. Admittedly, gaffes in other areas
> of language design are at fault for that failure. Correct me if I'm wrong.[/color]

I don't know how much is true gaffes, and how much the simple fact
that templates are enough different from normal code that what was
expected was simply (at least extremely close to) impossible.
[color=blue]
> 3. export failed miserably at being reasonably easy to implement.[/color]

I can hardly imagine how anybody could argue that one.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Thorsten Ottosen]

Re: Is export &quot;useles s and broken&quot;?

"Hyman Rosen" <hyrosen@mail.c om> wrote in message news:1092861868 .153157@master. nyc.kbcfp.com.. .

| > Currently is also seriously tedious to implement class
| > template member functions outside the class.
|
| Huh? Why? Just because you have to repeat the template
| header part?

yes.

| That's not that much more onerous than
| repeating ClassName:: in front of ordinary methods.

many templates have several parameters; then they might have templated member functions.
This get *very* tedious to define outside a class.

br

Thorsten



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Daveed Vandevoorde]

Re: export (WAS: Boost Workshop at OOPSLA 2004) (WILL BE: Save Andrei)

"Andrei Alexandrescu wrote:[color=blue]
> "Daveed Vandevoorde" <google@vandevo orde.com> wrote in message
> news:52f2f9cd.0 408161420.56e0d 49f@posting.goo gle.com...[color=green]
> > "Andrei Alexandrescu wrote:
> > [...][color=darkred]
> > > Maybe "export" which is so broken and so useless and so abusive that its
> > > implementers have developed Stockholm syndrome during the long years
> > > that
> > > took them to implement it?[/color]
> >
> > How is "export" useless and broken?
> >
> > Have you used it for any project? I find it very pleasant
> > to work with in practice.[/color]
>
> Haven't used export, and not because I didn't wanna.[/color]

What has prevented you from at least trying it? An affordable
implementation has been available for well over a year.

Without doing so, I fail to see how you can objectively make the
assertions you made.
[color=blue]
> [Whom do you think I referred to when mentioning the Stockholm syndrome?
> :o)][/color]

Adding a smiley to an innapropriate remark does not make it
any more appropriate.
[color=blue]
> I'd say, a good feature, like a good business idea, can be explained in a
> few words. What is the few-words good explanation of export? (I *am*
> interested.)[/color]

It allows you to separate a function, member function, or static data
member implementation ("definition ") in a single translation unit.
[color=blue]
> In addition, a good programming language feature does what it was intended
> to do (plus some other neat things :o)), and can be reasonably implemented.[/color]

To clarify: That is "good" in your personal point of view.

The intent of the feature was to protect template definitions from
"name leakage" (I think that's the term that was used at the time;
it refers to picking up unwanted declaration due to excessive
#inclusion). export certainly fulfills that.

export also allows code to be compiled faster. (I'm seeing gains
without even using an export-aware back end.)

export also allows the distribution of templates in compiled form
(as opposed to source form).
[color=blue]
> I think we all agree "export" fell the last test.[/color]

export was hard to implement for us, no doubt.
[color=blue]
> Does it do what it was intended to do? (Again, I *am* interested.)[/color]

Yes, and more. See above.
[color=blue]
> A summary of what's the deal with export would be of great help to at least
> myself, so I'd be indebted to anyone who'd give me one. For full disclosure,
> my current perception is:
>
> 1. It's hard to give a good account of what export does in a few words, at
> least an account that's impressive.[/color]

Impressive is in the eye of the beholder. Whenever I use the feature,
I'm impressed that it works so smoothly.
[color=blue]
> 2. export failed horribly at doing what was initially supposed to do. I
> believe what it was supposed to do was true (not "when"s and "cough"s and
> "um"s) separate compilation of templates. Admittedly, gaffes in other areas
> of language design are at fault for that failure. Correct me if I'm wrong.[/color]

How does it fail at separate compilation?
[color=blue]
> 3. export failed miserably at being reasonably easy to implement.[/color]

While it is true that it was hard to implement for EDG (I am not aware of
anyone else having even tried), it was never claimed by the proponents
that it would be easy to implement.

After EDG implemented export, Stroustrup once asked what change to
C++ might simplify its implementation without giving up on the separate
compilation aspect of it. I couldn't come up with anything other than the
very drastic notion of making the language 100% modular (i.e., every entity
can be declared in but one place). That doesn't mean that a template
separation model is not desirable.
[color=blue]
> Combined with 1 and 2, I can only say: at the very best, export is a Pyrrhic
> victory.[/color]

The history C++ "export" feature may well be the very incarnation of irony.
However, I don't think there is a matter of "victory" here.

I contend that, all other things being equal, export templates are more
pleasant to work with than the equivalent inclusion templates. That by
itself is sufficient to cast doubt on your claim that the feature is "broken
and useless."

Daveed

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Gabriel Dos Reis]

Re: export (WAS: Boost Workshop at OOPSLA 2004) (WILL BE: Save Andrei)

Hyman Rosen <hyrosen@mail.c om> writes:

| Andrei Alexandrescu (See Website for Email) wrote:
| > What is the few-words good explanation of export?

Do those few-words need to be technical or are they marketing purpose?
This is a genuine question, as I suspect that too much hype and
marketing have been pushed against export. That impression I got was
not cleared up after discussion of a well kown paper.

| Here's my attempt:
| Because of historical reasons having to do with how templates are
| implemented, template methods (and static data members) are
| effectively considered inline, and so their definitions must be
| included in any compilation unit which requires an instantiation.

I think that use of "inline" is unfortunate. I don't think that
description accurately covers what CFront did and other historical
repository-based instantiations (like in old Sun CC).

Export is the result of a compromise. A compromise between tenants of
inclusion model only and tenants of separate compilation of templates.

--
Gabriel Dos Reis
gdr@integrable-solutions.net

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Walter]

Re: export (WAS: Boost Workshop at OOPSLA 2004) (WILL BE: Save Andrei)


"Hyman Rosen" <hyrosen@mail.c om> wrote in message
news:1092864307 .563385@master. nyc.kbcfp.com.. .[color=blue]
> To express it as simply as possible, imagine that C++ required that every
> function be declared inline, and that therefore the implementation of[/color]
every[color=blue]
> function must be included in any compilation unit that used it. This is[/color]
the[color=blue]
> model that unexported templates labor under, and is what export is[/color]
designed[color=blue]
> to avoid.[/color]

In the D programming language, all functions are potentially inline (at the
compiler's discretion), and so all the function bodies are available, even
though it follows the separate compilation model. All the programmer does is
use the statement:

import foo;

and the entire semantic content of foo.d is available to the compiler,
including whatever template and function bodies are in foo.d. So, is this a
burden the compiler labors under? Not that anyone has noticed, it compiles
code at a far faster rate than a C++ compiler can. I can go into the reasons
why if anyone is interested.

But back to what can be done with C++. Many compilers implement precompiled
headers, which do effectively address this problem reasonably well. Export
was simply not needed to speed up compilation, and for those who don't
believe me, I stand by my challenge to benchmark Digital Mars C++ with
precompiled headers against any export template implementation for project
build speed.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Walter]

Re: Is export &quot;useles s and broken&quot;?


"Hyman Rosen" <hyrosen@mail.c om> wrote in message
news:1092860733 .240922@master. nyc.kbcfp.com.. .[color=blue]
> Walter wrote:[color=green]
> > "Hyman Rosen" <hyrosen@mail.c om> wrote[color=darkred]
> >>And users of the joe class only include joe.h, and never
> >>have to worry about joe.c.[/color]
> >
> > They would for templates, since the compiler will need to precompile it[/color][/color]
at[color=blue][color=green]
> > some point. You'd still have to put a dependency on joe.c in the[/color][/color]
makefile,[color=blue][color=green]
> > etc., since there's now an order to compiling the source files.[/color]
>
> If this comes to you from a library provider, they could ship
> compiled versions of the implementation file, just as they now
> ship object files (assuming the compiler vendor supplied such
> support). If it's your own templates, you simply make your
> overall project depend on the implementation files if your
> vendor uses the freedom given by 14/9 to force you to compile
> the implementations first.[/color]

I agree it's not a big problem, it just isn't as simple as not having to
worry about joe.c <g>.
[color=blue][color=green]
> > Furthermore, there's no indication to the compiler that the
> > template implementation is in joe.c, so some sort of cross
> > reference would need building or it'd need to be manually
> > specified. That's all doable, of course, and is not that big
> > an issue, but I wished to point out that it isn't quite as
> > simple as object files are.[/color]
> How is it different from object files? For normal source files
> you must specify which object files are part of your program,
> what their source files are, and what other files they depend
> on. Some of this is done automatically by various development
> platforms, but it is always done. How are exported templates
> different?[/color]

The cross reference database is what the librarian does <g>. And again, I
agree that this is not a huge problem, but it is a problem and it does, for
example, impose an order on the compilations that was not required before.
But I'll also say that, as a compiler vendor, one of the most common tech
questions I get is "I am getting an undefined symbol message from the
linker, what do I do now?" I imagine this would be worse with template
interdependenci es, but I could be wrong.

[color=blue][color=green]
> > But just what are the benefits of separate compilation?
> > They are the 3 I mentioned. There is no semantic benefit
> > that namespaces can't address.[/color]
> I will believe this once you agree that C++ should require
> definitions of all functions, template or not, to be included
> in every compilation unit which calls them. If you do not
> agree that this is a good idea for plain functions, I do not
> see why it's a good idea for function templates.[/color]

The D language does this, and it works fine. I've also heard of C++
compilers that do cross-module optimization that do this as well. Good idea
or not, it is doable with far less effort than export. But I emphasize that
the way the C++ language was designed makes it *easy* to implement separate
compilation for functions. That same design makes it *very hard* to do
separate compilation for templates, no matter how conceptually the same we
might wish them to be. If C++ had the concept of modules (rather than its
focus on source text), this would not be such a big problem. And it is not
enough that an idea be just a good idea, its advantages must outweigh the
costs. The costs of export are enormous, and the corresponding enormous gain
just isn't there.

[color=blue][color=green]
> > I don't understand why namespaces wouldn't do the job.
> > Isn't that kind of problem exactly what namespaces were
> > designed to solve?[/color]
> No. By requiring that implementations be bodily included
> where instantiations are needed, the implementations are,
> first, subject to the various pollutions of the instantiation
> space, not least of which are macros, and secondly, are not
> able to use anonymous namespaces since that will break the
> ODR.[/color]

Why not use a named namespace?
[color=blue][color=green]
> > So, we have, for the user:
> > export template foo ...
> > v.s.
> > #include "foo_implementa tion.h"
> > and they're done in either case.[/color]
>
> You fail to see that the second case exposes the implementation
> to the vagaries of the instantiation environment while the first
> does not. Think of macros if nothing else.[/color]

I'll agree on the macro issue, but nothing else <g>. And to repeat what I
said earlier about the macro issue, export seems to be an awfully expensive
solution to the macro scoping problem, especially since the macro pollution
issue still remains. Wouldn't it be better to come at the macro problem
head on?


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Andrei Alexandrescu \(See Website for Email\)]

Re: export (WAS: Boost Workshop at OOPSLA 2004) (WILL BE: Save Andrei)

"Hyman Rosen" <hyrosen@mail.c om> wrote in message
news:1092864307 .563385@master. nyc.kbcfp.com.. .[color=blue]
> Andrei Alexandrescu (See Website for Email) wrote:[color=green]
> > What is the few-words good explanation of export?[/color]
>
> Here's my attempt:
> Because of historical reasons having to do with how templates are
> implemented, template methods (and static data members) are
> effectively considered inline, and so their definitions must be
> included in any compilation unit which requires an instantiation.
>
> The export keyword breaks this requirement. When a template method
> is marked as export, its definition does not get included into
> compilation units which use it. Instead, it goes into its own source
> file(s), and is compiled separately.
>
> The C++ standard permits an implementation to require that the
> definition of an exported method or object must be compiled before a
> reference to such an object is compiled.[/color]

Thanks.
[color=blue][color=green]
> > 2. export failed horribly at doing what was initially supposed to do. I
> > believe what it was supposed to do was true separate compilation of
> > templates.[/color]
>
> Compilation of templates is obviously not like compilation of ordinary
> source, since template instantiation requires information from the
> instantiation context and from the template parameters. But what do you
> mean by "true" separate compilation? What kind of separate compilation
> is not true?[/color]

By "true" separate compilation I understand the dependency gains that
separate compilation achieves. That is crucial, and whole projects can be
organized around that idea. It translates into what needs be compiled when
something is touched, with the expected build speed and stability tradeoffs.

Templates cannot be meaningfully typechecked during their compilation. They
also cause complications when instantiated in different contexts. That makes
them unsuitable for "true" separate compilation. Slapping a keyword that
makes them appear as separately compilable while the true inside the
compilation system guts is different (in terms of dependency management and
compilation speed) didn't help.
[color=blue]
> I understand that some people wish that export should be a
> way to prevent people from examining template implementation code, but
> that's hardly something for the standard to worry about.[/color]

I consider that a secondary issue.
[color=blue]
> To express it as simply as possible, imagine that C++ required that every
> function be declared inline, and that therefore the implementation of
> every
> function must be included in any compilation unit that used it. This is
> the
> model that unexported templates labor under, and is what export is
> designed
> to avoid.[/color]

I don't think that that's a good parallel. Because the non-inline functions
can be typechecked and compiled to executable code in separation. Templates
cannot.


Andrei



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Andrei Alexandrescu \(See Website for Email\)]

Re: export (WAS: Boost Workshop at OOPSLA 2004) (WILL BE: Save Andrei)

"Jerry Coffin" <jcoffin@taeus. com> wrote in message
news:b2e4b04.04 08181428.295807 1b@posting.goog le.com...[color=blue][color=green]
>> 2. export failed horribly at doing what was initially supposed to do. I
>> believe what it was supposed to do was true (not "when"s and "cough"s and
>> "um"s) separate compilation of templates. Admittedly, gaffes in other
>> areas
>> of language design are at fault for that failure. Correct me if I'm
>> wrong.[/color]
>
> I don't know how much is true gaffes, and how much the simple fact
> that templates are enough different from normal code that what was
> expected was simply (at least extremely close to) impossible.[/color]

Fundamentally templates are sensitive to the point where they are
instantiated, and not on the parameters alone. That's a classic PL design
mistake because it undermines modularity. The effects of such a mistake are
easily visible :o). They've been visible in a couple of early languages as
well.

Andrei



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]