[cfe-dev] Interesting clang behavior/bug? on Windows

[Reid Kleckner]

On Sat, Feb 14, 2015 at 4:08 PM, Edward Diener <
eldlistmailingz at tropicsoft.com> wrote:

> On 2/14/2015 5:48 PM, Reid Kleckner wrote:
>
>> There might be a Clang bug here, depending on whether the copy ctor is
>> supposed to be implicitly deleted or not. I forget if having a base
>> class with a private copy ctor implicitly deletes derived class copy
>> ctors or not.
>>
>
> The second sentence above is not the case in my example, since there is no
> base class involved. I also did not compile in C++11 mode in my example
> AFAICS. Don't I need a command-line switch of -std=c++11 for that ?


True, I misspoke, but it doesn't change my question: should the copy ctor
be implicitly deleted due to a member with a private copy ctor? I've
forgotten.


>> Clang's class dllexport semantics are modeled on MSVC's because they
>> make more sense than GCC's for PE/COFF. As Nico said, the idea is that
>> we emit all these special members (and inline functions!) so that
>> clients can dllimport them and not have to emit definitions. This is an
>> intentional semantic difference from ELF's visibility model, which has a
>> different mechanism for ensuring that the addresses of inline functions
>> are the same across DSO boundaries.
>>
>> If you can find a way to delete, explicitly or implicitly, the unwanted
>> copy ctor, then Clang should skip it while exporting the rest. If not,
>> that's a bug.
>>
>
> Let me start by saying that both mingw/mingw64/gcc on Windows and VC++
> compiles the example I gave without error using their respective Windows
> export keywords. Clang as I have shown does not.
>

Yup. Ultimately, it's not possible to stamp out all inconsistencies between
compilers. We have to focus on the important ones.


> Whether or not clang generates an implicit copy constructor /
> copy-assignment operator when the user does not have one seems to me to be
> an irrelevant issue. If objects of the class are never copied/assigned why
> should clang generate an error ? This is regardless of whether the class is
> exported or not. I have a class that cannot be copied/assigned so naturally
> I see no need to create a user-defined copy constructor or copy-assignment
> operator. How can I be wrong not doing so ? Even when I export the class I
> am still telling users of the class that import it that it cannot be copied
> or assigned. That seems pretty clearcut to me. Clang now wants to tell me
> that if I export the class I must change how I code the class as to provide
> a user-defined copy constructor/assignment operator ( or a private
> declaration/deleted function depending on C++03/C++11 ) to satisfy clang ?
> That is not logically right from this end-user's point of view. I am also
> pretty sure that in C++03 if a class is not copyable I am not required to
> provide a user-defined copy constructor or private copy constructor
> declaration when defining the class.


> Even in a C++11 compilation is it actually a C++ standard error if the
> programmer does not provide deleted versions of the copy constructor /
> assignment operator when objects of that class cannot be copied / assigned
> using the default generated copy constructor / assignment operator ? I do
> not think so. According to my reading of the C++11 standard as interpreted
> by Lippman in C++ Fifth Edition,
>
> "The synthesized copy constructor is defined as deleted if the class has a
> member whose own copy constructor is deleted or inaccesible..."
>
> "The synthesized copy-assignment operator is defined as deleted if a
> member has a deleted or inaccessible copy-assignment operator..."
>
> I realized I am not quoting from the C++11 standard but unless Lippman is
> in error here I cannot see other than that clang is in error in the case I
> have presented.
>
> I don't mind filing a bug report on this but I want to get some agreement
> here that clang is not doing the right thing even in the face of an
> "export" of the class. The job of defining an implicit copy constructor and
> copy-assignment operator is that of the compiler and if clang wants to
> claim that in the face of the "export" keyword it is not required to follow
> the standard C++ rules of how thiws should be done, I do not want to follow
> up with such a bug report.
>

This seems like something worth filing a bug about. I guess even if the
copy ctor isn't technically deleted (probably because we're in C++98), it'd
be nice to avoid requiring it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150214/6acb30f8/attachment.html>