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

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


[quoted text, click to view]

Perhaps, this might useful :

http://beta.blogs.msdn.com/nikolad/archive/2005/06/15/429652.aspx

--
Regards,
Nish [VC++ MVP]


[quoted text, click to view]

[quoted text, click to view]

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.

[quoted text, click to view]
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++.

[quoted text, click to view]
- It's not standard
- It's type-safe, template based, only since a recent version of MFC.

[quoted text, click to view]
- 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

For newbies like me:

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

Ralph

[quoted text, click to view]


[quoted text, click to view]

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

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

[quoted text, click to view]

Hi David,

[quoted text, click to view]

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.

[quoted text, click to view]

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).

[quoted text, click to view]

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

[quoted text, click to view]

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

Hi RalphTheExpert!

[quoted text, click to view]

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

--
Greetings
Jochen

My blog about Win32 and .NET