Re: duplicate instantiations

[Jaroslav Hajek]

On Tue, Jun 2, 2009 at 2:16 PM, Michael Goffioul
<address@hidden> wrote:
> On Tue, Jun 2, 2009 at 12:54 PM, Jaroslav Hajek <address@hidden> wrote:
>> hi Michael,
>>
>> I noticed that as part of 9237:3c1762c7e787, you added lines like
>> template class OCTAVE_API DiagArray2<Complex>::Proxy;
>>
>> to Array-*.cc. While this is accepted by GCC, it gets rejected by
>> Intel C++, griping about duplicate instantiation.
>> I've asked for advice on comp.lang.c++, but after a quick
>> investigation it seems to me that Intel is right here. An explicit
>> instantiation of a class instantiates all its non-template members,
>> including member classes, which causes a duplicate explicit
>> instantiation.
>> I assume the OCTAVE_API decoration does not automatically apply to
>> member classes? Is there a different way to do this with MSVC?
>> I'm not really much fond about the whole DiagArray2::Proxy stuff, but
>> I wouldn't like to remove it now. OTOH, I wouldn't like to keep code
>> needed only for MSVC (and fooling other commercial compilers) which is
>> actually incorrect C++.
>
> The problem here is indeed the OCTAVE_API decoration, which does
> not apply to member classes. So, even if MSVC instantiates all members
> on DiageArray2<xxx> statement, including member classes, those do not
> get exported, which is then a problem later on (undefined references).
>
> I remember that I had to explicitely instantiate (and decorate) ::Proxy
> classes, before the surrounding class, otherwise I also got a compilation
> error due to duplicate specialization.
>
> Unfortunately, at the moment I don't see any other solution.
>
> If that's a problem, feel free to remove the offending statements, and I'll
> maintain a patch MSVC just for myself.
>

OK, but I'll wait what people on comp.lang.c++ say. It's not a big
problem since GCC accepts it
(even in -pedantic -ansi, which probably deserves a bug report if I'm
right). I'll alert you if I am about to remove these declarations. I
was already beginning to think Intel C++ is just barking, but I just
tested the online Comeau C++ (on a hopefully equivalent test case),
which is reported to be very good at standard conformance diagnostics,
and it complains as well :(
I'll try to investigate it a bit more. It seems a correct workaround
would be to put a whole specialization (including the decorator) into
Array-*.cc, but that seems really ugly.

Another option is to simply make the instantiations conditional for
MSVC. This seems to me the most feasible approach for now.

regards

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz