Question

UPDATE the belowmentioned bug is fixed in VS2012, and noncopyable works as epected

This is both a question and a way to provide information / warn others so they don’t fall into the same trap as I did: it seems that using a noncopyable base class (like the one in boost) has no effect in exported classes when using the MS compiler. This is a known bug to MS but I doubt there are a lot of programmers that know of it. As one can imagine, this can produce extremely nasty bugs because it allows writing code that should not even compile. Example (code for noncopyable class here🙂

a typical header file in a dll project, compile with /D EXPORT_IT:

#ifdef EXPORT_IT
  #define mydll __declspec( dllexport )
#else
  #define mydll __declspec( dllimport )
#endif    

class mydll CantCopyMe : private noncopyable
{
public:
  CantCopyMe();
  ~CantCopyMe();
};

mydll CantCopyMe MakeIt();

the source file:

#include <iostream>

CantCopyMe::CantCopyMe()
{
  std::cout << "constructor" << std::endl;
}

CantCopyMe::~CantCopyMe()
{
  std::cout << "destructor" << std::endl;
}

CantCopyMe MakeIt()
{
  CantCopyMe x;
  return x; //oops... this sould not compile nor link but it does
}

the application:

int main()
{
  CantCopyMe x( MakeIt() );
}

the output:

constructor
destructor
destructor

1 constructor, 2 destructors called. Imagine the problems when the class effectively contains resources.

edit
usage cases that do compile but should not:

CantCopyMe MakeIt()
{
  CantCopyMe x;
  return x;
}

void DoIt( CantCopyMe x )
{
  x.Foo();
}

void SomeFun()
{
  CantCopyMe x;
  DoIt( x );
}

other cases:
CantCopyMe MakeIt()
{
return CantCopyMe(); //fatal error C1001
}

CantCopyMe GenerateIt()
{
  CantCopyMe x;
  return x;
}

CantCopyMe MakeIt()
{
  return GenerateIt(); //fatal error C1001
}

CantCopyMe MakeIt()
{
  CantCopyMe x;
  return CantCopyMe( x ); //fatal error C1001 + cl crashes
}

void DoSomething()
{
  CantCopyMe x;
  CantCopyMe y = x; //fatal error C1001 + cl crashes
}  

Questions:

1. The KB article mentions a fix in an upcoming release. Can anyone check if this is fixed in VS2010 already (or possibly with a Visual Studio 11 preview)?

2. Is there any workaround to trigger any kind of error? I tried (ab)using the fact that writing return CantCopyMe() triggers an internal compiler error but, I couldn’t find a way to conditionally trigger it only when compiling a function like MakeIt above. Putting static_assert in the noncopyable’s copy constructor also doesn’t cut it since the compiler will always compile it even if it doesn’t get invoked.

Answer 1

To answer 1 (for VS2010), I just tried it in VS2010 (with SP1) and it compiles just fine, which means it has not been fixed. Unfortunately I do not have 2011 to test

To 2. I guess one way to do it would be to:

• no longer derive from noncopyable
• declare the copy ctor and assignment operator as private in CantCopyMe without providing an implementation)

class CantCopyMe 
{
public:
   //omitted for brevity...
private:
    CantCopyMe( const CantCopyMe& );
    const CantCopyMe& operator=( const CantCopyMe& );
};

With this done you avoided the dangerous situations you describe and it should work with VS2008 also. And you solve the problem in the right place, that is in the non-copyable class declaration.