This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: STL and explicit template instantiation
On Thu, 2006-09-28 at 19:10 +0200, Paolo Carlini wrote:
> Benjamin Kosnik wrote:
>
> >>Now of course the follow on question since I poked at this some more.
> >>Why would the
> >>
> >>__uninitialized_fill_n_aux
> >>__uninitialized_fill_n_a
> >>
> >>template function not be inlined when all other template functions in
> >>the stl_uninitialized.h header are inlined? Could this be considered as
> >>a bug? When I hack the header to inline these template functions the
> >>problem goes away, as expected based on your answer.
> >>
> >>
> >Perhaps. These functions look to be inlined inconsistently, at least at
> >first glance.
> >
> As far as I can see, only the overload of __uninitialized_fill_n_a
> taking std::allocator is so trivial to warrant very safe inlining (it
> just forwards to std::uninitialized_fill_n). I'm going to adjust that
> (barring objections).
>
> Note, however, that this change doesn't "fix" the issue debated here,
If I inline all 3 template function the link error does go away. I don't
know whether or not the compiler actually follows the directive and
inlines the code. However, providing the inline directive is sufficient
to get the template functions instantiated, which makes explicit
instantiation of the vector template work.
> which, contrary to the initial report in this thread, was *already*
> there pre-4.0 compiler + library (I tried 3.3.4 and 3.4.4).
The __uninitialized_fill_n_a template functions are not part of 3.3.5 on
a SUSE 9.3 system :
(-> gcc --version
gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) )
-> cat /usr/include/c++/3.3.5/bits/stl_uninitialized.h | grep
__uninitialized_fill_n_a
__uninitialized_fill_n_aux(_ForwardIter __first, _Size __n,
__uninitialized_fill_n_aux(_ForwardIter __first, _Size __n,
return __uninitialized_fill_n_aux(__first, __n, __x, _Is_POD());
In addition the vector template did not depend on any of these template
function in 3.3.5:
-> cat /usr/include/c++/3.3.5/bits/vector.tcc | grep
__uninitialized_fill
But in 4.1 and 4.0
-> cat /usr/include/c++/4.1.0/bits/vector.tcc | grep
__uninitialized_fill
std::__uninitialized_fill_n_a(this->_M_impl._M_finish,
std::__uninitialized_fill_n_a(this->_M_impl._M_finish,
std::__uninitialized_fill_n_a(__new_finish, __n, __x,
Therefore the problem did not exist in 3.3.5.
>
> Paolo.
--
Robert Schweikert <Robert.Schweikert@abaqus.com>
ABAQUS