Migrating VC 6 to VC 8

  • Thread starter Thread starter danip
  • Start date Start date
D

danip

Hi there,
I need to do the following:
1. Migrate a whole solution (with tens of projects) from VC 6.0 to VC
8.0. The project has a lot of MFC templates like CArray, and many error
are poping out, like: Error 1 error C2248: 'CObject::operator =' :
cannot access private member declared in class 'CObject' d:\program
files\microsoft visual studio 8\vc\atlmfc\include\afxtempl.h 272.
2. Also few libraries I would like to convert to managed code, in order
to use these infrastucture to our new .net development.
Any ideas from where to start ?

-- Dani
 
danip said:
Hi there,
I need to do the following:
1. Migrate a whole solution (with tens of projects) from VC 6.0 to VC
8.0. The project has a lot of MFC templates like CArray, and many error
are poping out, like: Error 1 error C2248: 'CObject::operator =' :
cannot access private member declared in class 'CObject' d:\program
files\microsoft visual studio 8\vc\atlmfc\include\afxtempl.h 272.
2. Also few libraries I would like to convert to managed code, in order
to use these infrastucture to our new .net development.
Any ideas from where to start ?

-- Dani
Click to expand...

Dani:

I personally do not like these MFC collection classes, and if you are
thinking of migrating to .NET you might consider replacing them by the
STL collection classes. That way, it should be relatively easy to
convert to STL.NET (if it is ever released!).

What are you putting in these CArray's? I would think that the objects
in the array must have a copy constructor and assignment operator, and
if the class is derived from CObject then you will need to write these
methods yourself, because the default ones won't work because CObject's
ones are private. Of course, this will happen with STL also.

David Wilkinson
 
Hi David,

Just curious. What do you not like about CArray. It's just a templated
class and it seems to work well for me. What makes the STL collection
classes more desirable (assuming one is already using MFC of course)?

Tom
 
Tom said:
Hi David,

Just curious. What do you not like about CArray. It's just a
templated class and it seems to work well for me.
Click to expand...
- It's not standard
- It's type-safe, template based, only since a recent version of MFC.
What makes the STL
collection classes more desirable (assuming one is already using MFC
of course)?
Click to expand...
- It's standard and portable.
- Complexity of various operations (insert, delete, sort, ...) is
guaranteed.
- The STL separates containers and algorithms operating on those containers
through the use of iterator models. This make the STL solution more modular.
- STL provide higher level operations ("remove all values from the array for
which such or such predicate is true"), and make it easier to write other
such high-level operations.
- Exception safety for all operations is clearly defined.

Arnaud
MVP - VC
 
Tom said:
Hi David,

Just curious. What do you not like about CArray. It's just a templated
class and it seems to work well for me. What makes the STL collection
classes more desirable (assuming one is already using MFC of course)?

Tom
Click to expand...
Tom:

In addition to what Arnaud said:

1. I have never really seen the point of the double template argument in
the MFC collection classes, and to this day I find it confusing. CArray
always returns elements by const or non-const reference to TYPE (as does
std::vector). ARG_TYPE is only used when inserting elements, so why
would one ever choose ARG_TYPE to be anything but const ARG& (same as
std::vector)? Maybe I am missing something...

2. CArray objects cannot be copied because they derive from CObject,
which has private copy constructor and assignment operator. To copy a
CArray, you must make a derived class and provide copy constructor and
assignment explicitly. std::vector does this automatically. Why does
CArray derive from CObject? I guess it's for serialization, but I'm not
interested in MFC binary serialization.

3. But the real biggie is what you say. Just because you use MFC for the
GUI, there's no reason to use it for everything. I often think MFC is
designed to encourage a style of programming that makes it maximally
difficult to port to other platforms. And I see much the same in .NET.
Personally I try to extract as much of the application as I can into a
"business layer" that is written entirely in ISO-C++.

David Wilkinson
 
David Wilkinson wrote:

1. I have never really seen the point of the double template argument in
the MFC collection classes, and to this day I find it confusing. CArray
always returns elements by const or non-const reference to TYPE (as does
std::vector). ARG_TYPE is only used when inserting elements, so why
would one ever choose ARG_TYPE to be anything but const ARG& (same as
std::vector)? Maybe I am missing something...
Click to expand...

Correction: I meant why would one ever choose ARG_TYPE to be anything
but const TYPE& ?

Interestingly, I see that ARG_TYPE is defaulted to const TYPE& in the
latest version of vc that I have (7.1). Even more interesting, I see
that various signatures for extracting elements from CArray have changed
over the years. I do not have VC6, but VC5 and VC7.1 are like this:

VC5:

class CArray : public CObject
{
TYPE GetAt(int nIndex) const;
TYPE& ElementAt(int nIndex);

TYPE operator[](int nIndex) const;
TYPE& operator[](int nIndex);
};

VC7.1:

template<class TYPE, class ARG_TYPE = const TYPE&>
class CArray : public CObject
{
const TYPE& GetAt(INT_PTR nIndex) const;
TYPE& GetAt(INT_PTR nIndex);

const TYPE& ElementAt(INT_PTR nIndex) const;
TYPE& ElementAt(INT_PTR nIndex);

const TYPE& operator[](INT_PTR nIndex) const;
TYPE& operator[](INT_PTR nIndex);
};

The VC7.1 version is essentially the same as std::vector in this
respect, except that ElementAt() now seems redundant. Even so, the
documentation for ElementAt still says

"Returns a temporary reference to the element pointer within the array."

which seems to ignore the fact that all the above methods now return a
reference that might be temporary. In fact the non-const version of
operator [] always did that also.

Note that none of the above, now or ever, return ARG_TYPE, or ARG_TYPE&,
although (googling through the newsgroups) it would appear that some
people believe that ARG_TYPE controls what is returned from the array as
well as how elements are inserted.

Another thing is that the recommendation was always to do

CArray<MyClass, MyClass&> myArray;

rather than const MyClass& as the second template argument. Doesn't this
unnecessarily preclude inserting a constant object into a CArray?

To be fair, the implementation (if not the documentation) in VC7 seems
improved in these respects, but I would be happier to see size_t in all
the arguments, rather than INT_PTR. Maybe size_t and INT_PTR are always
the same in both Win32 and Win64, but aren't they logically different?

And then there's ConstructElements() and DestructElements(), which I
never understood.

All in all, I don't think these MFC collection classes were very well
designed.

David Wilkinson
 
RalphTheExpert said:
For newbies like me:

Does VC 8.0 == .Net 2003 or 2005 or something else?

Ralph
Click to expand...

As far as Visual C++ is concerned:

VC5 = Visual Studio 97
VC6 = Visual Studio 6
VC7 = Visual Studio.NET 2002
VC7.1 = Visual Studio.NET 2003
VC8 = Visual Studio.NET 2005

David Wilkinson
 
I think they stopped calling it .Net (for Visual Studio) around version 7.1
because it was confusing people. You can do both .NET and native with the
current version (VC 8.0 is part of VS 2005).

Tom
 
Hi David,

Maybe I am missing something...
Click to expand...

Could be... I don't know. I've never had problem with the collection
classes in MFC, but I know they only did them initially since there was no
STL in VC++ in the beginning versions. Then, once they existed they had to
continue existing to support legacy.
2. CArray objects cannot be copied because they derive from CObject, which
has private copy constructor and assignment operator. To copy a CArray,
you must make a derived class and provide copy constructor and assignment
explicitly. std::vector does this automatically. Why does CArray derive
from CObject? I guess it's for serialization, but I'm not interested in
MFC binary serialization.
Click to expand...

I don't use serialization either. I used to, but I found it to be klutzy
and difficult to read from other programs so I mostly use standard file
formats now (like XML).
3. But the real biggie is what you say. Just because you use MFC for the
GUI, there's no reason to use it for everything. I often think MFC is
designed to encourage a style of programming that makes it maximally
difficult to port to other platforms. And I see much the same in .NET.
Personally I try to extract as much of the application as I can into a
"business layer" that is written entirely in ISO-C++.
Click to expand...

No doubt. I obviously use many non-MFC classes including some of STL.
However, there is still much of STL I have yet to learn. Like they used to
say, the nice thing about standards is there are so many to chose from.

Tom
 
Back
Top