In article <39CCD1D1.C99340A4@aspi.net>, Trevor L. Jackson, III
<fullmoon@aspi.net> writes
>That context is sometimes hard to describe.  For instance, should
>#pragma settings be part of the saved context?  Should the definition or
>instantiation context be used? Some implementations do not preserve that
>fraction of the context wherein the template was defined.

So some compilers get it wrong. The mechanisms used to instantiate a
template should always produce the same, predictable, results. If they
do not we are all in trouble. The context of a template should always be
that in which the template is defined AND that in which it is being
instantiated. IMHO that should also include pragma's.


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              ]

Francis Glassborow wrote:

> In article <003b01c024ba$444bf700$aa0e38c3@bpnt>, Balog Pal
> <pasa@lib.hu> writes
> >In the case the compiler sees the implemetation somehow at a 'good'
> >time. In the past compilation time was an issue, and that was limiting
> >the passes. On most platforms you had the compiler that created code
> >(executable machine code) for functions from the info at hand, then a
> >linker put those functions together, without any modificatons but fixing
> >the address links. Certainly nothing forbids to insert arbitrary amount
> >of passes in between, when the whole code base is together. Then scan
> >for some selected functions and recompile others, then select again, and
> >so on. All you need is time. To do that certainly you must go back to
> >the source, or equivalent precooked form that has all the info the
> >source had.
>
> Oh that it really was that easy. And it isn't what those wanting
> separate compilation for templates really want anyway.
>
> One of the tough issues with separate compilation of templates is that
> the compiler still has to know the context in which the template is
> being instantiated so that it can do the bindings to free functions
> correctly.

That context is sometimes hard to describe.  For instance, should #pragma
settings be part of the saved context?  Should the definition or
instantiation context be used?
Some implementations do not preserve that fraction of the context wherein the
template was defined.



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

> But some compilers do inline precompiled code! It is a fairly common
> (particularly in highly optimizing C and Fortran compilers) to do a
> whole-program review of compiled modules, and substitute called
> functions inline at the point of the call. You eliminate the calling
> overhead for sure.

Sure, that's another reason I don't really understand why that 'export' is
needed. Quite many comilers use 'precompiled headers', for a ton of reasons.
That is a more general soulution, that as a side-effect makes templates and
inlines precompiled too.

Certainly on the code side you still have to present the source, just the
compiler will not parse it all the time, just on changes.
If you'd make it into the language it would only complicae things IMHO,
without any great benefit.

> In addition, the substitution might be done at the intermediate-
> language level, allowing more optimizing.

I think the optimization has nothing to do with the 'intermediate' issue.
The source is always parsed and compiled to some intermediate form, the only
difference is in the 'when' it happens, on every 1 compilation, or the
result is cached for further use. The optimizations and all the rest is not
influenced.

> You normally would not get
> the full benefit of some available C++ optimizations done at the
> source-code level, such as eliminating copies of objects.

That also can happen now at linker level. It's only matter of passes.
Unfortunately the virtual functions prevent most of this kind of
optimization, as the compiler/linker have to store the address of the
function in the VMT, and it can't assume what will actually be called at
runtime. And az an avalanche effect that code keeps a plenty of other
around.

> The optimization is expensive in compile time, of course, but often
> makes a significant difference in program efficiency that is important
> in high-performance computing.

IMHO in real-life development you compile without opt 99% of the time, as
you'll want to debug your code, and performance is not needed until very
late. The few compiles to release build can take their time.

Paul





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

"Greg Comeau" <comeau@panix.com> wrote

> >Probably you don't quite understand what the compiler really does.
> IMO, he does.
...
> >and no pre-compiled stuff can be used to do that.
> Really?

We're probably talking about different issues. My original stuff was about
the case the compiler not seeing the implemetation of a function in any
form.
If the compiler can access the implementation, it is just detail if it is
raw or precompiled. (however the end-result machine code is likely
insufficient for that use).

> >What can be implemented of your requirement above, to insert a
precompiled
> >body "inline" actually has not a slightest difference from the regular
> >function call.
>
> Then neither does a non-precompiled inline.

> And moreover that comes full circle on why any function can't
> be exported then, since a function can still be inlined
> w/o having to say 'inline'.

In the case the compiler sees the implemetation somehow at a 'good' time.
In the past compilation time was an issue, and that was limiting the passes.
On most platforms you had the compiler that created code (executable machine
code) for functions from the info at hand, then a linker put those functions
together, without any modificatons but fixing the address links.
Certainly nothing forbids to insert arbitrary amount of passes in between,
when the whole code base is together. Then scan for some selected functions
and recompile others, then select again, and so on. All you need is time. To
do that certainly you must go back to the source, or equivalent precooked
form that has all the info the source had.

Paul






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

In article <003a01c024ba$42a63640$aa0e38c3@bpnt>, Balog Pal
<pasa@lib.hu> writes
>Sure, that's another reason I don't really understand why that 'export'
>is needed. Quite many comilers use 'precompiled headers', for a ton of
>reasons. That is a more general soulution, that as a side-effect makes
>templates and inlines precompiled too.

I have tried hard, but I do not understand this statement. The object of
'export' is to take template implementations out of headers (i.e. the
template class definition is in the header but the definitions of the
member functions are in an implementation file exactly as we do ordinary
classes.


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              ]

In article <003b01c024ba$444bf700$aa0e38c3@bpnt>, Balog Pal
<pasa@lib.hu> writes
>In the case the compiler sees the implemetation somehow at a 'good'
>time. In the past compilation time was an issue, and that was limiting
>the passes. On most platforms you had the compiler that created code
>(executable machine code) for functions from the info at hand, then a
>linker put those functions together, without any modificatons but fixing
>the address links. Certainly nothing forbids to insert arbitrary amount
>of passes in between, when the whole code base is together. Then scan
>for some selected functions and recompile others, then select again, and
>so on. All you need is time. To do that certainly you must go back to
>the source, or equivalent precooked form that has all the info the
>source had.

Oh that it really was that easy. And it isn't what those wanting
separate compilation for templates really want anyway.

One of the tough issues with separate compilation of templates is that
the compiler still has to know the context in which the template is
being instantiated so that it can do the bindings to free functions
correctly.



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              ]

In article <39C7C538.E28893AD@grog.net>, Derek Kusiak  <spam@grog.net> wrote:
>> >Inline means a pack of code you want to be inlined. If the function resides
>> >in some CPP, and gets called, it is no longer inline. So your export for
>> >inlines is just equal to removing the inline. ;-)
>>
>> Clearly, he wants to change that behavior, and have it work even if
>> if it's in a .cpp file.  The basic premise, of shortening header
>> files, speeding compilation, seperating interface and implementation,
>> etc, is the point he's trying to raise.
>
>Thank you. That was indeed the whole reason I raised this question.

Your welcome.  If it's not clear by now, it could have been done
but wasn't.  Personally, I always wished for more environmental
support from the language, as I really despise #include et al,
but so be it.

- Greg
--
Comeau Computing / Comeau C/C++ ("so close" 4.2.44 betas starting)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

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

In article <slrn8s84bs.5f9.juergen@monocerus.n-online.de>,
Juergen Heinzl <juergen@monocerus.n-online.de> wrote:
>it would not be possible to put the template into a .C o. .cpp file,

Not sure what you mean.

- Greg
--
Comeau Computing / Comeau C/C++ ("so close" 4.2.44 betas starting)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

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

In article <005d01c0206b$0636d460$f50e38c3@bpnt>, Balog Pal
<pasa@lib.hu> writes
>What can be implemented of your requirement above, to insert a
>precompiled body "inline" actually has not a slightest difference from
>the regular function call.

Maybe you do not get maximum benefit, but you should be fair and
recognise that there are many places where the optimisation by code
substitution is fine. In many cases forwarding functions entail no more
than substituting one function call address for another.


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              ]

In article <005d01c0206b$0636d460$f50e38c3@bpnt>,
Balog Pal <pasa@lib.hu> wrote:
>"Derek Kusiak" <spam@grog.net> wrote in message
>>That's my point: why can't "export" for an inline say to
>>the compiler "remember this definition and insert it _inline_
>>into every translation unit that needs it."
>
>Probably you don't quite understand what the compiler really does.

IMO, he does.

>When a function is compiled, the following happens:
><some stuff about passing args, context, and such snipped>
>
>The purpose of inlne is twofold. One immediate is avoiding the overhead
>introduced by param/return passing. The inlined code access the param
>'in place' skipping the protocol of the regular call.  Certainly that
>means the code will be different in each situation,

Ok, ok....

>and no pre-compiled stuff can be used to do that.

Really?

>...
>What can be implemented of your requirement above, to insert a precompiled
>body "inline" actually has not a slightest difference from the regular
>function call.

Then neither does a non-precompiled inline.

And moreover that comes full circle on why any function can't
be exported then, since a function can still be inlined
w/o having to say 'inline'.

- Greg
--
Comeau Computing / Comeau C/C++ ("so close" 4.2.44 betas starting)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

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

In article <8q2d1g$1be$1@panix6.panix.com>, Greg Comeau wrote:
>In article <slrn8s84bs.5f9.juergen@monocerus.n-online.de>,
>Juergen Heinzl <juergen@monocerus.n-online.de> wrote:
>>it would not be possible to put the template into a .C o. .cpp file,
>
>Not sure what you mean.
[-]

Yes - what I meant is if I want the compiler to generate inlined
code, then put it into an include file. Say usually I do not
include a .C / cpp / cxx file and yes, I presumed the idea was
to make it visible to more than one source file.

Sorry for those implizit assumptions,
Juergen

--=20
\ Real name     : J=FCrgen Heinzl         \       no flames      /
 \ EMail Private : monocerus@n-online.de \ send money instead /

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

> >Inline means a pack of code you want to be inlined. If the function resides
> >in some CPP, and gets called, it is no longer inline. So your export for
> >inlines is just equal to removing the inline. ;-)
>
> Clearly, he wants to change that behavior, and have it work even if
> if it's in a .cpp file.  The basic premise, of shortening header
> files, speeding compilation, seperating interface and implementation,
> etc, is the point he's trying to raise.

Thank you. That was indeed the whole reason I raised this question.

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

The new (and currently mostly unsupported) keyword "export" allows
template definitions to reside in .cpp files and (as I understand it)
leaves it to the compiler (or preprocessor?) to make sure the template
definition ends up in each translation unit where it's needed.

As of now, an inline function must be defined in each translation unit
that uses that function (ANSI/ISO/IEC 14882:1998, 3.2[3]).

Why no exporting inlines?

Is there a fundamental reason why "export" is a good idea for templates
but not for inlines?

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

Balog Pal wrote:

> Inline means a pack of code you want to be inlined. If the function resides
> in some CPP, and gets called, it is no longer inline. So your export for
> inlines is just equal to removing the inline. ;-)

That's my point: why can't "export" for an inline say to the compiler "remember
this definition and insert it _inline_ into every translation unit that needs
it."

I guess I just don't see why the compiler can't be left to the task of placing
the function definition in each client translation unit. That way all the
definitions could happily live in an implementaion file without having to
differentiate between functions based on how they will be used. Having some
functions in .cpp files and others in .inl (or .h or whatever) files just seems
so...clunky. It seems like I'm doing work that the compiler could be doing out
unambiguously at my command (through the inline directive).

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

Derek Kusiak <spam@grog.net> writes:

|>  The new (and currently mostly unsupported) keyword "export" allows
|>  template definitions to reside in .cpp files and (as I understand
|>  it) leaves it to the compiler (or preprocessor?) to make sure the
|>  template definition ends up in each translation unit where it's
|>  needed.

|>  As of now, an inline function must be defined in each translation
|>  unit that uses that function (ANSI/ISO/IEC 14882:1998, 3.2[3]).

|>  Why no exporting inlines?

|>  Is there a fundamental reason why "export" is a good idea for
|>  templates but not for inlines?

Probably only that it didn't occur to anyone.  The necessary mechanisms
are the same.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

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

In article <000101c01f56$c4605530$e90e38c3@bpnt>,
Balog Pal <pasa@lib.hu> wrote:
>"Derek Kusiak" <spam@grog.net> wrote in message
>> ....Why no exporting inlines?
>
>Inline means a pack of code you want to be inlined. If the function resides
>in some CPP, and gets called, it is no longer inline. So your export for
>inlines is just equal to removing the inline. ;-)

Clearly, he wants to change that behavior, and have it work even if
if it's in a .cpp file.  The basic premise, of shortening header
files, speeding compilation, seperating interface and implementation,
etc, is the point he's trying to raise.

- Greg
--
Comeau Computing / Comeau C/C++ ("so close" 4.2.44 betas starting)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

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

In article <39C2942F.300ECA1A@grog.net>, Derek Kusiak wrote:
>Balog Pal wrote:
>
>> Inline means a pack of code you want to be inlined. If the function re=
sides
>> in some CPP, and gets called, it is no longer inline. So your export f=
or
>> inlines is just equal to removing the inline. ;-)
>
>That's my point: why can't "export" for an inline say to the compiler "r=
emember
>this definition and insert it _inline_ into every translation unit that =
needs
>it."
[-]

IMHO it'd be redundant as something along that line can be achieved by us=
ing
a template function::

template <typename type>
inline
type min_( type arg0, type arg1 ) {
  return arg0 < arg1 ? arg0 : arg1;
}

I'm aware min_( 3L, 4 ) is not going to compile, but would consider
it a good thing to force the developer into thinking it over. Sure,
it would not be possible to put the template into a .C o. .cpp file,
but the capability would only make the compiler more complex.

Cheers,
Juergen

--=20
\ Real name     : J=FCrgen Heinzl         \       no flames      /
 \ EMail Private : monocerus@n-online.de \ send money instead /

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

"Derek Kusiak" <spam@grog.net> wrote in message

> > Inline means a pack of code you want to be inlined. If the function
resides
> > in some CPP, and gets called, it is no longer inline. So your export for
> > inlines is just equal to removing the inline. ;-)
>
> That's my point: why can't "export" for an inline say to the compiler
"remember
> this definition and insert it _inline_ into every translation unit that
needs
> it."

Probably you don't quite understand what the compiler really does.

When a function is compiled, the following happens:

1. You have a protocol to pass arguments to the function. That is observed
by caller and callee in a similar way. So the compiled function starts with
estabilishing context to get its arguments.
2. the main function body follows, that access the arguments in the
localized place made by 1.
3. The return value is placed using a protocol too.

A common solution is to use a stack to passing arguments, and use a register
to get small return value, and plus one param on the stack to pass back
bigger thing.
The call pushes the arguments on the stack, the function finds them at fixed
address relative to the stack pointer. Then at return one party will clear
the stack.

The purpose of inlne is twofold. One immediate is avoiding the overhead
introduced by param/return passing. The inlined code access the param 'in
place', skipping the protocol of the regular call. Certainly that means the
code will be different in each situation, and no pre-compiled stuff can be
used to do that. Also, the return value emerges directly where it should.

The other (probably major) purpose of the thing that it allows optimisation.
A regular function uses a call. that call makes the compiler 'lose focus' on
its doings, as nothing can foresee what global changes that call could make.
The compiler must invalidate all its precompiled results. However when no
actual call happens, but the code is inlined, it can evaluate what objects
could have changed, and what results can still be used.

What can be implemented of your requirement above, to insert a precompiled
body "inline" actually has not a slightest difference from the regular
function call.

Paul






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

On Sun, 17 Sep 2000 14:37:58 GMT, "Balog Pal" <pasa@lib.hu> wrote:

>The purpose of inlne is twofold. One immediate is avoiding the overhead
>introduced by param/return passing. The inlined code access the param 'in
>place', skipping the protocol of the regular call. Certainly that means the
>code will be different in each situation, and no pre-compiled stuff can be
>used to do that. ...
>The other (probably major) purpose of the thing that it allows optimisation.
>A regular function uses a call. that call makes the compiler 'lose focus' on
>its doings, as nothing can foresee what global changes that call could make.
>The compiler must invalidate all its precompiled results.

But some compilers do inline precompiled code! It is a fairly common
(particularly in highly optimizing C and Fortran compilers) to do a
whole-program review of compiled modules, and substitute called
functions inline at the point of the call. You eliminate the calling
overhead for sure.

In addition, the substitution might be done at the intermediate-
language level, allowing more optimizing. You normally would not get
the full benefit of some available C++ optimizations done at the
source-code level, such as eliminating copies of objects.

The optimization is expensive in compile time, of course, but often
makes a significant difference in program efficiency that is important
in high-performance computing.

---
Steve Clamage, stephen.clamage@sun.com

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

"Balog Pal" <pasa@lib.hu> writes:

|>  "Derek Kusiak" <spam@grog.net> wrote in message

|>  > The new (and currently mostly unsupported) keyword "export" allows
|>  > template definitions to reside in .cpp files and (as I understand
|>  > it) leaves it to the compiler (or preprocessor?) to make sure the
|>  > template definition ends up in each translation unit where it's
|>  > needed.

|>  > As of now, an inline function must be defined in each translation
|>  > unit that uses that function (ANSI/ISO/IEC 14882:1998, 3.2[3]).

|>  > Why no exporting inlines?

|>  > Is there a fundamental reason why "export" is a good idea for
|>  > templates but not for inlines?

|>  Inline means a pack of code you want to be inlined. If the function
|>  resides in some CPP, and gets called, it is no longer inline. So
|>  your export for inlines is just equal to removing the inline. ;-)

But if compiling your exported inline results in some
meta-representation, as is the case with exported templates, then the
compiler can generate the code inline.

|>  For templates the expost has other meaning. (I guess) you can't
|>  export the template as a template.=20

You guess wrong.


--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

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

The new (and currently mostly unsupported) keyword "export" allows
template definitions to reside in .cpp files and (as I understand it)
leaves it to the compiler (or preprocessor?) to make sure the template
definition ends up in each translation unit where it's needed.

As of now, an inline function must be defined in each translation unit
that uses that function (ANSI/ISO/IEC 14882:1998, 3.2[3]).

Why no exporting inlines?

Is there a fundamental reason why "export" is a good idea for templates
but not for inlines?



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

"Derek Kusiak" <spam@grog.net> wrote in message

> The new (and currently mostly unsupported) keyword "export" allows
> template definitions to reside in .cpp files and (as I understand it)
> leaves it to the compiler (or preprocessor?) to make sure the template
> definition ends up in each translation unit where it's needed.
>
> As of now, an inline function must be defined in each translation unit
> that uses that function (ANSI/ISO/IEC 14882:1998, 3.2[3]).
>
> Why no exporting inlines?
>
> Is there a fundamental reason why "export" is a good idea for templates
> but not for inlines?

Inline means a pack of code you want to be inlined. If the function resides
in some CPP, and gets called, it is no longer inline. So your export for
inlines is just equal to removing the inline. ;-)

For templates the expost has other meaning. (I guess) you can't export the
template as a template. You only can export a specialization of a template
(or many specializations). If the client code runs into a place where a new
specialization is needed, you'll need the full template again, but where the
imported stuff is enough, the compiler will be contetnt having the interface
only. Thus saving compile & link time.

Paul




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