STL and explicit template instantiation

[Robert Schweikert <Robert dot Schweikert at abaqus dot com>]

I may be hitting a Grey area with this and am not sure what is supposed
to happen.

It is my understanding that explicit instantiation is supposed to work,
but I am not sure what is supposed to happen with dependents. Here is
the test case/example

#include <string>
#include <vector>


template class std::vector<std::string>;

int main()
{
    return 0;
}

Explicit instantiation of the vector with a string (or any type) results
in link errors as the vector template depends on the
std::__uninitialized_a_n template function declared in
stl_uninitialized.h.

The problem now is that as a user I know nothing about
std::__uninitialized_a_n thus I cannot explicitly instantiate it.
However, I did tell the compiler that I want explicit instantiation
(-fno-implicit-templates).

Is the compiler now supposed to figure out that explicit instantiation
is on but when a template is instantiated explicitly and it uses other
templates the dependent templates need to instantiated automatically?

Or maybe the compiler should always use automatic instantiation when a
template in the STL is used?

Should there be some #ifdef in the vector template that adds an explicit
instantiator?

#ifdef __EXPLICIT_INSTANTIATION
template ......;
#endif

This would mean the compiler would have to set the
__EXPLICIT_INSTANTIATION macro, or whatever it might be called when
-fno-implicit-templates is set on the command line.

The above example demonstrates the dilemma.

g++ -fno-implicit-templates vectTest.C

In previous versions vector did not depend on, nor did the
__uninitialized template function exist. The next question then is how
can I differentiate the version of the STL I get when compiling the code
on a machine with STL provided with gcc 4.0 and above versus earlier
versions. In the first case I would insert the explicit instantiation
for __uninitialized_a_n, while in the latter case I would skip the
instantiation.

Help is much appreciated.

Thanks,
Robert
-- 
Robert Schweikert <Robert.Schweikert@abaqus.com>
ABAQUS