In article <user-1109990909590001@aus-as5-026.io.com>,
  "nospam" <postmast.root.admi.gov@iname.com> wrote:
> (followups set to comp.std.c++)
>
> In article <walke751-0909990327040001@ts002d04.nor-ct.concentric.net>,
> walke751@concentric.net.invalid (Daryle Walker) wrote:
>
> > In article <mwron-0809992245430001@c243286-a.bcreek1.mi.home.com>,
> > mwron@metrowerks.com (MW Ron) wrote:

> > >In article <7r6mlf$630$1@nnrp1.deja.com>, matthias@remss.com wrote:

> > >>Stroustrup 3e discusses the template export keyword (in Section
> > >>13.7); unfortunately, it seems that this is not yet supported in
> > >>Pro 5. Are there any future plans to implement this feature?  It
> > >>sure would be handy...

> > >Actually there were no compilers (even the EDG based ones) that
> > >support the keyword Export or at least the last I looked there
> > >weren't . However this is one of the holy plateaus that we do plan
> > >on attaining.  It most likely would be an option as it surely would
> > >slow compiles down a lot.

> > Maybe it can be done like this:
> [snip scheme]

> The compiler would most likely store away information with the object
> code for the file specifying template functions that need to be
> compiled. For example,

>     export template<typename T>
>     void f();
>
>     void g() {
>         f<int>();
>     }

> would dump an instantiation request for f<int>.

> A source file that defined a template would dump information noting
> this fact.

>     export template<typename T>
>     void f() {
>         // ...
>     }

> Then, before linking, source files that were recompiled since the last
> link are checked for any template instantiation requests. These
> templates are compiled, and this process is repeated (since these
> templates may require instantiation of other exported templates).

This is more or less what CFront did.

> I suppose the critical issue (with regards to speed) is getting the
> defintion of the type(s) needed for template instantiation.

The critical issue (with regards to correctness) is getting the complete
instantiation context.  For example, consider the following:

t.hh:

    #include <iostream>

    inline void f( int ) { cout << "In f( int )\n" ; }

    template< typename T >
    void g( T )
    {
        f( 'a' ) ;
    }

x.cc

    static inline void f( char ) { cout << "In f( char )\n"; }
    #include "t.hh"

    int
    main()
    {
        g( 0 ) ;
        return 0 ;
    }

This code should output "In f( char )", which is rather difficult to
achieve with link time template instantiation.  (CFront would output "In
f( int )" for this program.)  (Obviously, no one would write code like
this.  But a correct compiler must still be able to compile it.)

> I could
> imagine a simplistic implementation re-parsing source file(s) (with
> the requests) as necessary, until all the definitions were found
> (because of the one-definition rule, it can stop after it's found all
> the definitions, regardless of which files it checks). As an
> optimization to this, the compiler could keep statistics on parse time
> for a source file that contained template instantiation requests,
> using this to choose files that were the fastest to parse, before
> others.

An intelligent implementation would keep the compiled versions of the
functions in a repository, with information concerning what they
actually depended on.  It would then only have to recompile when one of
the dependancies actually changed.  The real problem *is* maintaining
the complete context -- how does the compiler know to save the static
function f( char ) in this case, for example.

> From what I can tell, the purpose of export is to reduce compilation
> time.

The purpose of export is to permet separate compilation of templates.
Without it, templates are pretty much unusable in large projects, other
than for extremely stable basic containers.

> The benefit is derived in two ways: Template functions can be
> compiled only once, and the compilation dependencies of their
> implementation don't have to be passed on to clients.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ 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              ]

(followups set to comp.std.c++)

In article <walke751-0909990327040001@ts002d04.nor-ct.concentric.net>,
walke751@concentric.net.invalid (Daryle Walker) wrote:

> In article <mwron-0809992245430001@c243286-a.bcreek1.mi.home.com>,
> mwron@metrowerks.com (MW Ron) wrote:
>
> >In article <7r6mlf$630$1@nnrp1.deja.com>, matthias@remss.com wrote:
> >
> >>Stroustrup 3e discusses the template export keyword (in Section 13.7);
> >>unfortunately, it seems that this is not yet supported in Pro 5.  Are
> >>there any future plans to implement this feature?  It sure would be
> >>handy...
> >
> >Actually there were no compilers (even the EDG based ones)  that support
> >the keyword Export or at least the last I looked there weren't .  However
> >this is one of the holy plateaus that we do plan on attaining.  It most
> >likely would be an option as it surely would slow compiles down a lot.
>
> Maybe it can be done like this:
[snip scheme]

The compiler would most likely store away information with the object code
for the file specifying template functions that need to be compiled. For
example,

    export template<typename T>
    void f();

    void g() {
        f<int>();
    }

would dump an instantiation request for f<int>.

A source file that defined a template would dump information noting this fact.

    export template<typename T>
    void f() {
        // ...
    }

Then, before linking, source files that were recompiled since the last
link are checked for any template instantiation requests. These templates
are compiled, and this process is repeated (since these templates may
require instantiation of other exported templates).

I suppose the critical issue (with regards to speed) is getting the
defintion of the type(s) needed for template instantiation. I could
imagine a simplistic implementation re-parsing source file(s) (with the
requests) as necessary, until all the definitions were found (because of
the one-definition rule, it can stop after it's found all the definitions,
regardless of which files it checks). As an optimization to this, the
compiler could keep statistics on parse time for a source file that
contained template instantiation requests, using this to choose files that
were the fastest to parse, before others.

>From what I can tell, the purpose of export is to reduce compilation time.
The benefit is derived in two ways: Template functions can be compiled
only once, and the compilation dependencies of their implementation don't
have to be passed on to clients.
---
[ 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              ]