Bill Leonard writes:

> In article <01bc34f2$ad5fd4c0$1c0b1d26@ghost.artnet.net>, "Sean L.
> Palmer" <seanpalmer@mindspring.com> writes:
>> > One of the problems I have with this scheme is this: How do I control
>> > the set of options used by the compiler to compile instantiations at
>> > link time?

>> Store those compiler options in the .OBJ file along with the parsed
>> templates.

> What options?  From where?

> I think you missed my point.  I compile say 20 files, some with different
> compiler options than others.  Now the "linker" comes along and is going to
> instantiate some templates.  What compiler options should it use?  The ones
> specified on one of my 20 source files?  If so, which ones?  But far more
> importantly to me, what if none of those sets of options are the ones I
> want to use to compile these template instantiations?  What if two
> different source files both used a particular template instantiation, but
> those two files were compiled with different options?  Which set will the
> "linker" use to compile the instantiation?

If two different files use a given template, but different compiler
options cause different code for the templates to be generated, this
would, in a way, violate paragraph 5 of [basic.def.odr] (among other
things, it says that templates should be given exactly the same
definition in different compilation units).

If you wish to explicitly specify the options to be used to compile a
template instantiation, you should explicitly instantiate it in a
translation unit compiled with those options, and ideally make this
template exported.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil
---
[ 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 <01bc34f2$ad5fd4c0$1c0b1d26@ghost.artnet.net>, "Sean L.
Palmer" <seanpalmer@mindspring.com> writes:
> > One of the problems I have with this scheme is this: How do I control
> > the set of options used by the compiler to compile instantiations at
> > link time?

> Store those compiler options in the .OBJ file along with the parsed
> templates.

What options?  From where?

I think you missed my point.  I compile say 20 files, some with different
compiler options than others.  Now the "linker" comes along and is going to
instantiate some templates.  What compiler options should it use?  The ones
specified on one of my 20 source files?  If so, which ones?  But far more
importantly to me, what if none of those sets of options are the ones I
want to use to compile these template instantiations?  What if two
different source files both used a particular template instantiation, but
those two files were compiled with different options?  Which set will the
"linker" use to compile the instantiation?

I want to be able to specify the compiler options when my source gets
compiled.  I also want to know, definitively, what options were used when a
given piece of source was compiled.  If I don't know who/when the source is
going to get compiled, I have no opportunity to do that.

--
Bill Leonard
Concurrent Computer Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.ccur.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Concurrent Computer Corporation.

------------------------------------------------------------------------------
If I had my life to live over again, I think I *would* believe in
reincarnation.
------------------------------------------------------------------------------
---
[ 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                             ]

In article <199703171750.JAA06047@taumet.eng.sun.com>, Stephen.Clamage@eng.sun.com (Steve Clamage) writes:

> Eventually you link the complete program. The "link" process is actually
> a multi-step process which calls the actual linker as the last step.
> A special program scans all the object files presented for linking
> looking for needed template instantiations. Any current instantiations
> found in the template data base are automatically added to the list
> of files to be linked. Any missing instantiations are noted, and the
> template source code is compiled to create the instantiations. Those
> instantiations are added to the template data base and to the list of
> files to be linked. This process is repeated until no more
> instantiations are needed. The complete program is then linked.

One of the problems I have with this scheme is this: How do I control
the set of options used by the compiler to compile instantiations at
link time?  At compile time, I supply options to control things like
optimization, definition of macros, include-file paths, and so on.
I do NOT generally supply those options at link time.

Even if I did supply those options, there's still the question of what
options to use.  I can't tell which source(s) the "linker" is going to
attempt to compile, so how do I know what options to specify?  Suppose, for
instance, that I want a particular template to be compiled with a special
optimization -- how do I communicate that to the compiler at link time?

Most modern compilers have tons of options to control optimization, code
generation, and allocation of resources.  If I don't know *when* something
is going to be compiled, I can't specify *how* it should be compiled.

> In real life, you need to recompile program parts because of errors
> or changes in the source code. If the changes do not invalidate an
> instantiation previously generated (and the compiler has to be a
> bit pessimistic about invalidation),

A problem here is how to teach the compiler about my source control or
configuration management system.  The compiler might use a totally
inappropriate way of figuring out whether something has "changed" in order
to test for validity if I am using a source control system.  As a simple
example, suppose I am on a Unix system, and the compiler uses "stat" to
tell if a file has changed.  Some source management systems use symbolic
links to a "file cache" to set up a virtual environment reflecting a
particular configuration of the source.  A "stat" system call will return
the modification time of the target file, not the symbolic link to that
file.  But it is the link's modification time that is important in many
cases, so the compiler will think the file is not out-of-date when, in
fact, it is.

--
Bill Leonard
Concurrent Computer Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
Bill.Leonard@mail.ccur.com

These opinions and statements are my own and do not necessarily reflect the
opinions or positions of Concurrent Computer Corporation.
---
[ 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
]

bill@amber.ssd.csd.harris.com (Bill Leonard) writes:

|>  In article <199703171750.JAA06047@taumet.eng.sun.com>, Stephen.Clamage@eng.sun.com (Steve Clamage) writes:
|>
|>  > Eventually you link the complete program. The "link" process is actually
|>  > a multi-step process which calls the actual linker as the last step.
|>  > A special program scans all the object files presented for linking
|>  > looking for needed template instantiations. Any current instantiations
|>  > found in the template data base are automatically added to the list
|>  > of files to be linked. Any missing instantiations are noted, and the
|>  > template source code is compiled to create the instantiations. Those
|>  > instantiations are added to the template data base and to the list of
|>  > files to be linked. This process is repeated until no more
|>  > instantiations are needed. The complete program is then linked.
|>
|>  One of the problems I have with this scheme is this: How do I control
|>  the set of options used by the compiler to compile instantiations at
|>  link time?  At compile time, I supply options to control things like
|>  optimization, definition of macros, include-file paths, and so on.
|>  I do NOT generally supply those options at link time.
|>
|>  Even if I did supply those options, there's still the question of what
|>  options to use.  I can't tell which source(s) the "linker" is going to
|>  attempt to compile, so how do I know what options to specify?  Suppose, for
|>  instance, that I want a particular template to be compiled with a special
|>  optimization -- how do I communicate that to the compiler at link time?

But isn't this a problem no matter what template instantiation scheme is
used, except explicit instantiation?  In fact, I think that on any
implementation, if you want some particular option for the template
class, and not generally for the other classes, you will have to
explicitly instantiate the template, probably before the normal
instantiation (compile or link time, depending on the implementation),
and possibly take additional steps to ensure that it is your
instantiation that gets used.

|>  Most modern compilers have tons of options to control optimization, code
|>  generation, and allocation of resources.  If I don't know *when* something
|>  is going to be compiled, I can't specify *how* it should be compiled.

This is inherent in automatic instantiation, I think.  With strict link
time instantiation, a la CFront, you knew when the instantiation took
place, but in that case, all templates were instantiated from the same
command line, so you couldn't have different options for different
templates.

The only way I can think of to do this with most compilers (which use
compile time instantiation) is to:

1. Hide the template sources when compiling the code.

2. Unhide them, and explicitly instantiate the templates in question.

3. Link.

(The hiding/unhiding part can be as simple as using/not using a -I
option.)

|>  > In real life, you need to recompile program parts because of errors
|>  > or changes in the source code. If the changes do not invalidate an
|>  > instantiation previously generated (and the compiler has to be a
|>  > bit pessimistic about invalidation),
|>
|>  A problem here is how to teach the compiler about my source control or
|>  configuration management system.  The compiler might use a totally
|>  inappropriate way of figuring out whether something has "changed" in order
|>  to test for validity if I am using a source control system.  As a simple
|>  example, suppose I am on a Unix system, and the compiler uses "stat" to
|>  tell if a file has changed.  Some source management systems use symbolic
|>  links to a "file cache" to set up a virtual environment reflecting a
|>  particular configuration of the source.  A "stat" system call will return
|>  the modification time of the target file, not the symbolic link to that
|>  file.  But it is the link's modification time that is important in many
|>  cases, so the compiler will think the file is not out-of-date when, in
|>  fact, it is.

Again, this is a general problem, not limited to templates.  I've had
make fail to recompile something essential because of this more than
once.  On the other hand, I suspect that the system in question is
ClearCase, and you are using ClearMake, which "knows" about such
things.  In which case, if the compiler really does use something as
simplistic as "modified more recently than", you have a potential
problem.  In practice, "modified more recently than" is never adequate;
even with the classical make, you usually had to make sure you touch'ed
all of you sources anytime you "stepped back" to an older version of the
include file.

A better solution might be for the compiler to note that
actual date used in building the cache, and invalidate it if the actual
date is different.  It is still probabilistic, however; the last
modified dates of two different versions can coincide, even if it is
highly unlikely.  Similarly, the compiler could save a hash code of the
files included, and rapidly recalculate the hash of the currently
visible versions.  Any difference, and it invalidates the cache.  Again,
however, this is only a Stochastic solution; it will probably generally
work in practice, provided the hash code has enough bits, but it isn't
what I would call satifying.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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
]

> One of the problems I have with this scheme is this: How do I control
> the set of options used by the compiler to compile instantiations at
> link time?  At compile time, I supply options to control things like
> optimization, definition of macros, include-file paths, and so on.
> I do NOT generally supply those options at link time.
>
> Even if I did supply those options, there's still the question of what
> options to use.  I can't tell which source(s) the "linker" is going to
> attempt to compile, so how do I know what options to specify?  Suppose,
for
> instance, that I want a particular template to be compiled with a special
> optimization -- how do I communicate that to the compiler at link time?
>
> Most modern compilers have tons of options to control optimization, code
> generation, and allocation of resources.  If I don't know *when*
something
> is going to be compiled, I can't specify *how* it should be compiled.

Store those compiler options in the .OBJ file along with the parsed
templates.
---
[ 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 9c8@fs7.ece.cmu.edu, dacut@henry.ece.cmu.edu (David A. Cuthbert) writes:
>James Kanze  <james-albert.kanze@vx.cit.alcatel.fr> wrote:
>>Stephen.Clamage@eng.sun.com writes:
>>|>  If your compiler requires that template sources always be included at
>>|>  compile time, that would be the exception rather than the rule. The
>>|>  draft standard makes no such requirement. Indeed, there has never been
>>|>  such a language rule.
>>
>>Thank you, Steve.  This is what I have been saying for a long time
>>(i.e.: that compilers which required explicit inclusion of template
>>implementation sources were broken according to the existing rules).
>
>Out of curiosity, how does a compiler which does not require the
>inclusion of the template code know which templates to generate?
>Using a specific compiler as an example, Borland 4.52 will happily
>*compile* my code, but there will be a link-time error since some
>template code will be missing.

I don't know what the Borland compiler does, but I can tell you how
the Sun compiler works. Let's assume you have a new program using
templates which has never been compiled before. (And let's pretend
there are no errors in the code, ho ho ho.)

When a template needs to be instantiated, the compiler makes a note
of it. At the end of the compilation it generates all needed
instantiations for which source code has been seen. These in turn might
require generation of still more template instantiations, and they are
added to the list, extending the generation process.

As each template instantiation is generated, it is added to the
template data base (which used to be called a "repository"). Before
generating a template instantiation, the compiler checks the data
base to see whether a current version already exists -- "current"
meaning not invalidated by changes to any file the instantiation
depends on. (The data base includes dependency data.)

If template instantiations are needed for which source code has not
been seen, they are not generated at this time. ("This time" is the
actual compile process of what started out as a single compilation
unit. We haven't got to link time yet.) The object file will contain
references to these needed templates.

Eventually you link the complete program. The "link" process is actually
a multi-step process which calls the actual linker as the last step.
A special program scans all the object files presented for linking
looking for needed template instantiations. Any current instantiations
found in the template data base are automatically added to the list
of files to be linked. Any missing instantiations are noted, and the
template source code is compiled to create the instantiations. Those
instantiations are added to the template data base and to the list of
files to be linked. This process is repeated until no more
instantiations are needed. The complete program is then linked.

In real life, you need to recompile program parts because of errors
or changes in the source code. If the changes do not invalidate an
instantiation previously generated (and the compiler has to be a
bit pessimistic about invalidation), that instantiation is just
picked up from the data base. If you are not changing the template
code, but just code that uses the templates, the previous instantiations
are not invalidated, and compilation and linking goes very fast -- only
the changed code is recompiled, and linking can take place directly.

The compiler uses some heuristics about where to find template source
code based on header file names and locations. If you choose to use
conforming file names and locations, you don't have to do anything
else. Otherwise, you can supply directives to the compiler about where
to find the source code. Similarly, you can specify the location and
use of template data bases.

If you choose to use the "include everything" model of source code,
all needed templates will have been instantiated by the time you
get to the link phase. If you choose to use the "separate compilation"
model, the first time you link the program a lot of time will be
spent generating instantiations. Either way, if you don't change
template code the subsequent links don't need to re-generate
instantiations.

---
Steve Clamage, stephen.clamage@eng.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         ]
[ 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                             ]