[RESOLVED] Need advice - what to use CStringArray or CStringList

[ahmd]

I have a program that first counts and remembers file paths in a specified folder in accordance with a certain filter and then processes them. The counting part of the function needs to collect all file names into an array. The processing part needs to see if a certain file name is in that array.

What type of arrays shall I use for that: CStringArray, CStringList or CStringMap? I'm kind of confused over what each of them does (please don't point me to a Microsoft description, I read it about five times and I still don't get it.) I'm basically looking for the fastest implementation of the dynamic array for this purpose.

[Arjay]

Are you interested in the fasted insertion or fastest lookup?

[ahmd]

I'll technically be using both.

[VictorN]

Collections: Choosing a Collection Class

[cilu]

I'll technically be using both.

Yes, of course, but which is going to be more important? Once collected, are you going to do lots of look-ups? I would consider using a map in this case.

[GCDEF]

Yes, of course, but which is going to be more important? Once collected, are you going to do lots of look-ups? I would consider using a map in this case.

I agree. If you need to do a lot of lookups based on a value, a map would be best.

[Ajay Vijay]

If number of items are only inserted at end, and around 100 elements reside in container, then std::vector is very appropriate. Even with 1000 elements, vector search works faster than maps!

[ahmd]

I'm searching recursively thru files in a folder (so I can't tell you how many there are -- it may be anything from 0 to 10,000 and more). At this stage I need to collect all the file paths in an array.

When all files are found, the second round of recursive search opens each file and processes it in a certain way. At this point if a certain tag is found in a file, I need to match that tag with a file name in the array created above. Each file, on average, may contain from 0 to 10 of those tags, but that number can be more.

So what would you use in this case? (I can't go with std::vector since I've never used it before and I need to go with something that I already know.)

[Philip Nicoletti]

When all files are found, the second round of recursive search opens each file and processes it in a certain way. At this point if a certain tag is found in a file, I need to match that tag with a file name in the array created above. Each file, on average, may contain from 0 to 10 of those tags, but that number can be more.

Could you explain this in more detail ?

1) What is recursive about this search ?

2) What do you ultimately want :

a) for each file ... a list of tags in that file ?

b) for each tag ... a list of files that have that tag ?

[bhushan1980]

Just 2 cents...
I hope ahmd refers to a method that searches for all the files in a folder, gets / stores their paths and if a folder is encountered, it calls itself (recursion). So instead of storing only the paths, you can also store the information regarding the parent and the level (starting from 0 for the starting directory). You could just create a class that holds a files path (CString), parent (CString) and level (int) and then create a vector of that class?
BTW, using a vector is very simple...if you are not comfortable with STL, you are better off using CArray provided by MFC or even better if you use CAtlArray, if you do not need the serialization support provided by MFCs CObject.
Bhushan

[bhushan1980]

As I said, here is a MFC code to do the find:

http://msdn.microsoft.com/hi-in/libr...50(en-us).aspx

You can still get the path, parent and level info and store it in a class and create its MFC Array as I said before...

Bhushan

[ahmd]

1) What is recursive about this search ?

Pretty much what Bhushan showed in his MSDN link -- if I find a folder the function calls itself with it's path.

a) for each file ... a list of tags in that file ?

No.

b) for each tag ... a list of files that have that tag ?

If I find that the tag matches I'm updating the file that this tag is in and save it back to disc.

Why a second recursive search? You already have all your file names in your collection object, why not just iterate through that?

Good point. The reason I do this is because it's an option that can be switched off in the program. Without this option being on, I need to count all the files first to display the progress bar during the second pass.

So instead of storing only the paths, you can also store the information regarding the parent and the level (starting from 0 for the starting directory). You could just create a class that holds a files path (CString), parent (CString) and level (int) and then create a vector of that class?

I have the code that's already tested and working, rewriting it completely is not what I'm looking for at this point. (Again my goal is to speed it up/optimize it.) But thanks for offering. Truly I didn't think about such approach. Although, wouldn't it be much slower if I propagate the whole class instead of just a CString object?

[GCDEF]

Good point. The reason I do this is because it's an option that can be switched off in the program. Without this option being on, I need to count all the files first to display the progress bar during the second pass.

Okay, but what I'm saying is you can get all the paths from your container for the second pass. No need to go searching the whole directory structure again. That should be high on your list of things to eliminate if you're concerned about performance.

[GCDEF]

I'm searching recursively thru files in a folder (so I can't tell you how many there are -- it may be anything from 0 to 10,000 and more). At this stage I need to collect all the file paths in an array.

When all files are found, the second round of recursive search opens each file and processes it in a certain way. At this point if a certain tag is found in a file, I need to match that tag with a file name in the array created above. Each file, on average, may contain from 0 to 10 of those tags, but that number can be more.

So what would you use in this case? (I can't go with std::vector since I've never used it before and I need to go with something that I already know.)

Why a second recursive search? You already have all your file names in your collection object, why not just iterate through that?

[Paul McKenzie]

So what would you use in this case? (I can't go with std::vector since I've never used it before and I need to go with something that I already know.)

What if what you already know is less efficient than something you don't know? Are you willing to learn the thing that you don't know?

It has been reported (and I tend to agree), that the STL containers are more efficient and robust than the MFC containers. All it takes is an example or two from a book as to how to use them correctly. Unless you really have a huge stake in the serialization methods used in the MFC container classes, or you're maintaining a legacy MFC only app, IMO there is little, if any reason to be using the MFC container classes. I've seem rumors where the Microsoft engineers do not even use the MFC containers, but use the STL containers, but those are just rumors and I can't really substantiate them (but it wouldn't surprise me).

To be honest, I'm kind of surprised the MFC containers haven't been deprecated -- they have been around since 1990, before the STL containers made their way into the C++ standard library, and IMO been superseded by the standard components. There was nothing wrong with the MFC containers back in the early days of Visual C++ 1.0 or 1.5, but the standard C++ library container classes has surpassed those old MFC container classes (but again, only if you really and truly need the MFC serialization stuff in the MFC container classes, and even then, you can write your own serialization for the STL containers).

Now CString, that is a different story -- the CString class (which is now templated) is a very good implementation that has advantages over std::string.

Regards,

Paul McKenzie