Steve Clamage wrote:
> On Mon, 25 Jan 2010 11:42:36 CST, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> Steve Clamage wrote:
>>> The paper referenced above recommended (in 2003) that export be
>>> removed from the language. The committee voted to keep export. I do
>>> not believe the issue will be raised again.
>> I seem to vaguely recall the arguments for keeping export back after
>> Herb's paper, are there some minutes available online, or could you
>> summarize them?
>
> The paper was discussed at the April 2003 meeting. The minutes
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1459.html
> do not contain a record of the discussion. My recollection is that
> some people were not moved by the arguments against export; others
> felt that removing a relatively new feature (5 years old at the time,
> when C++ over 15 years old) was a bad precedent; still others felt
> that removing the feature would be seen as unfair to EDG, who had done
> the hard work of implementing the feature. In the end, there was
> little support for removing the feature, and less support for
> discussing the issue any more.

Thanks Steve. I'll just note that of the arguments you mention, both are
tenuous. As of this time the feature is 12 years old with little to show
for its maturity. Second argument comes below.

>> Now that a positive precedent has been created by the demise of
>> concepts, maybe the issue of eliminating export would be met quite
>> favorably nowadays.
>
> The situations are not comparable. Export has been in the C++ standard
> since the beginning (final draft in 1997, published in 1998). Concepts
> were first proposed several years ago, but no agreement was ever
> reached on their final form, and they never appeared in an actual
> standard. They were removed from the draft because the committee felt
> that a final version was still 2 to 3 years away.

I may be seeing more parallels than others, but I can say that there's
been a lot of work done on concepts, yet they were ditched. So the
sympathy argument doesn't strike me as very solid. (I think it's a weak
argument without this counterexample anyway.) Yes, there's been
commendable work done on export. How much more work is needed until the
admission there's no oil in that pit?

Given the circumstances, I think it's worth revisiting the issue with
the question: since 2003 when the Committee decided to not discuss this
subject anymore, how much progress has been made with regard to export
implementation and experience?


Andrei

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 25, 12:42 pm, Andrei Alexandrescu
<SeeWebsiteForEm...@erdani.org> wrote:
> Steve Clamage wrote:
> > The paper referenced above recommended (in 2003) that export be
> > removed from the language. The committee voted to keep export. I do
> > not believe the issue will be raised again.
>
> I seem to vaguely recall the arguments for keeping export back after
> Herb's paper, are there some minutes available online, or could you
> summarize them?

More recently, this issue was discussed at the Santa Cruz meeting. See
the minutes starting at page 17 in the following document:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n3003.pdf

The summary is:

"Adamczyk interpreted the vote as the group having a pretty strong
feeling towards deprecation, and against leaving as-is. He stated that
for this reason, he expected some action from the core working group
in next meeting."

Stefanus Du Toit


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Steve Clamage wrote:
> On 01/22/10 10:14, Timothy Madden wrote:
[...]
>>> I think this sums up the issue pretty
>>> well:http://www.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1426.pdf
>
>>
>> I have seen the paper. It is subjective and biased against export.
>
> The paper presents facts, and quotes from the team that implemented
> export. The team members all said it was not worth the effort (they
> did it only so they could claim complete conformance to the standard),
> and their advice to other implementers was not to implement the
> feature.
>
> As to whether the paper is biased, it presents the authors' point of
> view, as do all papers on any topic. Perhaps you could point out
> examples of actual bias. For example, do the authors omit some
> arguments in favor of the export feature, or unfairly criticize
> arguments they do show? (Even then you can't assume bias. I have known
> the authors personally for many years, and I seldom have met more
> fair-minded people.)
>

That paper was discussed long time ago and people were against it.

The team implementing export, quoted there as proof that export is
wrong, did not support the paper, and Daveed Vandevoorde in that team in
fact supported export in any serious discussion about the feature, and
said EDG was against it when the feature was first introduced.
EDG was actually willing to support with advice based on their
experience anyone wanting to implement export.

It should also say the reason for export is to provide declarations-only
for templates, with the effect of using external templates much like
external functions or external symbols in non-template code. The
benefits are clean and organized template code for the end-users.

The paper will tell that export only hides dependencies, that it is
misunderstood, that it produces confusion, but in fact the export
keyword does exactly what it is supposed to do. It is only doing the job
in a different perspective, since we are now in template code.

Supporting disagreement with the standard on a newly-introduced language
feature, that paper has done more harm then any good. :(


>> They say it could take 2 up to 3 man-years for a company to implement.
>> Well for a company this means less than one year, with more than one
>> programmer, which is reasonable.
>
> Don't fall into the trap of Brooks's Law. Putting 9 women on the job
> won't get you a baby in one month. :-)
>
> You gloss over the cost by saying it is reasonable. By what standard?

Reasonable as in "it fits in a release cycle" with but a few programmers.


>
> I'd like to see a case study that shows how the export feature has
> proved important to the development of an application. For example,
> how development time was reduced, or made easier, or made the
> application more robust or more maintainable. I don't know of any such
> papers.

What proves important for the development of an application are also
design, understanding the requirements and making the right choices and
estimates for resources. Export is but a language feature. Any C++
application in the world can be written with or without export, just as
any C++ application can be written in plain C.

Thinking of the separation between declaration and definition that it
introduces, export does make programs more robust and maintainable.

Thank you,
Timothy Madden

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 26, 10:08 pm, Andrei Alexandrescu
<SeeWebsiteForEm...@erdani.org> wrote:
> Steve Clamage wrote:
> > On Mon, 25 Jan 2010 11:42:36 CST, Andrei Alexandrescu
> > <SeeWebsiteForEm...@erdani.org> wrote:

> >> Steve Clamage wrote:
> >>> The paper referenced above recommended (in 2003) that
> >>> export be removed from the language. The committee voted
> >>> to keep export. I do not believe the issue will be raised
> >>> again.
> >> I seem to vaguely recall the arguments for keeping export
> >> back after Herb's paper, are there some minutes available
> >> online, or could you summarize them?

> > The paper was discussed at the April 2003 meeting. The
> > minutes
> >http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1459.html
> >do not contain a record of the discussion. My recollection is
> >that some people were not moved by the arguments against
> >export; others felt that removing a relatively new feature (5
> >years old at the time, when C++ over 15 years old) was a bad
> >precedent; still others felt that removing the feature would
> >be seen as unfair to EDG, who had done the hard work of
> >implementing the feature. In the end, there was little
> >support for removing the feature, and less support for
> >discussing the issue any more.

> Thanks Steve. I'll just note that of the arguments you
> mention, both are tenuous. As of this time the feature is 12
> years old with little to show for its maturity. Second
> argument comes below.

Yes and no.  In the absense of export, people don't use
templates.  We got along without them for years before the
standard, and we can still get along without them for all but
the lowest level (and most stable) code today.  It's a shame,
because there are a lot of nice things that can be done with
templates.  But the price (in terms of coupling) is too high.
And since no other language I know offers the power of C++
templates, so switching to another language won't buy us
anything either.

> >> Now that a positive precedent has been created by the
> >> demise of concepts, maybe the issue of eliminating export
> >> would be met quite favorably nowadays.

> > The situations are not comparable. Export has been in the
> > C++ standard since the beginning (final draft in 1997,
> > published in 1998). Concepts were first proposed several
> > years ago, but no agreement was ever reached on their final
> > form, and they never appeared in an actual standard. They
> > were removed from the draft because the committee felt that
> > a final version was still 2 to 3 years away.

> I may be seeing more parallels than others, but I can say that
> there's been a lot of work done on concepts,

Maybe too much:-).  The problem is, I think, that there are
several incompatible solutions.

--
James Kanze

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Steve Clamage wrote:
[...]
> The paper was discussed at the April 2003 meeting. The minutes
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1459.html
> do not contain a record of the discussion. My recollection is that
> some people were not moved by the arguments against export; others
[...]

Exactly! Some people are not moved by the arguments against export.


This arguments are:

1. That it is difficult to implement.
     It is and it should be, export is a big change. Even so, the idea is
     if a small group at EDG could implement it, than a company can also
     implement it.

2. That it is difficultto use correctly, it is underspecified, it is not
       well understood.
     Sorry to say to say that it is /easy/ to use and it just works.
     Special cases that show up are not that important and work anyway.

3. Lack of demand.
     That is actually difficult to asses as long as it is yet hardly
     implemented. Once compilers will have export, anyone doubts that
     language users will all immediately adopted it and get rid of the
     huge headers they now use ?
     Even now I can see on MSDN blogs people saying they had to drop
     a certain compiler because their clients were using export.

4. It does not offer source code hiding or faster builds
     What reason is this to remove it ? Besides it does provide a start at
     source code hiding. Java also offers poor source hiding and people
     still ship .jar files, so the poor hiding that export could allow is
     still better than nothing.

Thank you,
Timothy Madden

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andrei Alexandrescu wrote:
>
> I may be seeing more parallels than others, but I can say that there's
> been a lot of work done on concepts, yet they were ditched. So the
> sympathy argument doesn't strike me as very solid. (I think it's a weak
> argument without this counterexample anyway.) Yes, there's been
> commendable work done on export. How much more work is needed until the
> admission there's no oil in that pit?
>

There's a much higher barrier to removing something from a standard than
there is for not putting it in in the first place. Export is part of the
C++ standard. Concepts are not. Removing concepts from the draft
standard is nowhere near as significant a change as removing export from
the standard.

--
    Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andrei Alexandrescu wrote:
[...]
> I may be seeing more parallels than others, but I can say that there's
> been a lot of work done on concepts, yet they were ditched. So the
> sympathy argument doesn't strike me as very solid. (I think it's a weak
> argument without this counterexample anyway.) Yes, there's been
> commendable work done on export. How much more work is needed until the
> admission there's no oil in that pit?
>
> Given the circumstances, I think it's worth revisiting the issue with
> the question: since 2003 when the Committee decided to not discuss this
> subject anymore, how much progress has been made with regard to export
> implementation and experience?

People, what exactly is it with export to give you such problems that
now you want to see it out of the standard ? I mean what would precisely
be the problem with keeping export ?


You think it is difficult to use ?
Than use whatever could be easier, the inclusion model would still be
available with export.

You think somehow it is not worth the effort ?
Then invest effort in issues that are worth the effort ...

You think it is a problem in the very language ?
Sorry but some other people do not share your views, and see it as a
feature. End-users for sure would be happy to have it.


Thank you,
Timothy Madden

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Timothy Madden wrote:
>
> Steve Clamage wrote:
> [...]
>>
>> The paper was discussed at the April 2003 meeting. The minutes
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1459.html
>> do not contain a record of the discussion. My recollection is that
>> some people were not moved by the arguments against export; others
>
> [...]
>
> Exactly! Some people are not moved by the arguments against export.
>
>
> This arguments are:
>
> 1. That it is difficult to implement.
>    It is and it should be, export is a big change. Even so, the idea is
>    if a small group at EDG could implement it, than a company can also
>    implement it.

True but as it requires fundamental alterations to some compilation
techniques it could well mean suspending all other development whilst
it is done.  I would hazard a guess that on some compilers that might
mean suspending all new work (for C++0X) for 18 months (and throwing
more resources at doing it would not significantly shorten development
time. I have been told by one implementer that adding export would,
for them, effectively mean a complete rewrite of their implementation
from the ground up. I do not know how true that is, maybe they just do
not want to do it.

>
> 2. That it is difficultto use correctly, it is underspecified, it is not
>      well understood.
>    Sorry to say to say that it is /easy/ to use and it just works.
>    Special cases that show up are not that important and work anyway.

It is impossible to use unless your implementation provides it. Any
code shop that has a basic requirement for code to compile
successfully with two independent implementations cannot use export.
Many heavy duty users have such a requirement.


>
> 3. Lack of demand.
>    That is actually difficult to asses as long as it is yet hardly
>    implemented. Once compilers will have export, anyone doubts that
>    language users will all immediately adopted it and get rid of the
>    huge headers they now use ?
>    Even now I can see on MSDN blogs people saying they had to drop
>    a certain compiler because their clients were using export.

Yes, and I can also see the other side of people dropping compilers
because they do not implement some other feature that they want (e.g.
move semantics)

>
> 4. It does not offer source code hiding or faster builds
>    What reason is this to remove it ? Besides it does provide a start at
>    source code hiding. Java also offers poor source hiding and people
>    still ship .jar files, so the poor hiding that export could allow is
>    still better than nothing.


Hiding or not is a non-issue though it was offered as a minor
incentive when it was originally discussed.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Timothy Madden wrote:
>
> Andrei Alexandrescu wrote:
> [...]
>>
>> I may be seeing more parallels than others, but I can say that there's
>> been a lot of work done on concepts, yet they were ditched. So the
>> sympathy argument doesn't strike me as very solid. (I think it's a weak
>> argument without this counterexample anyway.) Yes, there's been
>> commendable work done on export. How much more work is needed until the
>> admission there's no oil in that pit?
>>
>> Given the circumstances, I think it's worth revisiting the issue with
>> the question: since 2003 when the Committee decided to not discuss this
>> subject anymore, how much progress has been made with regard to export
>> implementation and experience?
>
> People, what exactly is it with export to give you such problems that
> now you want to see it out of the standard ? I mean what would precisely
> be the problem with keeping export ?

Put simply, it has only been implemented by a single implementer and
implementing it is very time-consuming so it looks unlikely that
anyone else will do so in the near future. Given that there is an
(excellent) implementation that people can try it might be significant
that there has not been a large demand from customers of commercial
implementations to have it.

>
>
> You think it is difficult to use ?
> Than use whatever could be easier, the inclusion model would still be
> available with export.

While most implementations do not support it using it just adds more
to any project whose writers desire portability (+ familiarity from
their maintenance staff)

>
> You think somehow it is not worth the effort ?
> Then invest effort in issues that are worth the effort ...

That is exactly what most implementers claim to be doing.

>
> You think it is a problem in the very language ?
> Sorry but some other people do not share your views, and see it as a
> feature. End-users for sure would be happy to have it.

Well not so happy that they are making any great demand for it (or
perhaps all the commercial implementers are in a conspiracy)

Now it is perfectly true that it is (desirably) much harder to remove
something from an existing standard than it is to add a feature.
However it is the general rule that Standards should follow existing
practice. I think it is too soon to remove export from the Standard
but if it is still not widely available when C++1X is being worked on,
I think that it will be time then to remove it.

I actually think it was a mistake putting it in in the first place but
that is an entirely different issue. It is there now and it should be
allowed a fair crack of the whip before being removed.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Adding to my own post:

On 01/25/10 11:10, Steve Clamage wrote:
>
> ... Concepts
> were first proposed several years ago, but no agreement was ever
> reached on their final form, and they never appeared in an actual
> standard. They were removed from the draft because the committee felt
> that a final version was still 2 to 3 years away.

Also, Concepts are not dead. The C++ committee wants the feature, and
work will continue on it. The next standard, the one after C++0X,
almost certainly will contain Concepts.

---
Steve Clamage

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Timothy Madden wrote:
>
> Andrei Alexandrescu wrote:
> [...]
>>
>> I may be seeing more parallels than others, but I can say that there's
>> been a lot of work done on concepts, yet they were ditched. So the
>> sympathy argument doesn't strike me as very solid. (I think it's a weak
>> argument without this counterexample anyway.) Yes, there's been
>> commendable work done on export. How much more work is needed until the
>> admission there's no oil in that pit?
>>
>> Given the circumstances, I think it's worth revisiting the issue with
>> the question: since 2003 when the Committee decided to not discuss this
>> subject anymore, how much progress has been made with regard to export
>> implementation and experience?
>
> People, what exactly is it with export to give you such problems that
> now you want to see it out of the standard ? I mean what would precisely
> be the problem with keeping export ?
>
>
> You think it is difficult to use ?
> Than use whatever could be easier, the inclusion model would still be
> available with export.
>
> You think somehow it is not worth the effort ?
> Then invest effort in issues that are worth the effort ...

One issue worth the effort is kicking export out of the language.

Andrei

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Francis Glassborow wrote:
[snip]
>
> Now it is perfectly true that it is (desirably) much harder to remove
> something from an existing standard than it is to add a feature.
> However it is the general rule that Standards should follow existing
> practice. I think it is too soon to remove export from the Standard
> but if it is still not widely available when C++1X is being worked on,
> I think that it will be time then to remove it.

Never mind that it's 1X already, but your conclusion came as a
surprise after all of your arguments. I mean, reading your post goes
like this: "Nobody will implement it... check. No demand... check.
Portability issues... check. Implementors not looking into it...
check. Alright, I'm convinced. Where do I sign the petition to give
export the electric chair? Oh, wait, there are two more paragraphs.
Keep it on the death row for 15 more years.... whaaaaa?"

> I actually think it was a mistake putting it in in the first place but
> that is an entirely different issue. It is there now and it should be
> allowed a fair crack of the whip before being removed.

That whip don't crack, Francis.


Andrei

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 28/01/2010 12:02, Francis Glassborow wrote:
>
> Timothy Madden wrote:
>>
>> You think it is a problem in the very language ?
>> Sorry but some other people do not share your views, and see it as a
>> feature. End-users for sure would be happy to have it.
>
> Well not so happy that they are making any great demand for it (or
> perhaps all the commercial implementers are in a conspiracy)
>
> Now it is perfectly true that it is (desirably) much harder to remove
> something from an existing standard than it is to add a feature.
> However it is the general rule that Standards should follow existing
> practice. I think it is too soon to remove export from the Standard
> but if it is still not widely available when C++1X is being worked on,
> I think that it will be time then to remove it.

Couldn't the "export" feature be classified as "conditionally
supported" (a term already used in the standard for some other
features)? It wouldn't have to removed from the standard but
implementations not providing it could still be standard compliant as
long as they document the fact that they don't support "export".

Falk

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Steve Clamage wrote:
>
> Adding to my own post:
>
> On 01/25/10 11:10, Steve Clamage wrote:
>>
>> ... Concepts
>> were first proposed several years ago, but no agreement was ever
>> reached on their final form, and they never appeared in an actual
>> standard. They were removed from the draft because the committee felt
>> that a final version was still 2 to 3 years away.
>
> Also, Concepts are not dead. The C++ committee wants the feature, and
> work will continue on it. The next standard, the one after C++0X,
> almost certainly will contain Concepts.
>
and I wish we had had the good sense to do the same with export.
Separate compilation of templates is fine but I am unconvinced that
export was the solution.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 28 Jan, 17:04, Falk Tannh   user <falk.tannhau...@crf.canon.fr>
wrote:
> On 28/01/2010 12:02, Francis Glassborow wrote:
> > Timothy Madden wrote:

> >> You think it is a problem in the very language ?
> >> Sorry but some other people do not share your views, and
> >> see it as a feature. End-users for sure would be happy to
> >> have it.

> > Well not so happy that they are making any great demand for
> > it (or perhaps all the commercial implementers are in a
> > conspiracy)

> > Now it is perfectly true that it is (desirably) much harder
> > to remove something from an existing standard than it is to
> > add a feature.  However it is the general rule that
> > Standards should follow existing practice. I think it is too
> > soon to remove export from the Standard but if it is still
> > not widely available when C++1X is being worked on, I think
> > that it will be time then to remove it.

> Couldn't the "export" feature be classified as "conditionally
> supported" (a term already used in the standard for some other
> features)? It wouldn't have to removed from the standard but
> implementations not providing it could still be standard
> compliant as long as they document the fact that they don't
> support "export".

In practice, that's more or less what happens.  Except they
don't document the fact that they're lying: compilers which
don't implement export do claim compliance.

 From the user point of view, the issue is simple: what are your
choices.  Basically, you don't have export, so you do without.
That means banning templates at the application level, but
typically, you don't miss something you've never had.

--
James Kanze


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andrei Alexandrescu wrote:
> Francis Glassborow wrote:
> [snip]
>>
>> Now it is perfectly true that it is (desirably) much harder to remove
>> something from an existing standard than it is to add a feature.
>> However it is the general rule that Standards should follow existing
>> practice. I think it is too soon to remove export from the Standard
>> but if it is still not widely available when C++1X is being worked on,
>> I think that it will be time then to remove it.
>
> Never mind that it's 1X already, but your conclusion came as a
> surprise after all of your arguments. I mean, reading your post goes
> like this: "Nobody will implement it... check. No demand... check.
> Portability issues... check. Implementors not looking into it...
> check. Alright, I'm convinced. Where do I sign the petition to give
> export the electric chair? Oh, wait, there are two more paragraphs.
> Keep it on the death row for 15 more years.... whaaaaa?"
>
>> I actually think it was a mistake putting it in in the first place but
>> that is an entirely different issue. It is there now and it should be
>> allowed a fair crack of the whip before being removed.
>
> That whip don't crack, Francis.


Ah, but this is not a technical problem but a political one so do not
waste effort trying to get it removed more quickly :)

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Francis Glassborow wrote:
> Timothy Madden wrote:
>>
>> Steve Clamage wrote:
>> [...]
>>>
>>> The paper was discussed at the April 2003 meeting. The minutes
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1459.html
>>> do not contain a record of the discussion. My recollection is that
>>> some people were not moved by the arguments against export; others
>>
>> [...]
>>
>> Exactly! Some people are not moved by the arguments against export.
>>
>>
>> This arguments are:
>>
>> 1. That it is difficult to implement.
>>    It is and it should be, export is a big change. Even so, the
>>    idea is if a small group at EDG could implement it, than a
>>    company can also implement it.
>
> True but as it requires fundamental alterations to some compilation
> techniques it could well mean suspending all other development
> whilst it is done.  I would hazard a guess that on some compilers
> that might mean suspending all new work (for C++0X) for 18 months
> (and throwing more resources at doing it would not significantly
> shorten development time. I have been told by one implementer that
> adding export would, for them, effectively mean a complete rewrite
> of their implementation from the ground up. I do not know how true
> that is, maybe they just do not want to do it.
>

Consider that just after the first standard was issued, one compiler
had a 4 year gap in its release cycle, used to add "managed
extensions" to the language. This was definitely not by "customer
demand", as hardly anyone use it.

This could very well have been spent on export and other Standard C++
features, using less resources. Makes the "cannot afford it" argument
a bit weak!

For some reason, it seems that they just don't want to.


Bo Persson



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Andrei Alexandrescu wrote:
>
> Never mind that it's 1X already,

For some unspecified value of "it". Yes, this year is 1x. No, the next
release of the C++ standard is not 1x. It's C++0x.

--
    Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 20, 5:56 pm, Timothy Madden <terminato...@gmail.com> wrote:
> What is the current status for the export keyword for the future version
> of the standard ?
Pointless, as ever.

> Can you please keep it as-is in the language ?
Keeping pointless features does not seem very useful.

> I know implementers do not like it, but they should, and templates are
> such an important part in C++. They should have complete language support.
Why should implementers like it?  It is hard to implement for no
apparent gain. Templates are indeed an important part of C++, but
templates do not need export, so that fails to constitute any kind of
an argument in favour.

> Why is an intermediate step in a build system, to allow for template
> instantiation before linking, such a big deal ?
Because it's a big change to an old system that yields little to no
benefit.

> If people do not like the linker invoking compiler functionality, just
> make instantiation an independent step performed by a compiler-like tool
> that receives all "uninstantiated" object files in the program, much
> like a linker receives all plain object files, but that otherwise has
> nothing to do with the linker itself.
What does the additional complexity win you?

export doesn't:
* allow meaningful separate compilation of templates (one still
couldn't ship a header of prototypes and a binary blob for template
code)
* improve compile times (and can actually do the reverse)
* have any great demand (development resources are finite and features
must be prioritized; given the choice between, say, implementing C++0x
lambdas and export, no-one is going to pick export. It is hard to
imagine which features would be prioritized below export)

export does:
* break the meaning of anonymous namespaces (they can now leak outside
their translation unit)
* break the meaning of static in some contexts (same reason)

Why is it worth retaining? Never mind whether it should take long to
implement or not--evidence says it takes a long time, but that is
somewhat beside the point--why is it even worth having? What problem
is it solving? And is it even worth solving? Given that C++
programmers have lived without it for more than a decade, and further,
given that they are not clamouring for its implementation (there are
things they want, but export isn't one of them), it does not appear to
be a significant problem, if it even exists.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Pete Becker wrote:
> Andrei Alexandrescu wrote:
>>
>> Never mind that it's 1X already,
>
> For some unspecified value of "it". Yes, this year is 1x. No, the next
> release of the C++ standard is not 1x. It's C++0x.

I know. And that's (literally) for backward compatibility reasons :o).

Andrei

[ Moderator's note: See also the thread "C++0x --> hex number?" ]
[ that started 09 December 2009.                                ]


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 28 Jan, 11:03, Francis Glassborow
<francis.glassbo...@btinternet.com> wrote:
> Timothy Madden wrote:

      [...]
> > 1. That it is difficult to implement.
> >    It is and it should be, export is a big change. Even so, the idea is
> >    if a small group at EDG could implement it, than a company can also
> >    implement it.

> True but as it requires fundamental alterations to some compilation
> techniques it could well mean suspending all other development whilst
> it is done.  I would hazard a guess that on some compilers that might
> mean suspending all new work (for C++0X) for 18 months (and throwing
> more resources at doing it would not significantly shorten development
> time. I have been told by one implementer that adding export would,
> for them, effectively mean a complete rewrite of their implementation
> from the ground up. I do not know how true that is, maybe they just do
> not want to do it.

I know of a couple of C++ compilers which would seriously
benefit from a complete rewrite, from the ground up:-).  Maybe
that's an argument for keeping it.

> > 2. That it is difficultto use correctly, it is
> >    underspecified, it is not well understood.  Sorry to say
> >    to say that it is /easy/ to use and it just works.
> >    Special cases that show up are not that important and
> >    work anyway.

> It is impossible to use unless your implementation provides
> it. Any code shop that has a basic requirement for code to
> compile successfully with two independent implementations
> cannot use export.  Many heavy duty users have such a
> requirement.

True.  Many heavy duty users also have banned templates except
for the low level, most stable things, because they can't get
export.  (Heavy duty users tend to be conservative, and
independantly of export, at least until recently, templates were
a portability nightmare.)

> > 3. Lack of demand.  That is actually difficult to asses as
> >    long as it is yet hardly implemented. Once compilers will
> >    have export, anyone doubts that language users will all
> >    immediately adopted it and get rid of the huge headers
> >    they now use ?  Even now I can see on MSDN blogs people
> >    saying they had to drop a certain compiler because their
> >    clients were using export.

> Yes, and I can also see the other side of people dropping
> compilers because they do not implement some other feature
> that they want (e.g.  move semantics)

Any demand for move semantics is recent, because in industry,
most people have never heard of them.  Nor need them.  Of
course, most people in industry have not heard of export,
either.  All they know is that templates, as implemented by
their compiler, don't work, and that you're better off avoiding
them.  (Again, the lack of export isn't the only issue.  DLL's
and templates don't mix very well either, and I don't think
export would solve that.)

--
James Kanze

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 29, 1:08 am, "Bo Persson" <b...@gmb.dk> wrote:
[...]
>
> Consider that just after the first standard was issued, one compiler
> had a 4 year gap in its release cycle, used to add "managed
> extensions" to the language. This was definitely not by "customer
> demand", as hardly anyone use it.
>
> This could very well have been spent on export and other Standard C++
> features, using less resources. Makes the "cannot afford it" argument
> a bit weak!
>
> For some reason, it seems that they just don't want to.

Maybe someone told them that it might be close-to-impossible to do. :)

Exactly what is the difference between instantiating an exported
template and an in-place one ?

I mean other than exported templates have their parse tree and symbols
table loaded from disc, while in-place ones already have them.

Thank you,
Timothy Madden


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 30, 12:15 am, Peter Bright <drpi...@gmail.com> wrote:
> On Jan 20, 5:56 pm, Timothy Madden <terminato...@gmail.com>
> wrote:
> > What is the current status for the export keyword for the
> > future version of the standard ?

> Pointless, as ever.

Only because vendors don't implement it.

> > Can you please keep it as-is in the language ?

> Keeping pointless features does not seem very useful.

> > I know implementers do not like it, but they should, and
> > templates are such an important part in C++. They should
> > have complete language support.

> Why should implementers like it?  It is hard to implement for
> no apparent gain.

It's rumored hard to implement.  Still, EDG implemented it,
with, from what I understand, one man year of effort.  And the
first implementation is always the hardest, so it would require
even less effort from other implementors.

> Templates are indeed an important part of C++, but templates
> do not need export, so that fails to constitute any kind of an
> argument in favour.

Well, you can't really use templates much at the application
level without export (or something similar).

> > Why is an intermediate step in a build system, to allow for
> > template instantiation before linking, such a big deal ?

> Because it's a big change to an old system that yields little
> to no benefit.

The differences in semantics make the resulting code far more
robust.  (This was the major motivation for it.)

> > If people do not like the linker invoking compiler
> > functionality, just make instantiation an independent step
> > performed by a compiler-like tool that receives all
> > "uninstantiated" object files in the program, much like a
> > linker receives all plain object files, but that otherwise
> > has nothing to do with the linker itself.

> What does the additional complexity win you?

> export doesn't:
> * allow meaningful separate compilation of templates (one still
> couldn't ship a header of prototypes and a binary blob for template
> code)

You can with the one existing implemenation.

> * improve compile times (and can actually do the reverse)

It does with the existing implementation.

> * have any great demand (development resources are finite and
> features must be prioritized; given the choice between, say,
> implementing C++0x lambdas and export, no-one is going to pick
> export. It is hard to imagine which features would be
> prioritized below export)

That depends on what you're doing in C++.  Most places simply
ban templates at the application level, so it doesn't matter.
With export, they might be willing to remove this ban.

> export does:
> * break the meaning of anonymous namespaces (they can now leak outside
> their translation unit)

You've got that backwards.  At present, you can't use anonymous
namespaces with templates, because you'll immediately fall into
undefined behavior.  With export, you can.

> * break the meaning of static in some contexts (same reason)

As above: you can't use non member statics in a template,
for the same reasons that you can't use anonymous namespaces.

> Why is it worth retaining? Never mind whether it should take
> long to implement or not--evidence says it takes a long time,

The evidence says that it should take at most one man-year to
implement.  That's not a long time at all.

> but that is somewhat beside the point--why is it even worth
> having?

Because it allows separate compilation of templates, making them
significantly more robust, and reducing coupling.

> What problem is it solving?

The fact that templates without it (or something similar) are
more or less unusable at the application level in large
projects.

> And is it even worth solving?

Only if you think that templates are useful at the application
level in large projects, or projects where reliability is
important.

> Given that C++ programmers have lived without it for more than
> a decade, and further, given that they are not clamouring for
> its implementation (there are things they want, but export
> isn't one of them), it does not appear to be a significant
> problem, if it even exists.

Given the C programmers have lived without classes for God knows
how many decades, and are not clamouring for them...  Given that
C++ programmers lived without templates for a long time, and in
many cases, still live with only restricted use of templates...

--
James Kanze

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Timothy Madden wrote:
> Steve Clamage wrote:
>> On 01/22/10 10:14, Timothy Madden wrote:
> [...]
>>>> I think this sums up the issue pretty
>>>> well:http://www.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1426.pdf
>>
>>>
>>> I have seen the paper. It is subjective and biased against export.
>>
>> The paper presents facts, and quotes from the team that implemented
>> export. The team members all said it was not worth the effort (they
>> did it only so they could claim complete conformance to the standard),
>> and their advice to other implementers was not to implement the
>> feature.
>>
>> As to whether the paper is biased, it presents the authors' point of
>> view, as do all papers on any topic. Perhaps you could point out
>> examples of actual bias. For example, do the authors omit some
>> arguments in favor of the export feature, or unfairly criticize
>> arguments they do show? (Even then you can't assume bias. I have known
>> the authors personally for many years, and I seldom have met more
>> fair-minded people.)
>>
>
> That paper was discussed long time ago and people were against it.
>
> The team implementing export, quoted there as proof that export is
> wrong, did not support the paper, and Daveed Vandevoorde in that team in
> fact supported export in any serious discussion about the feature, and
> said EDG was against it when the feature was first introduced.
> EDG was actually willing to support with advice based on their
> experience anyone wanting to implement export.
>
> It should also say the reason for export is to provide declarations-only
> for templates, with the effect of using external templates much like
> external functions or external symbols in non-template code. The
> benefits are clean and organized template code for the end-users.
>
> The paper will tell that export only hides dependencies, that it is
> misunderstood, that it produces confusion, but in fact the export
> keyword does exactly what it is supposed to do. It is only doing the job
> in a different perspective, since we are now in template code.

I am well aware of the shiny city on the hill image of exported
templates. It is in stark contrast with the slums one enters when
getting closer.

> Supporting disagreement with the standard on a newly-introduced language
> feature, that paper has done more harm then any good. :(

On the contrary, in wake of the recent information posted by sdt, I'm
glad that the paper has slowly turned the tide around. export should be
eliminated, and the paper might have had a contribution in spite of its
own mistakes and shortcomings.

>>> They say it could take 2 up to 3 man-years for a company to implement.
>>> Well for a company this means less than one year, with more than one
>>> programmer, which is reasonable.
>>
>> Don't fall into the trap of Brooks's Law. Putting 9 women on the job
>> won't get you a baby in one month. :-)
>>
>> You gloss over the cost by saying it is reasonable. By what standard?
>
> Reasonable as in "it fits in a release cycle" with but a few programmers.

On what basis are you making that claim?

>> I'd like to see a case study that shows how the export feature has
>> proved important to the development of an application. For example,
>> how development time was reduced, or made easier, or made the
>> application more robust or more maintainable. I don't know of any such
>> papers.
>
> What proves important for the development of an application are also
> design, understanding the requirements and making the right choices and
> estimates for resources. Export is but a language feature. Any C++
> application in the world can be written with or without export, just as
> any C++ application can be written in plain C.
>
> Thinking of the separation between declaration and definition that it
> introduces, export does make programs more robust and maintainable.

This feel-good stuff is too general to be useful. We could go on with
projectmanagerspeak and enumerate more reasonable approaches and
desirable outcomes. That doesn't get things done, and does little to
reveal fundamental issues that blunt attacks to the problem.


Andrei

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 30, 2:15 am, Peter Bright <drpi...@gmail.com> wrote:
> On Jan 20, 5:56 pm, Timothy Madden <terminato...@gmail.com> wrote:> What
is the current status for the export keyword for the future version
> > of the standard ?
>
> Pointless, as ever.
>
> > Can you please keep it as-is in the language ?
>
> Keeping pointless features does not seem very useful.

The point of export is to reduce the coupling that is now required
with template code.

[...]
> What problem
> is it solving?

What problem are prototypes for external functions solving ? Why are
functions not all inlined ?

> Given that C++
> programmers have lived without it for more than a decade
[...]

Given that you can live without C++ at all ... (or without a computer,
for that matter)


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Kanze wrote:
> That depends on what you're doing in C++.  Most places simply
> ban templates at the application level, so it doesn't matter.

One of Bjarne's most insightful observations is that nobody knows what *most*
C++ programmers/places are doing.  My experience is that use of templates in
industry for application development varies from little to extensive,
and that's
for systems up to several millions lines of code.  (One company I worked with
told me that MS had told them that they had the largest code base compiled with
MSVC outside of MS.)  Whether my experience is representative of "most
places" I
don't know, but I do know that use of templates in industrial applications is
common.  Whether it crosses the 50% threshhold is, IMO, unimportant.

Scott

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu <std-c%2B%2B@netlab.cs.rpi.edu>]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 30, 6:03 pm, Andrei Alexandrescu
[...]
> On the contrary, in wake of the recent information posted by sdt, I'm
> glad that the paper has slowly turned the tide around. export should be
> eliminated [...]
[...]

On what basis are you making that claim ?
The so-controversial paper ?

What if it does get implemented by other compilers ?


>
> >>> They say it could take 2 up to 3 man-years for a company
to implement.
> >>> Well for a company this means less than one year, with more than one
> >>> programmer, which is reasonable.
>
> >> Don't fall into the trap of Brooks's Law. Putting 9 women on the job
> >> won't get you a baby in one month. :-)
>
> >> You gloss over the cost by saying it is reasonable. By what standard?
>
> > Reasonable as in "it fits in a release cycle" with but a few programmers.
>
> On what basis are you making that claim?


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Timothy Madden" <terminatorul@gmail.com>
>> On the contrary, in wake of the recent information posted by sdt, I'm
>> glad that the paper has slowly turned the tide around. export should be
>> eliminated [...]
> On what basis are you making that claim ?
> The so-controversial paper ?
>
> What if it does get implemented by other compilers ?

#include "Lennon/imagine.flac"

I try to look at the real world. If someone says me "i call back" and it
does not happen in days, I accept it will not happen. If there's a promise
to do a thing shortly and no sign in a month, it will not happen. Just will
not.

Export is in the standard since '98. In 12 years it was not implemented in
the compilers that were around the whole time. And not even a promise is
made.

I would be extremely glad to use export, but it is just not there, and
nothing implies it will ever be. Keeping it in the standard certainly is not
a thing that will make it appear.

And the paper is right in the claim it creates a schism in the language, and
I'd rather see a perfect 100% match of compilers and the standard. The only
pragmatic way to do it now is to change the standard to reflect the general
practice.  (Btw that *is* generally an aim of a standard too.)


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu <std-c%2B%2B@netlab.cs.rpi.edu>]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Feb 8, 12:52 am, Edward Diener
<eldiener_no_spam_h...@tropicsoft.com> wrote:
> Steve Clamage wrote:

      [...]
> > But export does not in fact give that comparable
> > functionality. The standard does not promise it, and the
> > only known implementation of export (EDG) does not provide
> > it.

> > You can declare a specific template instance and use it, as
> > long as a compiled version is available at link time, but
> > this functionality is exactly equivalent to an ordinary
> > function declaration, and does not require exported
> > templates.

> > In my export example, the source code for template foo must
> > be present when compiling the example. The export feature
> > does not actually provide any help in this case.

> Your summation of 'export' is excellent.

> My argument, which may be that of others, is that 'export'
> should have been given teeth so that the template source code
> did not need to be available in source code form.

Except that the standard doesn't require that of non-template
functions, either.  It's a quality of implementation issue.
(It's been literally ages since I used export with Comeau, so I
don't really recall the details, but I seem to recall that
instantiation didn't necessarily occur before link time.  But I
can't be sure, because in the case that interested me, the
source was available---in that one particular case, I was mainly
motivated by the significantly lower compile times which export
provided.)

> How a compiler would do this is of course a big issue,

It's interesting to note that other languages have solved the
problem.  (Of course, their templates or generics aren't
necessarily the same as those in C++.)

> but I think that the C++ standard could have specified that
> the source code for the template be 'compiled' into some form,
> whether obfuscated or not, and automatically used when the
> template declarations needed to be checked during phase 2
> checking without the end-user doing anything further ( such as
> including the source code file also ).

> > What about separating declarations and definitions?  You
> > don't need export for that either, with many compilers. Even
> > the first C++ compiler, Cfront from Bell Labs, allowed
> > separation of template declarations and definitions.

> > Example:

> > foo.h  // header file
> > ------
> >  template<class T> T foo(T);

> > foo.cpp  // implementation file
> > -------
> >  template<class T> T foo(T t) { ... }

> > Then you can write
> >  #include <foo.h>
> >  class myclass { ... }
> >  myclass M = foo( myclass() );

> > When a template declaration is seen in a file foo.h, the
> > compiler automatically includes foo.cpp when the definition
> > is needed.

> No compiler of which I know does that, and if it is not
> specified by the C++ standard it is very hard for the end-user
> to rely on such functionality.

To date, only two compilers I've used don't support this
"implicit inclusion" model: VC++ and g++.  Sun CC certainly did,
and I think still does.  And even VC++ and g++ will allow
compiling template instantatiions without the implementation
being present; all they require is that at least one translation
unit which uses the instantiation have been compiled with the
implementation present.

> So your claiming that this currently "works" does not convince
> me that it actaully does anywhere that I know about.

> Nonetheless this is analogous to what I suggested above, but
> with foo.cpp being "compiled" separately to some intermediate
> form just as one compiles any source file.

No.  Steve specifically mentionned CFront.  The way CFront
worked was to generate a pseudo-C++ source file for the
instantiation in a repository, with (hopefully) all of the
necessary includes, and then invoke the compiler on this source
file when it encountered an unresolved external whose mangled
name looked like a template instantiation.  (That is, of course,
a radical simplification.)  The source for the template
implementation was still required to be present at link time.

> The difference is that if the C++ standard committee would
> have specified how 'export' must work, then 'export' could
> have effectively been used to separate template declarations
> from their definitions, and perhaps to also hide the template
> definitions themselves in the same way that programmers are
> allowed to hide source code implementations when shipping a
> product.

There are two issues.  Logically, one does expect the source to
be separate---one of the big embarassements of C++ is that
unlike normal functions, you have to put the source in the
header, and include it at compile time.  The goal of export goes
further, however; the template "source" should be compiled
without reference to the environment in which you include the
file (e.g. any previously defined macros).  Except, of course,
where dependent names are involved.  And that's rather
difficult.  But then, so is correctly implementing two phase
look-up to begin with.  (I should add that most of what I know
about these issues, I owe to a long and fruitful email exchange
with John Spicer, many years ago.  Without his patience, I don't
know if I'd understand the issues even today.)

> > You don't need export for this separation of declaration and
> > definition. If your favorite compiler doesn't have this
> > feature, you could ask for it. The feature is not hard to
> > implement.

> I could ask for anything but that does not mean I will get it.

Yep.  That's a real problem.  The C++ committee asked for
export, and they didn't get it.  And they probably have a lot
more weight that you or I.

> But you are totally right that even without 'export' it is
> completely possible to separate template declarations and
> template definitions into separate files and use them.

That's called the implicit inclusion model.

> > As far as I can tell, and at least one of the EDG compiler
> > writers who worked on export agrees with me, export as
> > defined has no useful functionality.

All I can say is that in the one case where I used it, it
significantly improved my build times.  More generally, my
discussions with people from EDG did suggest useful
functionality.  (But they were a long time ago, and the opinions
of those people could have changed since then.)

      [...]
> Of course if one wanted to eliminate 'export' entirely but add
> new rules in the standard which specified that the inclusion
> of template declarations automatically forces the compiler to
> find and include the template definitions, if they exist, in a
> similarly named file, with the .cpp extension substituting for
> the template declaration extension, that would at least be of
> some help.

One of the people from EDG has proposed a complete module
system.  Which solves the problems export was designed to solve,
plus a lot more.  If that's adopted, then I'd agree that we
don't need export, but until then... it's far from perfect, but
it's all we (don't) have.

--
James Kanze

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

What is the current status for the export keyword for the future version
of the standard ?

Can you please keep it as-is in the language ?

I know implementers do not like it, but they should, and templates are
such an important part in C++. They should have complete language support.

Why is an intermediate step in a build system, to allow for template
instantiation before linking, such a big deal ?

If people do not like the linker invoking compiler functionality, just
make instantiation an independent step performed by a compiler-like tool
that receives all "uninstantiated" object files in the program, much
like a linker receives all plain object files, but that otherwise has
nothing to do with the linker itself.


Thank you,
Timothy Madden

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 20 jan, 17:56, Timothy Madden <terminato...@gmail.com> wrote:

> Why is an intermediate step in a build system, to allow for template
> instantiation before linking, such a big deal ?

Because that breaks the usual frontend design.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 20, 6:56 pm, Timothy Madden <terminato...@gmail.com> wrote:
> What is the current status for the export keyword for the future version
> of the standard ?
>
> Can you please keep it as-is in the language ?
>
> I know implementers do not like it, but they should, and templates are
> such an important part in C++. They should have complete language support.

I think this sums up the issue pretty well:
http://www.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1426.pdf

I've also been thinking about the effort necessary to implement export
in Clang. I believe that Clang's design is very well suited to
implementing export - and yet I estimate that it would consume a huge
amount of time. I believe that GCC, for example, would have a far
harder time implementing it; from what little I know of GCC internals,
it is really, really unsuited to support the feature.

Sebastian


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 20, 11:56 am, Timothy Madden <terminato...@gmail.com> wrote:
> What is the current status for the export keyword for the future version
> of the standard ?
>
> Can you please keep it as-is in the language ?
>
> I know implementers do not like it, but they should, and templates are
> such an important part in C++. They should have complete language support.
>
> Why is an intermediate step in a build system, to allow for template
> instantiation before linking, such a big deal ?

Read this thread:
http://groups.google.com/group/comp.lang.c++.moderated/msg/26f44cf244d2789c


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 21, 11:49 pm, CornedBee <wasti.r...@gmx.net> wrote:
> On Jan 20, 6:56 pm, Timothy Madden <terminato...@gmail.com> wrote:
>
> > What is the current status for the export keyword for the future version
> > of the standard ?
>
> > Can you please keep it as-is in the language ?
>
> > I know implementers do not like it, but they should, and templates are
> > such an important part in C++. They should have complete language support.
>
> I think this sums up the issue pretty well:http://www.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1426.pdf
>
> I've also been thinking about the effort necessary to implement export
> in Clang. I believe that Clang's design is very well suited to
> implementing export - and yet I estimate that it would consume a huge
> amount of time. I believe that GCC, for example, would have a far
> harder time implementing it; from what little I know of GCC internals,
> it is really, really unsuited to support the feature.
>
> Sebastian

I have seen the paper. It is subjective and biased against export.

Nobody said it is simple to do. Clearly export affects the build
process and clearly it requires some changes in the compiler's
internal proessing in order to now support instantiation. That's a
given and has been for many years since export was adopted.

Yes it does not offer source hiding. That is not a language issue
actually and a new keyword will not promise you that (even so it might
open a possibility: as the standard says, an implementation /could/
encode enough information in the translated translation unit that the
source would not be required at instantiation time ...).

Yes it does not necessarily speed up instantiation time: automated by
export or not, the instantiation still takes place, and is dependent
on the context at the point of instantiation.

The reason for export is just to separate the instantiation (use) from
the definition. I can use the template anywhere I want in my code with
only a prototype. I do not need the definition, I do not need to know
even where the definition would be. The compiler will be the one to
care to locate it at some point before linking. Of course I still need
to know that the definition will be there among the object files
somewhere, but that is obvious. It offers me a little freedom: I can
use the templates without carrying the definition with me all the
time.

Export allows me to use the explicit instantiation model for my
templates, but without the responsibility to explicitly instantiate
them upon reading the linker's output with the needed instantiations.
With export, instantiation is just automatic, and for exactly the
needed types that I would otherwise instantiate manually.

They say it could take 2 up to 3 man-years for a company to implement.
Well for a company this means less than one year, with more than one
programmer, which is reasonable. How often are compilers released per
year ? Besides it will be easier to implement now that EDG has already
implemented it and templates are anyway wide-spread ...

Export is a feature, meant to better support templates, which are a
part of C++ that made the language be what it now is.

Export keyword has been through controversial discussions before, and
it was kept and standardised. It is there. It is plain standard C++ as
of now. Just let things be as they are ...
Many other features have been controversial; still they are not
getting out of the standard ...

Thank you,
Timothy Madden


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 21, 11:47 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
> On 20 jan, 17:56, Timothy Madden <terminato...@gmail.com> wrote:
>
> > Why is an intermediate step in a build system, to allow for template
> > instantiation before linking, such a big deal ?
>
> Because that breaks the usual frontend design.

What usual design ? Exactly how will it break it ?

There is already an implementation, that does template instantiation,
even if not clearly as a separate step in the build process.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 21 jan, 21:49, CornedBee <wasti.r...@gmx.net> wrote:

> I've also been thinking about the effort necessary to implement export
> in Clang. I believe that Clang's design is very well suited to
> implementing export - and yet I estimate that it would consume a huge
> amount of time. I believe that GCC, for example, would have a far
> harder time implementing it; from what little I know of GCC internals,
> it is really, really unsuited to support the feature.

With all compilers getting link-time optimization, I would initially
think everything is already here.
But I suspect the problem is that the internal representations
compilers use don't support generative programming. Is that it?

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Dilip <rdilipk@lycos.com> writes:
> Read this thread:
> http://groups.google.com/group/comp.lang.c++.moderated/msg/26f44cf244d2789c

Of course in the end it turns into yet another of Walter's incessant
attempts to flog D... :P

-Miles

--
Marriage, n. The state or condition of a community consisting of a master, a
mistress and two slaves, making in all, two.

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jan 22, 8:14 pm, Mathias Gaunard <loufo...@gmail.com> wrote:
> On 21 jan, 21:49, CornedBee <wasti.r...@gmx.net> wrote:
>
> > I've also been thinking about the effort necessary to implement export
[...]
> With all compilers getting link-time optimization, I would initially
> think everything is already here.
> But I suspect the problem is that the internal representations
> compilers use don't support generative programming. Is that it?

A separate step in the build process for template instantiation, when
the compiler (or compiler-tool) would get and see all the object files
in the program, would also help with these so-called "link-time"
optimisations.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 01/22/10 10:14, Timothy Madden wrote:
>
> On Jan 21, 11:49 pm, CornedBee <wasti.r...@gmx.net> wrote:
>>
>> On Jan 20, 6:56 pm, Timothy Madden <terminato...@gmail.com> wrote:
>>
>>> What is the current status for the export keyword for the future version
>>> of the standard ?
>>> Can you please keep it as-is in the language ?
>>> I know implementers do not like it, but they should, and templates are
>>> such an important part in C++. They should have complete language support.
>>
>> I think this sums up the issue pretty well:http://www.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1426.pdf

>
> I have seen the paper. It is subjective and biased against export.

The paper presents facts, and quotes from the team that implemented
export. The team members all said it was not worth the effort (they
did it only so they could claim complete conformance to the standard),
and their advice to other implementers was not to implement the
feature.

As to whether the paper is biased, it presents the authors' point of
view, as do all papers on any topic. Perhaps you could point out
examples of actual bias. For example, do the authors omit some
arguments in favor of the export feature, or unfairly criticize
arguments they do show? (Even then you can't assume bias. I have known
the authors personally for many years, and I seldom have met more
fair-minded people.)

> ...
>
> They say it could take 2 up to 3 man-years for a company to implement.
> Well for a company this means less than one year, with more than one
> programmer, which is reasonable.

Don't fall into the trap of Brooks's Law. Putting 9 women on the job
won't get you a baby in one month. :-)

You gloss over the cost by saying it is reasonable. By what standard?
For example, all teams have limited resources. The 3 man-years spent
on export represent 3 man-years not spent on anything else. Other
features don't get implemented, some bugs don't get fixed, support for
the C++0X standard is delayed.

So when you assert that the cost to implement export is reasonable,
you also assert that these other factors are less important, or that
the compiler vendor has no resource constraints.

I'd like to see a case study that shows how the export feature has
proved important to the development of an application. For example,
how development time was reduced, or made easier, or made the
application more robust or more maintainable. I don't know of any such
papers.

>
> Export keyword has been through controversial discussions before, and
> it was kept and standardised. It is there. It is plain standard C++ as
> of now. Just let things be as they are ...
> Many other features have been controversial; still they are not
> getting out of the standard ...

The paper referenced above recommended (in 2003) that export be
removed from the language. The committee voted to keep export. I do
not believe the issue will be raised again.

---
Steve Clamage

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Steve Clamage wrote:
> The paper referenced above recommended (in 2003) that export be
> removed from the language. The committee voted to keep export. I do
> not believe the issue will be raised again.

I seem to vaguely recall the arguments for keeping export back after
Herb's paper, are there some minutes available online, or could you
summarize them?

Now that a positive precedent has been created by the demise of
concepts, maybe the issue of eliminating export would be met quite
favorably nowadays.


Andrei

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Sat, 23 Jan 2010 03:11:11, Steve Clamage wrote:
> On 01/22/10 10:14, Timothy Madden wrote:
> >
> > On Jan 21, 11:49 pm, CornedBee <wasti.r...@gmx.net>  wrote:
> > >
> > > On Jan 20, 6:56 pm, Timothy Madden <terminato...@gmail.com>  wrote:
> > >
> > > > What is the current status for the export keyword for the future version
> > > > of the standard ?
> > > > Can you please keep it as-is in the language ?
> > > > I know implementers do not like it, but they should, and templates are
> > > > such an important part in C++. They should have complete language support.
> > >
> > > I think this sums up the issue pretty well:http://www.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1426.pdf
> >
> > I have seen the paper. It is subjective and biased against export.
>
> The paper presents facts, and quotes from the team that implemented
> export. The team members all said it was not worth the effort (they
> did it only so they could claim complete conformance to the standard),
> and their advice to other implementers was not to implement the
> feature.

At least one of those implementers expressed disagreement with the
conclusions of that paper.  Specifically, on 8 Sep 2004 04:19:30 -0400,
in article news:52f2f9cd.0409071910.338bd2e7@posting.google.com,
Daveed Vandevoorde wrote:

> "David B. Held" <dh...@codelogicconsulting.com> wrote:
> > Daveed Vandevoorde wrote:
> > > [...]
> > > 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."
> >
> > What are your comments on N1426, given that you and the rest of EDG are
> > thoroughly quoted as being against export?
>
> (Sorry for the delay in answering.  I have been busy lately.)
>
> I'm not particularly happy about that paper.  It makes it look
> like EDG supports its points of view, when in fact that isn't
> the case.  (I agree neither with the technical aspects nor with
> the nontechnical arguments of the paper.)

The full text of the article is available here:

http://groups.google.com/group/comp.lang.c++.moderated/msg/0e0b908031fb927f

C. M. Heard

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mon, 25 Jan 2010 11:42:36 CST, Andrei Alexandrescu
<SeeWebsiteForEmail@erdani.org> wrote:

>Steve Clamage wrote:
>> The paper referenced above recommended (in 2003) that export be
>> removed from the language. The committee voted to keep export. I do
>> not believe the issue will be raised again.
>
>I seem to vaguely recall the arguments for keeping export back after
>Herb's paper, are there some minutes available online, or could you
>summarize them?

The paper was discussed at the April 2003 meeting. The minutes
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1459.html
do not contain a record of the discussion. My recollection is that
some people were not moved by the arguments against export; others
felt that removing a relatively new feature (5 years old at the time,
when C++ over 15 years old) was a bad precedent; still others felt
that removing the feature would be seen as unfair to EDG, who had done
the hard work of implementing the feature. In the end, there was
little support for removing the feature, and less support for
discussing the issue any more.

>Now that a positive precedent has been created by the demise of
>concepts, maybe the issue of eliminating export would be met quite
>favorably nowadays.

The situations are not comparable. Export has been in the C++ standard
since the beginning (final draft in 1997, published in 1998). Concepts
were first proposed several years ago, but no agreement was ever
reached on their final form, and they never appeared in an actual
standard. They were removed from the draft because the committee felt
that a final version was still 2 to 3 years away.

---
Steve Clamage

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Feb 1, 5:38 pm, "Balog Pal" <p...@lib.hu> wrote:
> "Timothy Madden" <terminato...@gmail.com>

      [...]
> Export is in the standard since '98. In 12 years it was not
> implemented in the compilers that were around the whole time.
> And not even a promise is made.

You raise a real issue.  Independently of templates.  Given what
happened with templates, what will it mean in practice if the
committee adopts garbage collection, or concepts, or lambda?
Will you ever really see them?

      [...]
> And the paper is right in the claim it creates a schism in the
> language, and I'd rather see a perfect 100% match of compilers
> and the standard. The only pragmatic way to do it now is to
> change the standard to reflect the general practice.  (Btw
> that *is* generally an aim of a standard too.)

It's a difficult balancing act.  Go too far in the direction
you're proposing, and you might as well let Microsoft write the
standard.

--
James Kanze

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Feb 1, 3:24 am, Scott Meyers <NeverR...@aristeia.com> wrote:
> James Kanze wrote:
> > That depends on what you're doing in C++.  Most places
> > simply ban templates at the application level, so it doesn't
> > matter.

> One of Bjarne's most insightful observations is that nobody
> knows what *most* C++ programmers/places are doing.

Yes.  I can really only talk about places where I've worked.
And while they've been fairly varied, until recently, robustness
and maintainability have been critical issues in all of them.

> My experience is that use of templates in industry for
> application development varies from little to extensive, and
> that's for systems up to several millions lines of code.  (One
> company I worked with told me that MS had told them that they
> had the largest code base compiled with MSVC outside of MS.)
> Whether my experience is representative of "most places" I
> don't know, but I do know that use of templates in industrial
> applications is common.  Whether it crosses the 50% threshhold
> is, IMO, unimportant.

The use of templates is, I think, almost universal today.  The
question is how they are being used---most places I've seen
restrict their use to relatively low-level, very stable code,
and don't allow them in the higher levels (the application
level).  (Most well run shops, of course, are also willing to
make exceptions when the advantages can be shown to justify the
cost.)

--
James Kanze

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Balog Pal wrote:
[...]
> I try to look at the real world. If someone says me "i call back" and it
> does not happen in days, I accept it will not happen. If there's a promise
> to do a thing shortly and no sign in a month, it will not happen. Just will
> not.
>
> Export is in the standard since '98. In 12 years it was not implemented in
> the compilers that were around the whole time. And not even a promise is
> made.

People have not been on the Moon since many more years, and they don't
look like they are trying. Would you look at the real world and just say
they are not going to land there again ?

> I would be extremely glad to use export, but it is just not there, and
> nothing implies it will ever be. Keeping it in the standard certainly is
> not
> a thing that will make it appear.

Removing it from the standard certainly is not a thing that will make it
appear. Remember that export /has/ been implemented. Comeau is not the
only vendor. Intel is still shipping an EDG-based compiler that can
understands export, and Borland also had some attempts with their
product at some time.

> And the paper is right in the claim it creates a schism in the language,
> and
> I'd rather see a perfect 100% match of compilers and the standard. The only
> pragmatic way to do it now is to change the standard to reflect the general
> practice.  (Btw that *is* generally an aim of a standard too.)

Going with the flow is not always the way to go.

If people would not care about environmental issues would you state the
issue should no longer be approached ?

If no kid in your class wants to learn mathematics because the thing is
getting so hard would you take it to mean that you too should no longer
try ?

Timothy Madden

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

This discussion is degenerating into repetition and wanderings into
off-topic areas. We comp.std.c++ moderators will be looking closely at
articles posted to this thread. In addition to the usual criteria for
postings (see the FAQ), we will accept only those that  add new,
on-topic,  material to the discussion. Others will be rejected.

Steve Clamage
speaking for the moderation team

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 01/31/10 19:27, Timothy Madden wrote:

> On Jan 30, 2:15 am, Peter Bright <drpi...@gmail.com> wrote:
>
....

> The point of export is to reduce the coupling that is now required
> with template code.
>
> [...]
>
>> What problem
>> is it solving?
>>
>
> What problem are prototypes for external functions solving ? Why are
> functions not all inlined ?
>

I'd like to put this point (and this feature comparison) to rest.

With a function declaration
   int foo(int);
I can proceed to call or take the address of foo without ever having access
to the source code, as long as a compiled version of the function is
available at link time.

To me, the equivalent functionality for export would be something like this:
   export template<class T> T foo(T);
   class myclass { ... };
   myclass M = foo( myclass() );
where the source code for template foo is not available.

But export does not in fact give that comparable functionality. The standard
does not promise it, and the only known implementation of export (EDG) does
not provide it.

You can declare a specific template instance and use it, as long as a
compiled version is available at link time, but this functionality is
exactly equivalent to an ordinary function declaration, and does not require
exported templates.

In my export example, the source code for template foo must be present when
compiling the example. The export feature does not actually provide any help
in this case.

What about separating declarations and definitions?  You don't need export
for that either, with many compilers. Even the first C++ compiler, Cfront
from Bell Labs, allowed separation of template declarations and definitions.

Example:

foo.h  // header file
------
   template<class T> T foo(T);

foo.cpp  // implementation file
-------
   template<class T> T foo(T t) { ... }

Then you can write
   #include <foo.h>
   class myclass { ... }
   myclass M = foo( myclass() );

When a template declaration is seen in a file foo.h, the compiler
automatically includes foo.cpp when the definition is needed. You don't need
export for this separation of declaration and definition. If your favorite
compiler doesn't have this feature, you could ask for it. The feature is not
hard to implement.

As far as I can tell, and at least one of the EDG compiler writers who
worked on export agrees with me, export as defined has no useful
functionality.

In an earlier posting in this thread, I said the C++ Committee voted to keep
export in 2004, and that the subject would not be raised again. Due either
to brain cells dying or insufficient caffeine, I had forgotten about the
discussion in the last meeting, October 2009, where no conclusion was
reached for C++0x about keeping, deprecating, or removing export. The issue
will be discussed again at the next meeting in March. If a decision is
reached, someone will post the result in this newsgroup.

In the mean time, if anyone has an example where export has proved useful,
and was better in some sense than alternatives, I'd like to see a posting
about it.

---
Steve Clamage

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Wed, 2010-02-03 at 15:16 -0600, Steve Clamage wrote:
> On 01/31/10 19:27, Timothy Madden wrote:
>
> > On Jan 30, 2:15 am, Peter Bright <drpi...@gmail.com> wrote:
> >
> ....
>
> > The point of export is to reduce the coupling that is now required
> > with template code.
> >
> > [...]
> >
> >> What problem
> >> is it solving?
> >>
> >
> > What problem are prototypes for external functions solving ? Why are
> > functions not all inlined ?
> >
>
> I'd like to put this point (and this feature comparison) to rest.
>
> With a function declaration
>    int foo(int);
> I can proceed to call or take the address of foo without ever having access
> to the source code, as long as a compiled version of the function is
> available at link time.
>
> To me, the equivalent functionality for export would be something like this:
>    export template<class T> T foo(T);
>    class myclass { ... };
>    myclass M = foo( myclass() );
> where the source code for template foo is not available.
>
> But export does not in fact give that comparable functionality.

Yes it does. You /can/ proceed to call or take address of template
function foo<myclass>(), without access to the source code as long as a
compiled template definition is available at instantiation time. Just
like with the function int foo(int).

As the standard says, an implementation /can/ encode enough information
in the compiled template definition so that the source is no longer
needed for instantiation. So all you need is such an implementation.

This is not implemented yet, but this is what the standard here is for:
to recommend things as suitable for being implemented.

When compilers will have export, they will also learn how to do without
requiring all those source files hanging around object files, because
undoubtedly this is the interesting (if not the intended) case.

Even if export does not promise the source code is not required, it
allows for it, or makes room for it, which is enough for what people
want. The relaxed attitude of maybe-need-the-source-code is there for
flexibility and for making things easier to adapt to; it is actually a
good attitude, as the standard would not say how the implementation
should go. Would you find it more useful if export would state the
source code is not required ?

People may think that even if compiled template definitions no longer
require source code, they still include a close model of the original
template source, needed for instantiation, so why not have the user
directly include that source, at the language level ?

But this is like saying a compiled program is just a different
representation of the same program previously expressed in C++, and so
why are C++ programs ever compiled and not interpreted ?


> What about separating declarations and definitions?  You don't need export
> for that either, with many compilers. Even the first C++ compiler, Cfront
> from Bell Labs, allowed separation of template declarations and definitions.
>
> Example:
>
> foo.h  // header file
> ------
>    template<class T> T foo(T);
>
> foo.cpp  // implementation file
> -------
>    template<class T> T foo(T t) { ... }
>
> Then you can write
>    #include <foo.h>
>    class myclass { ... }
>    myclass M = foo( myclass() );
>
> When a template declaration is seen in a file foo.h, the compiler
> automatically includes foo.cpp when the definition is needed.

Various forms of including template definition source files are not
doing what export does. To include the definitions you also include the
requisites and libraries used by the templates, and their requisites and
libraries, should these be also templates, and you include also any
components defined in that source for use only in the template body. And
there may very well be non-template code in the template definition
source files, related to the templates.

Including source files in one way or another does not separate the
declaration and the definition, export separates them.

Thank you,
Timothy Madden


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Feb 3, 9:16 pm, Steve Clamage <stephen.clam...@sun.com> wrote:
> On 01/31/10 19:27, Timothy Madden wrote:

> > On Jan 30, 2:15 am, Peter Bright <drpi...@gmail.com> wrote:

> ....

> > The point of export is to reduce the coupling that is now
> > required with template code.

> > [...]

> >> What problem is it solving?

> > What problem are prototypes for external functions solving ?
> > Why are functions not all inlined ?

> I'd like to put this point (and this feature comparison) to rest.

> With a function declaration
>    int foo(int);
> I can proceed to call or take the address of foo without ever
> having access to the source code, as long as a compiled
> version of the function is available at link time.

> To me, the equivalent functionality for export would be
> something like this:
>    export template<class T> T foo(T);
>    class myclass { ... };
>    myclass M = foo( myclass() );
> where the source code for template foo is not available.

> But export does not in fact give that comparable
> functionality. The standard does not promise it, and the only
> known implementation of export (EDG) does not provide it.

> You can declare a specific template instance and use it, as
> long as a compiled version is available at link time, but this
> functionality is exactly equivalent to an ordinary function
> declaration, and does not require exported templates.

> In my export example, the source code for template foo must be
> present when compiling the example. The export feature does
> not actually provide any help in this case.

> What about separating declarations and definitions?  You don't
> need export for that either, with many compilers. Even the
> first C++ compiler, Cfront from Bell Labs, allowed separation
> of template declarations and definitions.

> Example:

> foo.h  // header file
> ------
>    template<class T> T foo(T);

> foo.cpp  // implementation file
> -------
>    template<class T> T foo(T t) { ... }

> Then you can write
>    #include <foo.h>
>    class myclass { ... }
>    myclass M = foo( myclass() );

> When a template declaration is seen in a file foo.h, the
> compiler automatically includes foo.cpp when the definition is
> needed. You don't need export for this separation of
> declaration and definition. If your favorite compiler doesn't
> have this feature, you could ask for it. The feature is not
> hard to implement.

> As far as I can tell, and at least one of the EDG compiler
> writers who worked on export agrees with me, export as defined
> has no useful functionality.

> In an earlier posting in this thread, I said the C++ Committee
> voted to keep export in 2004, and that the subject would not
> be raised again. Due either to brain cells dying or
> insufficient caffeine, I had forgotten about the discussion in
> the last meeting, October 2009, where no conclusion was
> reached for C++0x about keeping, deprecating, or removing
> export. The issue will be discussed again at the next meeting
> in March. If a decision is reached, someone will post the
> result in this newsgroup.

> In the mean time, if anyone has an example where export has
> proved useful, and was better in some sense than alternatives,
> I'd like to see a posting about it.

There are really two separate issues.  The first concerns the
necessity of "source code".  This really depends on how you
define "source code"---at least some information from the source
code is necessary (more than is provided by a classical object
file), but this can be provided in many forms---at least one
implementation using CFront, for example, provided it in the
form of encrypted sources, and it doesn't require too much
imagination to imagine a special object file record which
contains (encryped, pre-parsed, compressed, or whatever) source
code.  If nothing else, this would allow at least the
functionality of CFront (which most modern compilers don't
achieve), and would make using templates, rather than
non-template classes and functions, more or less "transparent".

If the compiler/linker decides to make no effort to detect
violations of the one definition rule, even this could result in
significantly better compile times.  For certain uses, at least.

The other issue is the differing semantics of export.  In this
regard, export may not be the right, or the best answer, but it
is an answer.  The implementation of my templates is "protected"
from anything the user might do after the inclusion of the
header, and a lot of things he might do before.  (This wasn't
the case for CFront, since CFront used an implicite inclusion
model which would end up exposing whatever was in the
instantiation file anyway.)  In many ways, this is the same
argument as the one for two phase look-up---both serve to
isolate the template from the instantiation context, except for
dependent symbols.

Personally, I can't say that I'm totally convinced that export
is the right solution---I'd much prefer something along the
lines of David Vandevoortes modules proposal.  But in large
projects, something is necessary.

--
James Kanze

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 02/04/10 09:56, Timothy Madden wrote:

> On Wed, 2010-02-03 at 15:16 -0600, Steve Clamage wrote:
>
>>
>> To me, the equivalent functionality for export would be something like
>> this:
>>   export template<class T> T foo(T);
>>   class myclass { ... };
>>   myclass M = foo( myclass() );
>> where the source code for template foo is not available.
>>
>> But export does not in fact give that comparable functionality.
>>
>
> Yes it does. You /can/ proceed to call or take address of template
> function foo<myclass>(), without access to the source code as long as a
> compiled template definition is available at instantiation time. Just
> like with the function int foo(int).
>
> As the standard says, an implementation /can/ encode enough information
> in the compiled template definition so that the source is no longer
> needed for instantiation. So all you need is such an implementation.
>
> This is not implemented yet, but this is what the standard here is for:
> to recommend things as suitable for being implemented.
>

So in fact you do NOT get the equivalent of extern function declarations.
You agree the standard does not require it, and you agree there is no
implementation providing it.

There is a reason the functionality is not available. It is prohibitively
expensive at compile time (ignoring the difficulties of implementing the
additional capability in the first place).

To avoid needing the source code, the compiler would have to dump the
equivalent of the parse tree for the template, along with the symbol table
data. The symbol table data would have to include the transitive closure of
everything the template depends on. This amount of information is HUGE, and
would have to be done, possibly separately, for every exported template
definition. When instantiating an exported template, this data has to be
read in and merged with current environment in such a way that it can be
backed out after instantiating the template. Compilation would slow to a
crawl.

The export feature, which was voted in over the objections of EVERY compiler
implementer, was based on hope, not on experience or evidence. The hoped-for
results did not materialize, and probably cannot be realized in a meaningful
way.

But let's go back and think about what we want. Do we specifically want
exported templates?  Don't we really want the more general ability to
separate interface from implementation in a wider sense than individual
templates? Wouldn't we also want protection from symbols (especially macro
definitions) leaking from the implementation into the interface? (Exported
templates eliminate some leakage, but cause other kinds of leakage.)

A proposal for "modules" (among possibly other ideas) would do exactly that,
but in a way that is usable and reasonable to implement. When we had to make
a final decision about what could go into C++0x if we were to finish the
standard in a reasonable length of time, the modules proposal was not yet
ready for inclusion. I'm sure it will be revived for the next update of the
standard.

Unlike exported templates, we have real-world experience with modules in
other languages, such as Borland Pascal, Modula, and Fortran 95.

---
Steve Clamage

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Steve Clamage wrote:
>
> On 01/31/10 19:27, Timothy Madden wrote:
>
>> On Jan 30, 2:15 am, Peter Bright <drpi...@gmail.com> wrote:
>>
> ....
>
>> The point of export is to reduce the coupling that is now required
>> with template code.
>>
>> [...]
>>
>>> What problem
>>> is it solving?
>>>
>>
>> What problem are prototypes for external functions solving ? Why are
>> functions not all inlined ?
>>
>
> I'd like to put this point (and this feature comparison) to rest.
>
> With a function declaration
>  int foo(int);
> I can proceed to call or take the address of foo without ever having access
> to the source code, as long as a compiled version of the function is
> available at link time.
>
> To me, the equivalent functionality for export would be something like this:
>  export template<class T> T foo(T);
>  class myclass { ... };
>  myclass M = foo( myclass() );
> where the source code for template foo is not available.
>
> But export does not in fact give that comparable functionality. The standard
> does not promise it, and the only known implementation of export (EDG) does
> not provide it.
>
> You can declare a specific template instance and use it, as long as a
> compiled version is available at link time, but this functionality is
> exactly equivalent to an ordinary function declaration, and does not require
> exported templates.
>
> In my export example, the source code for template foo must be present when
> compiling the example. The export feature does not actually provide any help
> in this case.

Your summation of 'export' is excellent.

My argument, which may be that of others, is that 'export' should have
been given teeth so that the template source code did not need to be
available in source code form. How a compiler would do this is of
course a big issue, but I think that the C++ standard could have
specified that the source code for the template be 'compiled' into
some form, whether obfuscated or not, and automatically used when the
template declarations needed to be checked during phase 2 checking
without the end-user doing anything further ( such as including the
source code file also ).

>
> What about separating declarations and definitions?  You don't need export
> for that either, with many compilers. Even the first C++ compiler, Cfront
> from Bell Labs, allowed separation of template declarations and definitions.
>
> Example:
>
> foo.h  // header file
> ------
>  template<class T> T foo(T);
>
> foo.cpp  // implementation file
> -------
>  template<class T> T foo(T t) { ... }
>
> Then you can write
>  #include <foo.h>
>  class myclass { ... }
>  myclass M = foo( myclass() );
>
> When a template declaration is seen in a file foo.h, the compiler
> automatically includes foo.cpp when the definition is needed.

No compiler of which I know does that, and if it is not specified by
the C++ standard it is very hard for the end-user to rely on such
functionality. So your claiming that this currently "works" does not
convince me that it actaully does anywhere that I know about.

Nonetheless this is analogous to what I suggested above, but with
foo.cpp being "compiled" separately to some intermediate form just as
one compiles any source file. The difference is that if the C++
standard committee would have specified how 'export' must work, then
'export' could have effectively been used to separate template
declarations from their definitions, and perhaps to also hide the
template definitions themselves in the same way that programmers are
allowed to hide source code implementations when shipping a product.

> You don't need
> export for this separation of declaration and definition. If your favorite
> compiler doesn't have this feature, you could ask for it. The feature is not
> hard to implement.

I could ask for anything but that does not mean I will get it. But you
are totally right that even without 'export' it is completely possible
to separate template declarations and template definitions into
separate files and use them.

>
> As far as I can tell, and at least one of the EDG compiler writers who
> worked on export agrees with me, export as defined has no useful
> functionality.

I disagree that 'export' has theoretically no useful functionality as
an effort to allow the template programmer to separate template
declarations from their definitions. But as it has been specified in
the C++ standard it has little at all simply because it still requires
the template definitions in source code form to be available to source
code using templates.

Of course if one wanted to eliminate 'export' entirely but add new
rules in the standard which specified that the inclusion of template
declarations automatically forces the compiler to find and include the
template definitions, if they exist, in a similarly named file, with
the .cpp extension substituting for the template declaration
extension, that would at least be of some help.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]