This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Explicit instantiation and static objects in different modules
- From: Nikolay Vorobyov <nik dot vorobyov at gmail dot com>
- To: Alexander Monakov <amonakov at ispras dot ru>
- Cc: Jonathan Wakely <jwakely dot gcc at gmail dot com>, gcc-help <gcc-help at gcc dot gnu dot org>
- Date: Wed, 5 Aug 2015 20:22:30 +0300
- Subject: Re: Explicit instantiation and static objects in different modules
- Authentication-results: sourceware.org; auth=none
- References: <63FDE6C4-EFC2-44DD-991E-0BE895586162 at gmail dot com> <CAH6eHdRy3NWN1xC9DfHx0UKmAQByGHtJfiWTYdssfqa-75NLGw at mail dot gmail dot com> <alpine dot LNX dot 2 dot 20 dot 1508041934440 dot 28968 at monopod dot intra dot ispras dot ru> <CAH6eHdR4sp2TCPHHu7Bn+XD-0O0YZSVQ2QHtBKDcA+wPskSYaQ at mail dot gmail dot com> <alpine dot LNX dot 2 dot 20 dot 1508042026530 dot 28968 at monopod dot intra dot ispras dot ru>
On Aug 4, 2015, at 20:32, Alexander Monakov <amonakov@ispras.ru> wrote:
> On Tue, 4 Aug 2015, Jonathan Wakely wrote:
>> The extern template tells the compiler it doesn't *need* to
>> instantiate the template, because it will be explicitly instantiated
>> in another translation unit. But that doesn't mean it *must not*
>> instantiate it. The compiler can choose to inline the function and in
>> that case it will implicitly instantiate it. That should be
>> unobservable because the One Definition Rule means that the implicitly
>> instantiated definition that gets inlined and the explicitly
>> instantiation definition in the other translation unit must be
>> identical. The Windows linkage model seems to break that assumption
>> ... so I don't know what the right behaviour is.
>
> In light of that, perhaps it's best to structure code in a way that prevents
> implementation of a singleton from being visible in translation units that can
> be linked into different libraries.
Thanks for pointing this out. I’ll use __attribute__ (noinline) for functions with static variables.