ifstream File*.txt

[JovanD]

Hi,

Is it possible to use ifstream to sprecify loading a file called Filev2*.txt (the * part will vary with different version numbers)

The closest to what I thought would work, but did not:

ifstream myfile(*".txt");

Any help much appreciated

Jovan

[Stewbond]

string filename, version;
version = "123abc"; // put your version here.

filename = "Filev2";
filename += version;
filename += ".txt"

ifstream myfile(filename);

[JovanD]

Hi Stewbond,

Thanks for the quick reply,

This code works:

string filename = "Filev2.0.1.txt";
ifstream myfile(filename.c_str());

Am not sure if my first post explains properly but I want to be able to load any .txt file that starts with "Filev2". This way I can update the file to the user and it will automatically load without having to recompile the main program.

Thanks in advance,
Jovan

[Stewbond]

Oh I understand then.

You can't just load file "Filev2*.txt" because there is a possibility that there will be 2 files in a folder matching this criteria. Both files cannot be opened at the same time and stuck into one object. That would be a complete mess. You must define the filename somewhere. If you want to be able to define the version without recompiling, I recommend using a configuration file. This text or binary file could contain a set of options that you would be able to easily parse.

An easy way to do this:
1. create a blank file in notepad and save it in your bin directory as "version.cfg" or something like that.
2. Type the following into the file and save: 2.0.1.
3. Include the following in your code:

string filename, version;
ifstream ifVersion("version.cfg");
ifVersion>>version;

filename = "Filev";
filename += version;
filename+= ".txt";

ifstream myfile(filename.c_str());

Now if you ever change the version without updating this DLL or EXE, you'll need to add a line to update "version.cfg" in your install script.

I hope that helps.

[andywestken]

If you don't mind an o/s specific solution...

If you're working with Windows, you can use FindFirstFile()/FindNextFile()/FindClose() to list all files of the form Filev*.txt, parsing then to extract the version from their name, and then open the on with the highest version number. But this might be more effort than it's worth.

The Linux equivalent would, I assume, be based on opendir()

And there's Boost.FileSystem's directory_iterator (which will be turning up in TR2?)

[JovanD]

Thank you so much for your solutions Stewbond and Andywestken.

Your help is much appreciated. Thanks for the thorough explanations - its refreshing to see this on a forum compared to the comments on other ones like "learn the language!"

[cobowitz]

probably a stupid question, but where would I put the physical file within my computer. I am using Xcode on a mac, and it auto goes to my auto if(!inFile) cerr message. Also, does anyone know an easy way to use the input line by line as variables for calculations read from the text file?

[andywestken]

As far as file locations are concerned, the convention is o/s specific. Windows and Linux definitely have their own rules, and I have a suspicion that OS X mostly follows Linux rules, ...

http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs

But Apple o/s also work with "application bundles" which I only know of, rather than about.
http://en.wikipedia.org/wiki/Application_bundle

Any OS X developers about???

As far as using input: you mean the input of a file?

Andy

[Stewbond]

I agree that OS X mostly follows Linux rules (it is based on the same kernel), however I do not agree that the convention is completely OS specific.

As far as I know, an executable file will generally search its own directory for any required files unless otherwise specified. So just put the *.cfg file in the same folder as your *.exe file.

There are some other rules if you'd like to take advantage of them. If you are using Windows and you call an executable from another directory, the executable will search for the extra files in the current directory instead of its own directory.
example:
c:> start c:\project\bin\MyProgram.exe
This will start MyProgram.exe, however it will search C:\ for the associated files. To work around this, you'd have to change to the required directory first:

c:> cd c:\project\bin\
c:\project\bin> start MyProgram.exe

In Linux, this issue doesn't exist. You can run a program from anywhere (even from another computer using an ssh client such as PuTTy). Example:
/project/bin/MyProgram.exe
This will run the program directly and use any files in that /bin/ directory. Very cool and easy!

Another thing you could try if you wanted is setting environment variables. I'm not great at this in Linux and have never done it on a Mac, but in Windows you can use the "Path" environment variable. This contains a set of locations where Windows will look if it can't find your file. If you have a specific extension (.cfg or something), then you'd have to check if it is specified in the "PATHEXT" environment variable and then you'd have to add it. This will affect your entire system however and may be dangerous.

[andywestken]

If you want a Windows app to always look for it's config file in its own directory, you can either (a) use the path passed as argv[0] to main(), if it's a console app, or (b) the one obtained using GetModuleFileName(), which works for all WIN32 apps. This is the path to the exectable. The path pass to main() can can be relative, so you've got to convert it to an absolute path with respect to the working directory before using it. And I know the main() approach works for Ubuntu, so I assume it does so for most other distros.

I use the above approach for dev tools and other utilities. But for real applications, the convention is to put application settings and data in either in ProgramData (e.g. C:\ProgamData\MyCompany\App), if for all users, or the user's app data directory. The base paths to these folders are obtained using SHGetKnownFolderPath(). This convention has been around a while, but now restricted users do not have write access to C:\Program Files, it is necessary if you want the options to be modifiable.

For Linux, I thought the Linux Filesystem Hierarchy Convention defined where files were supposed to go? /usr, /etc, /var, ...