In article: <Dr1sqo.69t@edg.com>  jsa@edg.com (J. Stephen Adamczyk) writes:
> The motion to remove separate compilation of templates did not arise from
> a feeling that separate compilation of templates is a bad thing, or that
> users of C++ do not want separate compilation of templates.  Rather, it
> came from an opinion that the particular version of separate compilation
> of templates that is described in the current Working Paper (a) has not been
> implemented, (b) would be prohibitively expensive (in compilation speed
> and disk use), and (c) would not necessarily give users what they want.
> In short, there may well be a good way of providing separate compilation
> of templates, but this isn't it.  (Several vendors have implementations
> that do separate compilation of templates, but they all do it in ways
> rather different from what the WP mandates, and the standards committee
> doesn't seem inclined to standardize anything along those lines.)

I can see that separate compilation could be difficult because of the
need to identify relevant elements of the context from the point of
definition and the point(s) of instantiation.  But surely the "one
definition rule" has the effect of absolving the implementor from
resolving discrepancies in the latter.  (I.e. any mechanism by which a
point of instantiation can be chosen as the "real" one and the actual
instantiation tied to it is valid.)  The only problem is in supplying the
context information to that instantiation.  As a user I don't see how this
differs (except in application) from the "template repository" and/or
"precompiled header" technologies that exist in a number of current
implementations.

The problem is that these multiple approaches make moving between
implementations problematic.  A standardised approach would address
this.

> In addition, time is running out for this standard.  Even if there were
> a marvelous proposal for a better way to do separate compilation of
> templates, it would take several meetings to get it in shape to put into
> the WP, and it still would not have been implemented and proven in
> real-world use.  The choices seem to be (a) delay the standard in the
> hope of getting an appropriate definition of separate compilation of
> templates, or (b) standardize the lowest common denominator, and when
> someone comes up with an approach we all like, update the standard.
> Of the two, (b) seems like the prudent approach, and that's what was
> brought up for a vote in March.

There seems to be a lot of work already accumulating for "after this
version get ratified".  Is this just my impression, or is it reality?


Alan Griffiths               | Also editor of: The ISDF Newsletter
Senior Systems Consultant,   | (An Association of C and C++ Users publication)
CCN Group Limited.           | (ISDF editor : isdf@octopull.demon.co.uk)
(agriffiths@ma.ccngroup.com) | (For ACCU see: http://bach.cis.temple.edu/accu)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

>>>>> "A" == Alan Griffiths <aGriffiths@ma.ccngroup.com> writes:
[...]
A> I can see that separate compilation could be difficult because
A> of the need to identify relevant elements of the context from
A> the point of definition and the point(s) of instantiation.  But
A> surely the "one definition rule" has the effect of absolving
A> the implementor from resolving discrepancies in the latter.

I'm sure it does (i.e., violations of the ODR do not require
diagnostics), but I think until now they could in principle be
diagnosed relatively easily in popular environments (I may be
seriously wrong in this :). I certainly would like to know if
multiple non-equivalent bindings were possible due to implicit
instantiations --- I think such errors may be awfully hard to
find.

A> [...] The only problem is in supplying the context
A> information to that instantiation.  As a user I don't see how
A> this differs (except in application) from the "template
A> repository" and/or "precompiled header" technologies that exist
A> in a number of current implementations.

Wouldn't the number of contexts to be considered be very large
if the several levels of ``indirect instantiation'' occurred?

A> The problem is that these multiple approaches make moving
A> between implementations problematic.  A standardised approach
A> would address this.

Standardization will certainly help; the question is ``which standard?''.

I really want _source_ separation (i.e., no explicit #includes of
non-inline function template definitions). I also prefer separate
_instantiation contexts_, but the technical problems of the separation
model seem genuine... Still, the inclusion model makes unnamed
namespaces pretty much useless (does that mean that global `static'
specifiers would no longer be deprecated?) and certain common
macro-idioms less convenient.

[...]
A> There seems to be a lot of work already accumulating for "after
A> this version get ratified".  Is this just my impression, or is
A> it reality?

I'm sure the wishlist for C++ 2010 will be impressive ;-)

 Daveed
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

I've just come across a worrying rumour that the separate compilation
of templates is to be removed from the draft standard.

I'm currently working with a compiler - MSVC4 - that (from tests
manually separating template instantiation) spends most of its time either
generating redundent copies of templates (at the end of each compilation)
or deduplicating them (at link time).

I have been looking forward to the day that separate compilation
reduces my build times by around 80%.

 o  Is the rumor true?
 o  Can this be stopped?
 o  What can I do to prevent it happening?

Alan Griffiths               | Also editor of: The ISDF Newsletter
Senior Systems Consultant,   | (An Association of C and C++ Users publication)
CCN Group Limited.           | (ISDF editor  : isdf@octopull.demon.co.uk)
(agriffiths@ma.ccngroup.com) | (For ACCU see : http://bach.cis.temple.edu/accu)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <454171532wnr@ma.ccngroup.com> aGriffiths@ma.ccngroup.com writes:
>I've just come across a worrying rumour that the separate compilation
>of templates is to be removed from the draft standard.
>
>I have been looking forward to the day that separate compilation
>reduces my build times by around 80%.
>
> o  Is the rumor true?
> o  Can this be stopped?
> o  What can I do to prevent it happening?

It's a little early to tell what will happen in the standard.  The topic
was discussed at length and heatedly at the most recent meeting.  The
ANSI X3J16 group ended up with a faily decisive consensus (in favor of
removing separate compilation of templates), but the ISO WG21 group did
not, so the issue will be discussed further at the upcoming meeting.

Statement of bias: I am one of the people who pushed for removing separate
compilation of templates from the standard.  Everything I say below should
be read as my opinion.

The motion to remove separate compilation of templates did not arise from
a feeling that separate compilation of templates is a bad thing, or that
users of C++ do not want separate compilation of templates.  Rather, it
came from an opinion that the particular version of separate compilation
of templates that is described in the current Working Paper (a) has not been
implemented, (b) would be prohibitively expensive (in compilation speed
and disk use), and (c) would not necessarily give users what they want.
In short, there may well be a good way of providing separate compilation
of templates, but this isn't it.  (Several vendors have implementations
that do separate compilation of templates, but they all do it in ways
rather different from what the WP mandates, and the standards committee
doesn't seem inclined to standardize anything along those lines.)

In addition, time is running out for this standard.  Even if there were
a marvelous proposal for a better way to do separate compilation of
templates, it would take several meetings to get it in shape to put into
the WP, and it still would not have been implemented and proven in
real-world use.  The choices seem to be (a) delay the standard in the
hope of getting an appropriate definition of separate compilation of
templates, or (b) standardize the lowest common denominator, and when
someone comes up with an approach we all like, update the standard.
Of the two, (b) seems like the prudent approach, and that's what was
brought up for a vote in March.

Steve Adamczyk
Edison Design Group


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