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

[Richard Smith]

On Fri, Feb 13, 2015 at 8:43 PM, Edward Diener <
eldlistmailingz at tropicsoft.com> wrote:

> On 2/13/2015 11:17 PM, Nico Weber wrote:
>
>> Hans would know for sure, but I think this is intentional: Since AClass
>> is dllexported, all its implicit functions get generated (so that they
>> can be exported from the dll), which means they need to be semantically
>> checked. If you give the class a deleted copy constructor and assignment
>> operator, it might work.
>>
>
> Where in the C++ standard is such behavior justified ?
>

You're using a non-standard feature (dllexport); the C++ standard's
guarantees are not relevant.

The C++ standard does tell us I believe that if an object of a class is not
> copied there is never a need to specify a copy constructor and if a class
> is not assigned there is never a need to specify an assignment operator,
> whether or not one has a non-copyable or non-assignable member or not.
> Changing that basic rule to support something in clang related to
> "exported' classes cannot be correct IMO.
>
> Why does '__attribute__((__visibility__("default")))' work but
> '__attribute__((dllexport))' does not ? Aren't they both the equivalent of
> "exporting" a class in clang ?
>
> I realize that for clang on Windows targeting mingw/gcc and not VC++ that
> the correct "export" attribute is probably '__attribute__((__visibility__("default")))'
> and not '__attribute__((dllexport))'. But I heavily object to the idea that
> because I might be exporting a class the rules of copyability or
> assignability for that class must change contrary to the C++ standard. This
> also puts an extra conceptual burden on the design of a class.


If our behavior doesn't match mingw here, that's probably a bug. IIRC, MS
__declspec(dllexport) has the behavior of triggering the defintiions of all
implicit special member functions, but it's possible that
__attribute__((dllexport)) should not do the same thing.


> On Fri, Feb 13, 2015 at 8:07 PM, Edward Diener
>> <eldlistmailingz at tropicsoft.com
>> <mailto:eldlistmailingz at tropicsoft.com>> wrote:
>>
>>     I am compiling code with "-c -x c++ -O0 -g -fno-inline -Wall -g"
>>     using clang targeting mingw/gcc on Windows.
>>
>>     This code compiles with no errors ( boost::scoped_ptr<T> is
>>     non-copyable, non-assignable ):
>>
>>     #include <boost/scoped_ptr.hpp>
>>     class
>>     AClass { boost::scoped_ptr<int> sp_pointer; };
>>     int main()  {  return 0;  }
>>
>>     This code compiles with no errors:
>>
>>     #include <boost/scoped_ptr.hpp>
>>     class __attribute__((__visibility__(__"default")))
>>     AClass { boost::scoped_ptr<int> sp_pointer; };
>>     int main()  {  return 0;  }
>>
>>     but this code compiles with errors:
>>
>>     #include <boost/scoped_ptr.hpp>
>>     class __attribute__((dllexport))
>>     AClass { boost::scoped_ptr<int> sp_pointer; };
>>     int main()  {  return 0;  }
>>
>>         test_clang_bug.cpp:3:1: error: field of type
>>         'boost::scoped_ptr<int>' has private copy constructor
>>         AClass { boost::scoped_ptr<int> sp_pointer; };
>>         ^
>>         ..\..\..\boost/smart_ptr/__scoped_ptr.hpp:47:5: note: declared
>>         private here
>>              scoped_ptr(scoped_ptr const &);
>>              ^
>>         test_clang_bug.cpp:3:1: note: implicit copy constructor for
>>         'AClass' first required here
>>         AClass { boost::scoped_ptr<int> sp_pointer; };
>>         ^
>>         test_clang_bug.cpp:3:1: error: 'operator=' is a private member
>>         of 'boost::scoped_ptr<int>'
>>         AClass { boost::scoped_ptr<int> sp_pointer; };
>>         ^
>>         ..\..\..\boost/smart_ptr/__scoped_ptr.hpp:48:18: note: declared
>>         private here
>>              scoped_ptr & operator=(scoped_ptr const &);
>>                           ^
>>         test_clang_bug.cpp:3:1: note: implicit copy assignment operator
>>         for 'AClass' first required here
>>         AClass { boost::scoped_ptr<int> sp_pointer; };
>>         ^
>>         2 errors generated.
>>
>>
>>     Comments ?
>>
>>     Should I file a bug report ?
>>
>>     I do not see why, even "exporting" a class, clang should give an
>>     error. If I am not copying/assigning an instance of a class I should
>>     never get a compiler error telling me that some member is not
>>     copyable or assignable.
>>
>>     _________________________________________________
>>     cfe-dev mailing list
>>     cfe-dev at cs.uiuc.edu
>>     <mailto:cfe-dev at cs.uiuc.edu>
>>     http://lists.cs.uiuc.edu/__mailman/listinfo/cfe-dev
>>     <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
>>
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150213/794fcbeb/attachment.html>