In article <1edj3dt.15ycvznko9k2eN%dwalker07@snet.net.invalid>, Daryle
Walker <dwalker07@snet.net.invalid> writes
>Since I've heard that the ANSI/ISO C++ standard committee guys were
>supposed to organize existing practice, why did they introduce a
>totally-new feature that requires a _fundamental_ change in C++
>compilation?!

In simple terms because C++ had always promised separate compilation for
templates and export was the only way those who insisted that the
promise should be honoured could compromise with those who said that it
was an unacceptable burden. Just take my word for it, the air almost
crackled with ire.



Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

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

As I understand it, the traditional C and C++ compilation model consists
of a single text file being compiled to an object module, and the
several objects for a program are combined by a linker.  I say it's one
file since the interfaces of other modules, the header files, are
generally blindly dumped into the main file by the pre-processor.  Any
connection between the object modules is done by the programmer manually
making sure the compiler and linker options for each file are
compatible.

This doesn't seem to require a smart compilation system.  On the
contrary, it's one of the more simple ones.  It's understandable since
better systems couldn't be done when C was invented.

However, it seems that supporting the "export" keyword, with
declarations and definition of a templated item in seperate files, is
beyond this model.  It requires real coordination between several
header, source, and object files or, worse, all the files in a program.
Since I've heard that the ANSI/ISO C++ standard committee guys were
supposed to organize existing practice, why did they introduce a
totally-new feature that requires a _fundamental_ change in C++
compilation?!

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

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

Daryle Walker wrote:
>
> However, it seems that supporting the "export" keyword, with
> declarations and definition of a templated item in seperate files, is
> beyond this model.  It requires real coordination between several
> header, source, and object files or, worse, all the files in a program.
> Since I've heard that the ANSI/ISO C++ standard committee guys were
> supposed to organize existing practice, why did they introduce a
> totally-new feature that requires a _fundamental_ change in C++
> compilation?!

Because some compilers attempted to implement template linking (SUN for
example).  The idea is that templates weren't intended to be just a replacement
for the preprocessor, but the basis of their own library system.

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

Hi,
In article <1edj3dt.15ycvznko9k2eN%dwalker07@snet.net.invalid>,
  dwalker07@snet.net.invalid (Daryle Walker) wrote:
> Since I've heard that the ANSI/ISO C++ standard committee guys were
> supposed to organize existing practice, why did they introduce a
> totally-new feature that requires a _fundamental_ change in C++
> compilation?!

Library vendors want/wanted (at that time Open Source was not as
popular as it is today) a mechanism to support temnplates while also
protecting their implementation in form of some binary mechanism. To do
so, some implementations started to support some kind of template
repository but the semantics of them where not covered by the standard
and thus differed between implementation. The 'export' keyword and the
support for separate compilation basically has two effects for library
vendors:

- They have a standard way to organize their code with identical
  behavior between different comilers.
- All vendors of C++ implementations have to support this model (but
  there is no requirement that there can be some binary template
  distribution; this is what library vendors hope for).

>From a user's point of view this feature is also highly desirable:
Compiling code with lots of templates really slows down the turn around
cycles, especially when using optimization. Basically, the template
code in IOStreams has an impact even on people not using templates at
all (at least with most IOStreams implementations; however, even
without 'export' this is not required as is demonstrated by my IOStream
implementation).

It also has to be noted that the C++ committee did *not* only
standardize common practice. It also removed problems and made the
language more consistent in many areas: There was a lot of inventions
brought into the language via the standardization committee.
--
<mailto:dietmar_kuehl@yahoo.com>
<http://www.dietmar-kuehl.de/>


Sent via Deja.com http://www.deja.com/
Before you buy.

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