Home Dashboard Directory Help
Search

Private copy operator vs __declspec(dllexport) by HOMO_PROGRAMMATIS


Status: 

Closed
 as Fixed Help for as Fixed


1
0
Sign in
to vote
Type: Bug
ID: 624283
Opened: 11/24/2010 5:57:11 AM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

I observe various bugs when deriving from a dllexport'ed class with copying disabled.
Let's continue straight to a sample:

------------------------------------------------------------------------

class __declspec(dllexport) A
{
protected:
    A() {}

private:
    // Deny copying
    A(const A&);
    const A& operator = (const A&);
};

#define TESTCASE 0

#if (TESTCASE == 0)        // Success ?!
    class __declspec(dllexport) B : public A
    {
    };

    class C : public B
    {
    };
#elif (TESTCASE == 1)    // error LNK2019: unresolved external symbol "public: class C & __thiscall C::operator=(class C const &)" (??4C@@QAEAAV0@ABV0@@Z) referenced in function "void __cdecl Foo(void)" (?Foo@@YAXXZ)
    class __declspec(dllexport) C : public A
    {
    };
#elif (TESTCASE == 2)    // error C2248: 'A::operator =' : cannot access private member declared in class 'A'
    class C : public A
    {
    };
#endif

void Foo()
{
    C object1;
    C object2;
    object2 = object1;
}

------------------------------------------------------------------------

In testcase 2, things go as expected.
In testcase 0, the code is compiled without any errors or warnings, while it clearly should not.
In test case 1, the code is compiled, but not linked due to missing C::operator=(), which is not defined nor declared, and should not be used due to the base class restriction.
Details
Sign in to post a comment.
Posted by Microsoft on 11/25/2010 at 5:36 PM
Thanks for your feedback.
We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by HOMO_PROGRAMMATIS on 11/25/2010 at 1:15 AM
Edit: TESTCASE=2 shows the expected behavior, not 0
Posted by HOMO_PROGRAMMATIS on 11/25/2010 at 1:12 AM
Anyways, i hope you got it.

The file contains a fresh-generated project with the only modified file is PrivateCopyDllExport.cpp

Should you compile it as-is, you will get no errors or warning which is WRONG. You can also change the TESTCASE macro to 1 to see a different bug and to 0 to see the expected behavior.
Posted by HOMO_PROGRAMMATIS on 11/25/2010 at 1:10 AM
Not sure if i added anything, because although website tells file is attached, it does not display, and the form says 0 attachments
Posted by Microsoft on 11/24/2010 at 6:11 PM
Thank you for reporting this issue. Unfortunately, we are unable to reproduce the issue with the steps you provided.

Could you please provide us with a copy of you code file? A sample project zip should be more helpful.

It would be greatly appreciated if you could provide us this information as quickly as possible.

Thank you,
Posted by Microsoft on 11/24/2010 at 6:21 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
File Name Submitted By Submitted On File Size  
PrivateCopyDllExport.zip (restricted) 11/25/2010 -
PrivateCopyDllExport.zip 11/25/2010 6 KB