Is the following _translation unit_ valid? (*)

template<class T> T f(T);

int main
{
  return f(5);
}

If no, why? If yes, let's assume that the whole program contains two
translation units; what should the second TU contain in order for the program
to be valid?

If this is a legal way to separate template declarations from their
definition, why is 'export' necessary?

--
Peter Dimov
Multi Media Ltd

(*) The compilers I tried have no problems with it, generating an external
reference to f<int>(int).



 -----  Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web  -----
  http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

pdimov@techno-link.com writes:

Disclaimer -- I have not _used_ export (since it's not supported in my
compiler yet) but I did read (and I think understand) the standard's
definition. But watch out just in case someone steps in to correct me.

> Is the following _translation unit_ valid? (*)
>
> template<class T> T f(T);
>
> int main
> {
>   return f(5);
> }
>
> If no, why? If yes, let's assume that the whole program contains two
> translation units; what should the second TU contain in order for the program
> to be valid?

It is valid, but it assumes that f<int>(int) is instantiated in a
different TU. For the code to link into an executable, you'll have to
link it with an instantiation of f<int>.

I use that kind of code all the time to avoid duplicate instantiations
(and hence unnecessarily lengthy compile times).

> If this is a legal way to separate template declarations from their
> definition, why is 'export' necessary?

export is used to be able to instantiate a template in a translation
unit without knowing its definition (i.e. only knowing its
declaration).

The compiler obviously cannot instantiate f<int> in the above code, so
this will have to be done somewhere else. If the template was exported
it would instantiate it in your given TU (even though it doesn't know
the definition).

The relevant paragraphs are Section 14, paragraphs 6-9.

> --
> Peter Dimov
> Multi Media Ltd

--
Stefanus Du Toit --- sjdutoit at uwaterloo dot ca --- http://3.141593.org/
Undergraduate Computer Science student, University of Waterloo, ON, Canada
Free Software Programmer, GNU User --- GnuPG key: http://3.141593.org/gpg/

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

> Is the following _translation unit_ valid? (*)
>
> template<class T> T f(T);
>
> int main
> {
>   return f(5);
> }
>
> If no, why? If yes, let's assume that the whole program contains two
> translation units; what should the second TU contain in order for the
program
> to be valid?

This translation unit is valid only on condition that there's another
translation unit (belonging to the same program) that either contains an
exported definition of the function template f, or explicitly instantiates
the specialization  f<int>.


Cheers,
Andrei Iltchenko.




---
[ 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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]