Re: MSVC being stupid (again)?
On 07.03.2018 08:39, Bjoern Michaelsen wrote: Im going slightly mad over: https://gerrit.libreoffice.org/#/c/49565/ it: - 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 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 member) being SW_DLLPUBLIC, I assume that MSVC wants to instantiate some std::list 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 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. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: MSVC being stupid (again)?
Hi, On Wed, Mar 07, 2018 at 10:48:13AM +0200, Noel Grandin wrote: > more than likely the same thing bug I encounter with std::unique_ptr where > it is trying to instantiate something it should not be instantiating > > git grep 'MSVC2015 workaround' > > you have to delete the copy constructor and assignment operator to make it > happy. Thanks for the hint, I was really giddy to try this as I had deleted the copy ctor but not yet operator= everywhere. Unfortunately no dice so far, MSVC keeps resisting. Ill try to pinpoint down MSVC stupidity some more then. :/ Best, Bjoern ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: MSVC being stupid (again)?
On 2018/03/07 9:39 AM, Bjoern Michaelsen wrote: Im going slightly mad over: https://gerrit.libreoffice.org/#/c/49565/ more than likely the same thing bug I encounter with std::unique_ptr where it is trying to instantiate something it should not be instantiating git grep 'MSVC2015 workaround' you have to delete the copy constructor and assignment operator to make it happy. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
MSVC being stupid (again)?
Hi, Im going slightly mad over: https://gerrit.libreoffice.org/#/c/49565/ it: - 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 compile just fine My gut feeling is that window precompiled headers are hitting a broken corner case here. Anyone having any hints? Best, Bjoern ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
