467,894 Members | 1,554 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,894 developers. It's quick & easy.

Migrating VC 6 to VC 8

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

Nov 28 '05 #1
  • viewed: 4778
Share:
11 Replies
Perhaps, this might useful :

http://beta.blogs.msdn.com/nikolad/a...15/429652.aspx

--
Regards,
Nish [VC++ MVP]
"danip" <da***@ecmed.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...
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

Nov 28 '05 #2
danip wrote:
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


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
Nov 28 '05 #3
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

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

Nov 28 '05 #4
Tom Serface wrote:
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. - 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)?

- 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
Nov 28 '05 #5
Tom Serface wrote:
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:

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
Nov 28 '05 #6
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...


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

Nov 29 '05 #7
For newbies like me:

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

Ralph

Nov 29 '05 #8
Hi RalphTheExpert!
Does VC 8.0 == .Net 2003 or 2005 or something else?


VC8 = VC2005
VC7.1 = VC2003
VC7 = VC2002
VC6 = VC98
VC5 = VC97

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Nov 29 '05 #9
RalphTheExpert wrote:
For newbies like me:

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

Ralph


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

Nov 29 '05 #10
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

"RalphTheExpert" <ra****@dos32.com> wrote in message
news:11*********************@g44g2000cwa.googlegro ups.com...
For newbies like me:

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

Ralph

Nov 29 '05 #11
Hi David,

"David Wilkinson" <no******@effisols.com> wrote in message
news:Of**************@TK2MSFTNGP15.phx.gbl...
Maybe I am missing something...
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.
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++.


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
Nov 29 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Zvika Glickman | last post: by
4 posts views Thread by Bernardo Robelo | last post: by
6 posts views Thread by Shai Levi | last post: by
3 posts views Thread by BobRoyAce | last post: by
2 posts views Thread by Jean-Claude Adams | last post: by
12 posts views Thread by jdokos | last post: by
34 posts views Thread by subramanian100in | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.