Re: Errors when compiling a VC6 project in VC2005
fabioraciti wrote:
try to compile a project built using VC++6 in VC++ 2005 and got
following errors when trying to build the project after clearing out
all the other errors in *.CPP file:
error C2248: 'CObject::CObject': cannot access private member
declared in class 'CObject' file c:\programmi\microsoft visual
studio 8\vc\atlmfc\include\afx.h(553) : see declaration
of 'CObject::CObject'
CObject isn't copyable, so it is not suitable as element in a container. If
you derive a class from it or use it as a member, that class also isn't
suitable when you rely on the compiler-generated assignment operator and
copy constructor.
c:\programmi\microsoft visual studio 8\vc\atlmfc\include
\afx.h(524) : see declaration of 'CObject'
This diagnostic occurred in the compiler generated function
'CMap<KEY,ARG_KEY,VALUE,ARG_VALUE>::CMap(const
CMap<KEY,ARG_KEY,VALUE,ARG_VALUE> &)'
with
[
KEY=_HTREEITEM,
ARG_KEY=_HTREEITEM,
VALUE=int,
ARG_VALUE=int &
]
where _HTREEITEM is
#include <commctrl.h>
extern "C" struct _TREEITEM{};
typedef struct __TREEITEM :public _TREEITEM
{
public:
long vuoto;//non serve a nulla
private:
public:
__TREEITEM (){vuoto=0;}
virtual ~__TREEITEM (){vuoto=0;}
public: __TREEITEM (const __TREEITEM& c){vuoto=c.vuoto;}
}_STREEITEM,*_HTREEITEM;
This is a very bad idea for several reasons:
1. You are not allowed to use identifiers like _HTREEITEM or _STREEITEM.
Further, they look like macros because they are ALL_UPPERCASE. Lastly,
there is no need in C++ to use the 'typedef struct {...} blah;' that C
requires. Oh, btw, structs derive publicly by default, just as their
default access is public, as you surely know. All this won't cause errors
probably, but you should nonetheless clean up your code before posting here
so people don't have to search for the relevant parts.
2. There already are typedefs/macros called HTREEITEM in the win32 API, your
typedef is likely to conflict with that. Further, you seem to be deriving
from _TREEITEM which you're again not supposed to use, it is private to the
implementation.
3. Have you considered all possible cases of slicing when the derived is
converted to a baseclass? Also, why the virtual dtor? Unless that is also
present in the baseclass (I doubt it) it won't give you anything. In
particular, you don't seem to override/provide any virtual functions
either.
Anyway, what are you doing here? If you have a tree view/control, those
already have a pointer-sized integer that you can use to attach arbitrary
data to it.
If you can determine that all this is not the case, please provide a minimal
example someone could feed to the compiler to reproduce the problem.
Uli