Combining Arrays?

(.NET Version 2.0.50727) VS2005

Code:

---

strGetFiles = Directory.GetFiles(strDirectory, strFileType[0], searchOption);

strGetFiles1 = Directory.GetFiles(strDirectory, strFileType[1], searchOption);

---

I am getting all the file names(locations) of a specific type and placing them into a string array (strGetFiles[]). I am having to do this 2 times (into two seperate arrays) because I am searching for *.bmp in the first one and *.gif in the second. This is forcing me to use two different arrays when I really would like all of them to be combined into one array. I would like to do something like this:

Code:

---

strGetFiles = Directory.GetFiles(strDirectory, strFileType[0], searchOption);

strGetFiles += Directory.GetFiles(strDirectory, strFileType[1], searchOption);

---

I know this doesn't work, but you get the idea. I want to append the second array to the end of the first one. Is there a way to do this? Or is there a way to use the GetFiles command and include more than one filetype?

If I need to elaborate, please let me know.

Thanks,
Aaron

You could use the array copyto command and do something like...

Code:

---

strGetFiles = Directory.GetFiles(strDirectory, strFileType[0], searchOption);

Directory.GetFiles(strDirectory, strFileType[1], searchOption).CopyTo(strGetFiles, strGetFiles.length);

---

I don't remember the exact syntax, also you would have to make sure your strGetFiles array is large enough to hold the values of both arrays.

Quote:

---

Originally Posted by jshultz

You could use the array copyto command and do something like...

Code:

---

strGetFiles = Directory.GetFiles(strDirectory, strFileType[0], searchOption);

Directory.GetFiles(strDirectory, strFileType[1], searchOption).CopyTo(strGetFiles, strGetFiles.length);

---

I don't remember the exact syntax, also you would have to make sure your strGetFiles array is large enough to hold the values of both arrays.

---

I didn't predefine a size because I had not idea how many files would be returned. Is that a problem?

If you are just setting it equal to another array that shouldn't be a problem, if you want to use the CopyTo function, it might be. I haven't tested this. Give it a shot and see what happens. Worse that can happen is it throws an exception/crashes =-)

use a generic List<string> data type and use AddRange to add the results of the GetFiles, then return it to an standard array using the lists ToArray method.

Come on guys... Are we afraid to write a little code?

Code:

---

String[] strGetFiles;
String[] strFileType;

foreach (string type in strFileType) {
    strGetFiles = appendArray(strGetFiles, Directory.GetFiles(strDirectory, type, searchOption));
}

private String[] appendArray(String[] arr1, String[] arr2) {
    String[] resultArr = new String[arr1.Length + arr2.Length];
    int i,j;

    for (i = 0; i < arr1.Length; i++) {
        resultArr[i] = arr1[i];
    }
    for (j = 0; j < arr2.Length; j++) {
        resultArr[i + j] = arr2[j];
    }
   
    return resultArr;
}

---

Of course, if you're lazy you can always go MadHatter's route which would probably be much easier. :-)

Quote:

---

Are we afraid to write a little code?

---

No, but using a built in (such as MadHatters) is a better way.

Custom code like you wrote will cost money over the long run.

The odds of a bug is much higher [will you bet $100 that there is not a boundary condition that will break your code?]

One of the metrics we use for estimating maintenance costs is the number of "if" and "for" statements. These estimates have proven to be accurate.

Consider what happens to your code if some other programmer changes the "i++" to "++i" thinking it would make the loop "more efficient"???

I agree with the above. Why write complex code to append arrays when you can do the exact same thing using an inbuilt class? Unless there's a compelling reason not to, use the built-in stuff.

Code:

---

String[] strGetFiles;
String[] strFileType;

foreach (string type in strFileType) {
    strGetFiles = appendArray(strGetFiles, Directory.GetFiles(strDirectory, type, searchOption));
}

private String[] appendArray(String[] arr1, String[] arr2) {
    List<String> list = new List<String> (arr1);
    list.AddRange(arr2);
    return list.ToArray();
}

---

Of course, using the List<T> means you don't need the 'appendArray' function anymore, you can completely remove that method. A further bonus:

Code:

---

List<String> strGetFiles;
String[] strFileType;

foreach (string type in strFileType) {
    strGetFiles.AddRange(Directory.GetFiles(strDirectory, type, searchOption)
}

---

Isn't that much shorter and easier to maintain?

I understand the argument for maintainability and minimizing complexity, and I stated that using the built in functionality would be easier and simpler. But the point of my "are we afraid of a little code" statement was pointing out that after four responses to a question asking how to do one of the most basic programming operations, no one had said "Use a for loop!". It seems like everyone's looking for the built-in solution for even the simplest of tasks. I guess I was politely trying to suggest that we are better served by knowing how to do something as opposed to being told the correct library call. In the example, my little function is not simply a way to combine two arrays, but it is how arrays are combined. To me the latter is more useful.

True, true. I get your point alright and it's a good one.

if you don't think built in options are better in the long and short run than doing things yourself, then why use C# to begin with. I'm sure anyone could manage memory better in C++ than the framework could with .net, so IMO that argument falls flat to the ground.

Things like this always make me think of an old college professor of mine who spent an entire class session complaining about things like stl, and object oriented programming to some extent because it could never be as efficient as asm / procedural programming.

my thought is, why re-invent the wheel?

why not use label / go to statements instead of built in flow controls if we're not afraid of writing a little more code?

while I couldn't care less one way over another in this situation. .net collections will always be less efficient than rolling it yourself simply because they dynamically resize the internal array larger than what is needed, and even though that doesn't typically happen that often, or is that expensive, it still factors into the big O performance. On the other side of that argument are things that have already been said, so personally I wouldn't go ape-shite over the hand coded array manipulation as much as I would if someone used goto/labels in place of standard flow control.

personally, I like all the nice built in features of .NET, and would use a generic list.

True. With that mentallity you could even say, "Why use for loops? Why don't you just write every line out one by one?". I just need the code to be written quickly so I can get on with the rest of my project.

Anyway, thanks for the help all!

Quote:

---

Originally Posted by Amerikon

I guess I was politely trying to suggest that we are better served by knowing how to do something as opposed to being told the correct library call. In the example, my little function is not simply a way to combine two arrays, but it is how arrays are combined. To me the latter is more useful.

---

I believe both ways are important: 1) to understand what's going on and 2) learning the environment well enough that you don't need to do 1).

I wasn't trying to say that all built-in functions are bad or that they shouldn't be used. I was just trying to point out that when it comes to something as fundamental as appending two arrays isn't more important that you know how to do it as opposed to just which built-in function to call. It's not re-inventing the wheel, it's explaining how the wheel works. As I said before, adding the arrays to a list and then calling that list's .toArray() method is "a way to combine two arrays" it is not "how two arrays are combined", which is what my example was. I don't know how the .NET List class is implemented but if you were to look at java's Vector or ArrayList classes that's pretty much the exact way they combine their arrays. If you don't learn the basics, programming ends up being a magic puzzle where you just have to find the correct ordering of library calls and then it somehow does what you want it to do. There's a lot to be gained by pulling back the curtain so you can understand why calling List.AddRange() works.

List<T>.AddRange's only purpose in life is to combine the array passed in, with the current internal array.

One doesn't have to understand the mechanics of a car to be able to drive one, and drive it well. similarly I don't believe it is important to understand the mechanics of the way .NET has implemented web services in order to consume one, I don't think its important to understand the hypertext transfer protocol in order to make an HttpWebRequest, or for that matter the way winsock2 communicates w/ the system to enable you to transfer data over a socket, and so on and so forth.

its not like he was asking how to implement a genetic algorithm, or how to roll his own hashtable/map. He posted code that logically makes sense (using an append operator), IMO it was more of a question on how to append an array in .NET, and since .net arrays are not dynamic, the only logical way to do what his first approach was showing was to append an array. .NET collections are used for that, therefore, again, IMO using a dynamic array / collection was the answer they'd be looking for.

Quote:

---

Originally Posted by Amerikon

There's a lot to be gained by pulling back the curtain so you can understand why calling List.AddRange() works.

---

That is true, and for learning valuable, but IMHO has no place in any "real" program (even one written by a hobbiest).

If you REALLY want to know how things work, write some assembly code that properly manages a quad core, pipelined, dual level chached processor...

btw: I know one person who does exactly that. He is considered the leading expert in super high performance realtime (but his passion is writing games :) ). The problem is that NOBODY but him can do even the slightest maintenance on his code. Often changing a single instruction will completely break the code. So we keep him in a VERY small box, and make sure his code is used only where it is ABSOLUTELY needed.

First off, there is no way you're comparing combining arrays with socket communication and web services. Combining arrays is about as basic a programming task as you can imagine. It was also pretty clear from the original post, that the poster didn't know how to combine two arrays. Why am I so out of line for suggesting that he's better off having seen an example of how it's done instead of just throwing some
First off, there is no way you're comparing combining arrays with socket communication and web services. Combining arrays is about as basic a programming task as you can imagine. It was also pretty clear from the original post, that the poster didn't know how to combine two arrays. Why am I so out of line for suggesting that he's better off having seen an example of how it's done instead of just throwing some built-in functionality at him? If the original poster looked at my example and understood how it works he can now combine arrays in pretty much any language that supports arrays. If all he knows is List.AddRange() he can only combine arrays in .NET, and additionally comes away with the idea that in order to combine two arrays you have to use a List object. Which is why my first post said "here's how you combine arrays but using the List object is easier".
Second, the analogy driver:car :: programmer:program doesn't work. A driver is far more like a user than a programmer. When a programmer writes code, if that code breaks, the programmer has to fix it. He has to know enough about what's going on "under the hood" so that he can diagnose and solve the problem. There is a certain set of fundamental skills (including how arrays are manipulated) that you have to know if you want to program. Otherwise we might as well just hand out CS degrees with copies of the .NET SDK docs.

That tongue-out smiley is supposed to be a colon followed by a p. programmer : program.

In the U.S. there is a Yamaha motorcycle commercial that plays where kids are shown trying to start their dirtbikes. Yamaha is trying to sell their new line of electric start dirtbikes. They show them kicking and kicking and then the dads come up and try to start them. While this is going on, in the background you can hear kids sing, "I wanna ride, I wanna ride, I just wanna ride."

So for this post, maybe "I just wanna code" is apt?

Sometimes you just need to complete the task at hand and get on with it.

If I hire a beginning programmer, I expect the programmer to understand the basics. However, I expect the programmer to move beyond the basics and leverage what the environment offers.

Too often beginning programmers get caught up into manually coding such tasks. In C++, it was common to see yet another linked list implementation or a string class (rather than use stl). [If I see another homegrown C++ string class, I think I'm going to hurl]

C# is no different. Understand it, and then move on.

Code:

---

class String
{
public:
......
}

---

:D :D :D :wave:

If you're too young to start your dirt-bike, maybe you shouldn't be riding. :-)

perhaps the answer should have been:


Use a List<string>.AddRange for each of the arrays sent back from get files, and download reflector on your own time to learn how add range works.

This thread could go on and on, but I just want to say that although I'm a KTM fan, Yamaha makes some pretty dang good dirt bikes.