<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Feb 14, 2015 at 4:08 PM, Edward Diener <span dir="ltr"><<a href="mailto:eldlistmailingz@tropicsoft.com" target="_blank">eldlistmailingz@tropicsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 2/14/2015 5:48 PM, Reid Kleckner wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There might be a Clang bug here, depending on whether the copy ctor is<br>
supposed to be implicitly deleted or not. I forget if having a base<br>
class with a private copy ctor implicitly deletes derived class copy<br>
ctors or not.<br>
</blockquote>
<br></span>
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 ?</blockquote><div><br></div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Clang's class dllexport semantics are modeled on MSVC's because they<br>
make more sense than GCC's for PE/COFF. As Nico said, the idea is that<br>
we emit all these special members (and inline functions!) so that<br>
clients can dllimport them and not have to emit definitions. This is an<br>
intentional semantic difference from ELF's visibility model, which has a<br>
different mechanism for ensuring that the addresses of inline functions<br>
are the same across DSO boundaries.<br>
<br>
If you can find a way to delete, explicitly or implicitly, the unwanted<br>
copy ctor, then Clang should skip it while exporting the rest. If not,<br>
that's a bug.<br>
</blockquote>
<br></span>
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.<br></blockquote><div><br></div><div>Yup. Ultimately, it's not possible to stamp out all inconsistencies between compilers. We have to focus on the important ones.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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,<br>
<br>
"The synthesized copy constructor is defined as deleted if the class has a member whose own copy constructor is deleted or inaccesible..."<br>
<br>
"The synthesized copy-assignment operator is defined as deleted if a member has a deleted or inaccessible copy-assignment operator..."<br>
<br>
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.<br>
<br>
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.<br></blockquote></div><br></div><div class="gmail_extra">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.</div></div>