[cfe-dev] problem with std::function and virtual destructor

[Steve Ramsey]

On Jul 15, 2012, at 4:12 PM, Richard Smith wrote:
> On Sun, Jul 15, 2012 at 2:11 PM, Steve Ramsey <clang at lucena.com> wrote:
>> On Jul 15, 2012, at 1:55 PM, Rich E wrote:
>> > On Sun, Jul 15, 2012 at 1:38 PM, Steve Ramsey <clang at lucena.com> wrote:
>> >> This is correct behavior as per FDIS 12.8.18. Specifically, since there's a user-declared copy constructor, there needs to be a user-declared copy-assignment operator, if you want one; otherwise, the implicitly declared one is defined as deleted.
>> >>
>> > Excuse my ignorance, but how is there a user-declared copy constructor?
>> 
>> Excuse my lack of proofreading; I meant user-declared destructor.
>> 
> That's still not right: the rule you're referencing only applies to move operations. The implicit declaration of non-deleted copy operations still happens in this case, but it's deprecated (the committee didn't want to break a big pile of existing code, IIUC).

So the bug then is that the deprecated behavior has been prematurely removed? I suppose that would be technically correct - and technically correct is the best kind of correct. However, if you simply remove the virtual keyword from the destructor in the original example, it compiles, which clearly indicates I was simply off-base. So, let's dig a bit deeper...

The unusual characteristics of this struct include the virtual destructor and the std::function data member. std::function has explicit definitions for all 6 special member functions, which is interesting. Also, the libc++ implementation makes use of a union data member which also happens to include an array variant. That's an awful lot of special case fodder, and it's going to take me a while to look through the FDIS to find out if we're seeing unexpected behavior.

Still, the workaround I described earlier works: include an explicitly defaulted copy-assignment operator. I'll get back to the list if I figure out why.

			Steve