CArray vs. std::vector

Quote:

---

Originally Posted by nuzzle

It's a question of preferring standard C++ whenever this is a reasonable option.

---

Agree if underline reasonable.

1) "array size = 29979" ... try using array sizes that come up in many
scientific applications ... try an array size of 1,000,000 (or more)

2) It is not just the speed difference ... vector has a much richer array of
public interface functions and works better with <algorithm>

Quote:

---

Originally Posted by JohnW@Wessex

[...] if you have the choice between using MFC or STL, then STL was the better option.

---

It's seasy to say something is better but a little bit harder to prove that's true.
See: http://www.codeguru.com/forum/showpo...5&postcount=19

However, I have no intention to flame (in an non-MFC forum :)).
Just few opinions of an old programmer which dealt many years both with MFC and STL (and many other frameworks and libraries).
If you consider I'm not right, no problem. Your choice... ;)

Quote:

---

Originally Posted by ovidiucucu

It's seasy to say something is better but a little bit harder to prove that's true.

---

It's not so hard when the object is to try to make all generic and non-GUI code cross platform/ cross GUI framework agnostic. It means that a C++ coder coming to our company can work on our non-GUI code without having to have a good background in MFC, just standard C++.

Quote:

---

Originally Posted by Philip Nicoletti

1) "array size = 29979" ... try using array sizes that come up in many
scientific applications ... try an array size of 1,000,000 (or more)

---

No problem, can be done.
However, can you bet the results will be not the same? ;)

Quote:

---

Originally Posted by Philip Nicoletti

2) It is not just the speed difference ... vector has a much richer array of
public interface functions and works better with <algorithm>

---

Im the most of MFC applications using <algorithm> is not necessary.
I have joined in this discuttion in the point CStringArray vs. std::string<CString>.
As seen in the uploaded examples, sorting CStringArray with qsort is faster than sorting std::vector<CString> with std::sort.
No problem, you can also sort CStringArray with std::sort and the result will be somewhere between the two.

So, any gain using vector and algorithm?
As can be seen, none.

There are two bold sentences I have posted in this thread.

1. DO NOT use STL in an MFC project if it's not absolutelly necessary.
2. If for some reasons you are using STL in an MFC-based project, then put STL and MFC stuff in separate modules.

Not any "MFC rocks while STL sucks". Have somebody seen something like that? ;)
MFC is good, STL is wonderful but IMHO, putting them together, in the same source code, like using std::vector<CString> instead of CStringArray, is not so brilliant idea.
No problem, it can be done but that doesn't really mean we do a better job.

1) Well, you also said that mixing MFC and STL was a "headache".
That might have been true a long time agao (pre version 5), but
since version 5 (~1997 ?) there are no problems mixing the two.

2) The problem with the MFC containers is that they do no even have
a consistent interface for looping thru the elements. You have to loop
thru a CList in a different way than thru a CArray. This means you need
to write duplicate code for doing such simple tasks as finding if an
element is in the container, or finding the largest element.

3) how many times has something like this been seen on the other board ?

Code:

---

class A
{
  CArray< .... >;
  // other
};

class B
{
  CArray<A,...>
};

---

And they want to know whay it will not compile.

4) using qsort on a container of CString is technically undefined,
but since MS does it, I'll let it slide. But using qsort on other
non-POD elements still should not be done. Also, how are you
going to sort a CList ?

5) Here is a sample code ... feel free to publish your results
(also, not cheating by calling SetSize() or simuilar functions ....
remember my original post specifically stated the case where
you do not know how many elements before hand)

Code:

---

#include "stdafx.h"

#include <iostream>
#include <vector>
#include <ctime>
#include <afxtempl.h>

using namespace std;

int main()
{
    int n;

    cout << "enter number of elements > ";
    cin  >>  n;

    clock_t start , finish;

    CString s("Hello World");

    start = clock();

    /*
    vector<CString> v;

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

    CArray<CString,const CString &> v;

    for (int i=0; i<n; ++i)
    {
        v.Add(s);
    }

    finish = clock();

    cout << "number of ticks = " << finish - start << "\n";

    return 0;
}

---

Quote:

---

Originally Posted by ovidiucucu

Im the most of MFC applications using <algorithm> is not necessary.

---

I find that quite surprising! I use STL algorithms all over the place - they save many, many lines of code. Unless of course you are not really using STL containers at all? If so, then you are really missing out.

There is even an advantage to mixing MFC and STL

For example...

Code:

---

std::vector<CString> v;

// Sort
std::sort(v.begin(), v.end());

// Find the first instance of 3 consecutive repetitions of "Hello"
std::vector<CString>::const_iterator it = std::search_n(v.begin(), v.end(), 3, CString(_T("Hello")));

// Remove consecutive duplicate elements
std::erase(std::unique(v.begin(), v.end()), v.end());

// Reverse the order of first half
std::reverse(v.begin(), v.begin() + (v.size() / 2));

// And so on...

---

Try doing that in so few lines with MFC alone. ;)

I can imagine hundred of applications that load "Hello World!" one millon (or more) times, having to be rewritten to gain one precious second. :D

Come on Philip! That could not be a serious benchmark example.

1) One second ???? Did you actually run it ? How many values
of n did you try ? What raethe results for n = 5,000,000 ?
n = 10,000,000 ? These are by no means un-reasonable
values for scientific applications.

2) Did you even bother reading my previous posts ? It simulates the case
where you do not know the number of elements before hand (such as
reading from a file or running a time-dependent simulation).

3) I still have not seen any proof of the so called "STL headaches"

4) Have you posted code for sorting CLIst yet ? Still waiting .... and waiting ...
and waiting ...

5) How about one funtion that find the largest element in a CArray or CList ?
Still waiting for that one function also.

Quote:

---

Originally Posted by JohnW@Wessex

I find that quite surprising! I use STL algorithms all over the place - they save many, many lines of code. Unless of course you are not really using STL containers at all? If so, then you are really missing out.

---

I agree. But the bigger point (IMO) is that your code sample could be written using CArray and STL algorithms and not std::vector (using CArray::GetData). As a matter of fact, all of the algorithm functions can be used on MFC CArray.

I can't think of one non-trivial application, I don't care what the framework used is, that doesn't do some algorithm, whether it's searching, sorting, partitioning elements, etc. The problem I find with a lot of MFC programmers (and even STL programmers) is that they do not know this.

For the MFC programmer, they can keep using CArray, CStringArray, etc. and still use STL algorithms to do searching, sorting, partitioning, removing, shuffling, permutations, finding min/max, etc.

Quote:

---

Try doing that in so few lines with MFC alone. ;)

---

You can't do it in MFC, since algorithms do not exist in the MFC framework classes. The searches must be coded from scratch if no STL is used. This is no different than an STL container user who is not versed in algorithms -- they will also write all of this searching logic from scratch.

The usual results from coding these functions from scratch is that the code is slower than using the algorithm function, or the code has subtle bugs, or the code is redundant (for example, writing the same general loop over and over again, with the only difference being the search criteria).

Regards,

Paul McKenzie

Quote:

---

Originally Posted by JohnW@Wessex

Code:

---

std::vector<CString> v;

// Sort
std::sort(v.begin(), v.end());

// Find the first instance of 3 consecutive repetitions of "Hello"
std::vector<CString>::const_iterator it = std::search_n(v.begin(), v.end(), 3, CString(_T("Hello")));

// Remove consecutive duplicate elements
std::erase(std::unique(v.begin(), v.end()), v.end());

// Reverse the order of first half
std::reverse(v.begin(), v.begin() + (v.size() / 2));

// And so on...

---

Try doing that in so few lines with MFC alone. ;)

---

Well, I already said "STL is wonderful".
However, what's above look more like interview questions than practical examples (except the first one wich is trivial in MFC as well) ;)

Quote:

---

Originally Posted by Paul McKenzie

You can't do it in MFC, since algorithms do not exist in the MFC framework classes.

---

That was my point. :thumb:

Quote:

---

Originally Posted by Paul McKenzie

For the MFC programmer, they can keep using CArray, CStringArray, etc. and still use STL algorithms to do searching, sorting, partitioning, removing, shuffling, permutations, finding min/max, etc.

---

That's right. Many do not know that can use, for example, std::sort to sort a CStringArray, then run to std::vector<CString>.

Quote:

---

Originally Posted by ovidiucucu

However, what's above look more like interview questions than practical examples

---

When you've only got a few minutes between compilations to write an example then you're not going to get anything ground-breaking ;)