CArray vs. std::vector

[laserlight]

There were TWO questions in the original post; which one are you answering?

By the way, the original post was made in 2006. emailus resurrected this thread.

[VladimirF]

By the way, the original post was made in 2006. emailus resurrected this thread.

Oops...
Anyway, it still appears to be a hot topic

[Philip Nicoletti]

Some points:

1) std::vector works fine in MFC codes

2) std::vector does not have "to construct their ctors at least twice"
(maybe the poster was trying to say something about when re-allocation
occurs ... but CArray needs to do re-allocation also)

3) vector has a richer array of public functions (pun intended). Also,
it works better with the <algorithm>

4) a vector has at least as good of performance as CArray ... and in
some cases much faster. The usual situation is when you are reading
data from a file and adding to the container (and you do not know
the number of data elements in the file). Below is code to simulate
this ...

struct A
{
	int x,y;
};


const int n = 1000000;

vector<A> v;

A a;

for (int i=0; i<n; ++i)
{
   v.push_back(a);
}

[ovidiucucu]

"STL much faster than MFC" is just a legend.
Possible, that was true long time ago.

I have made some benchmarks for CStringArray vs. std::vector<CString> and the performance differences were small. For example, filling time resulted almost equal while sorting, a little bit faster for CStringArray (attached here is a screenshot as well as the VS2005 solution).

At least, if use a modern compiler and run under a modern computer, does not make sense anymore to mix STL in an MFC application for performance reasons.
On the other hand, as I already said many times before, mixing different libraries in a project makes the code harder to understand and maintain.

So again: DO NOT use STL in an MFC project if it's not absolutelly necessary.

[nuzzle]

So again: DO NOT use STL in an MFC project if it's not absolutelly necessary.

I'd recommend the opposite. Prefer standard C++. Always use as much standard C++ as possible.

In an MFC project try to isolate MFC as much as possible. Try to make as big a part as possible free from MFC.

If you write in C++ let C++ rule, not some 3'rd party package.

[ovidiucucu]

In an MFC project try to isolate MFC as much as possible.

Well then, what about "In an STL project try to isolate STL as much as possible"...

[JohnW@Wessex]

I'd recommend the opposite. Prefer standard C++. Always use as much standard C++ as possible.

I've created a lot of customised MFC components and their interfaces are, as far as possible, STL, as the generic (and possibly cross platform) libraries are all STL based.

[nuzzle]

Well then, what about "In an STL project try to isolate STL as much as possible"...

Don't get confused by naming.

An MFC project is the Microsoft teminology for any C++ program which makes use of the MFC.

In reality it's a C++ project based on the MFC application framework. It's easy to get goobled up by the framework. It's the same if you use Qt.

Regardless of whether you're using MFC or Qt my advice is the same. Prefer standard C++ whenever possible. Don't allow the framework to take over your program. You're the captain. Fight mutiny with standard C++ or you'll lose the ship.

[ovidiucucu]

Now serious.
A little bit better saying is:
If for some reasons you are using STL in an MFC-based project, then put STL and MFC stuff in separate modules.

[nuzzle]

Now serious.
A little bit better saying is:
If for some reasons you are using STL in an MFC-based project, then put STL and MFC stuff in separate modules.

No, you should use STL and the rest of the C++ standard library freely in your program.

It's MFC that should be but used as little as possible and be isolated in separate modules.

[ovidiucucu]

Don't get confused by naming.

An MFC project is the Microsoft teminology for any C++ program which makes use of the MFC.

In reality it's a C++ project based on the MFC application framework. It's easy to get goobled up by the framework. It's the same if you use Qt.

Regardless of whether you're using MFC or Qt my advice is the same. Prefer standard C++ whenever possible. Don't allow the framework to take over your program. You're the captain. Fight mutiny with standard C++ or you'll lose the ship.

Looks like thoughts from someone with no or with not too much experience in software industry.
In reality, even you are a little programming genius, you'll get nothing trying to reinvent the wheel instead of using some already made stuff in a framework.
In contrary, your managers will complain for delayed deadlines, your colleagues will swear you for hard to understand and buggy code, and so on.

This is the real reality, Captain!

[JohnW@Wessex]

, you'll get nothing trying to reinvent the wheel instead of using some already made stuff in a framework.

Who's talking about re-inventing the wheel? The STL is 'already made stuff in a framework'.

[ovidiucucu]

The STL is 'already made stuff in a framework'.

Well, then we can say also "The CRT is 'already made stuff in a framework'".
Come on! Can we seriously talk about "frameworks"?

[nuzzle]

Looks like thoughts from someone with no or with not too much experience in software industry.
In reality, even you are a little programming genius, you'll get nothing trying to reinvent the wheel instead of using some already made stuff in a framework.
In contrary, your managers will complain for delayed deadlines, your colleagues will swear you for hard to understand and buggy code, and so on.

This is the real reality, Captain!

Using an application framework is a strategic decision because once you've made your choise you're effectively stuck. But regardless of whether you're stuck with MFC or Qt or something else there's still plenty of room to decrease the coupling induced by the framework. One way is to prefer standard C++ over the framework and another is to isolate the framework as much as possible, like I suggested.

So it's not a question of reinventing the wheel. It's a question of preferring standard C++ whenever this is a reasonable option.

[JohnW@Wessex]

I still don't understand what you meant by 're-inventing the wheel'
Nobody said anything about doing that
The comment was that, if you have the choice between using MFC or STL, then STL was the better option.