tags:

views:

61

answers:

2

Apart from method calls not being optimized, are there any other issues?

A difference I have noticed is that default compiler generated methods (e.g. operator=) in the class appear either in the exporting dll (if dllimport is used by the client) or in the client binary (if dllimport is not used). In this latter case, it's almost as if part of the class is defined in the dll, and part in the client's binary. Are there any issues with this?

+1  A: 

I'm assuming that in both cases the class implementation resides in a DLL, is that correct?

The main issue that I can see with this scenario is that if the compiler-generated assignment operator allocates any memory, even indirectly by calling other copy constructors or assignment operators, the memory would potentially be allocated in the "wrong" heap (the client's heap instead of the DLL's heap, which is where they would be allocated if the assignment operator resided in the DLL). This can lead to memory leak and the occasional hard to debug problem.

That said, if your objects are "trivial enough" that you don't really need to write your own copy constructors and assignment operators (and destructors - see the rule of three), you may well get away with this, especially if you're only throwing a couple of PODs around.

Timo Geusch
A: 

Many thanks. Yes, the class implementation is in the DLL.