MSVC being stupid (again)?
sbergman at redhat.com
Thu Mar 8 10:18:58 UTC 2018
On 07.03.2018 08:39, Bjoern Michaelsen wrote:
> Im going slightly mad over:
> - uses a class which has a move ctor in a std container and a deleted copy
> ctor, which _should_ be fine
> - compiles fine on OSX and Linux gcc and Linux clang
> - it fails on MSVC with some bull&^(t errors that start off with "I tried to
> instanciate the deleted copy ctor" (which sounds almost reasonable) but ends
> with stuff including boost::args. which has ~nothing to do with the changes
> stl stuff involved and sound like it really took a wrong turn at some place
> - copying and renaming the involved clasess to uwriter seems to make the
> std::list<SwDepend2> compile just fine
> My gut feeling is that window precompiled headers are hitting a broken corner
> case here. Anyone having any hints?
What I note is that SwDepend has a move ctor but no move assignment op.
Both SwDepend and WriterMultiListener (containing a std::list<SwDepend>
member) being SW_DLLPUBLIC, I assume that MSVC wants to instantiate some
std::list<SwDepend> inline member function that requires SwDepend to be
MoveAssignable. Even if that function would never be used (and thus
Clang/GCC not instantiating it for non-MSVC ABIs, and not running into
an issue), MSVC would still want to do that when those SW_DLLPUBLIC
expand to __declspec(dllexport).
(Or maybe it's even trying to instantiate a std::list<SwDepend> member
function that requires SwDepend to indeed be CopyConstructible. But,
without looking deeper now, I would suspect that would be a bug in
MSVC's standard library.)
Not sure if this could be fixed by making select (implicit) member
functions of SwDepend and/or WriterMultiListener non-inline and moving
their definitions out into a .cxx.
More information about the LibreOffice