views:

296

answers:

6

In my new code I am not using strings to pass directory paths or file names. Instead I am using DirectoryInfo and FileInfo as they seem to encapsulate a lot of information.

I have seen a lot of code that uses strings to pass directory information then they "split" and "mid" and "instr" in long incomprehensible statements until they get the part of the directory they are looking for.

Is there any good reason to pass paths as strings?

+3  A: 

Once the path is in an application (i.e. not in a plain text configuration file), no, there isn't a good reason.

The only time (I can think of) it could be useful is when interoperating with code that only accepts paths as strings.

Sean Bright
+3  A: 

DirectoryInfo and FileInfo are awful heavy for passing around if all you need is a path. I'd be more concerned about the "split and mid and instr" junk. Learn the ways of:

Path.GetFileName
Path.GetDirectoryName
Path.Combine
etc...

Those are from the System.IO.Path class, btw.

Chris
Remember, when you're passing an instance into a function, it's passing a copy of the reference, not a copy of the entire object! So all you're really passing is copy of a pointer...
John Rasch
I believe the issue isn't how many bytes are passed around, but rather the overhead of using FileInfo/DirectoryInfo, which has to probe the file in a variety of ways to cache information about it.
Steven Sudit
But first optimize for readability.
Matthew Sposato
+4  A: 

In general, I think keeping the information in FileInfo/DirectoryInfo is better. There is a lot of useful functionality in these classes, as well as a lot of safety involved in that it's much easier to check for existence of a file, see the originally specified file, etc.

The only place where I would (potentially) pass a path as as a string instead of using FileInfo and DirectoryInfo would if the path was going to be passed across AppDomains or between processes, etc.

FileInfo and DirectoryInfo both work fine across AppDomain boundaries (since they're Serializable), but they have a fair amount more overhead in this situation. If things are going back and forth a lot, it could have an impact.

I would stick with FileInfo and DirectoryInfo in this case, though, unless I found that there was a noticeable problem during my profiling, and I was trying to reduce the amount of serialized data. If I didn't run into performance issues, I'd stick with using these classes, as they provide a lot of safety and functionality.

Reed Copsey
A: 

I've encountered problems when passing FileInfo to DMZ's. As far as I can see - correct me if i'm wrong - FileInfo performs a permission check when deserializing and that won't work from DMZ and result in 'path not found'. Create and pass a custom object with the data you instead.

magnus
A: 

I cant convert the paths to strings

steve
A: 

I think you do need a class to encapsulate a file or directory path, instead of using raw strings and manipulating them using the static System.IO.Path class. However, I don't find DirectoryInfo and FileInfo suitable, because they seem to be intended more for doing file/directory manipulations instead of path operations. If you make a custom class for path manipulation, you can provide more user friendly path manipulation functionality.

Dimitri C.