ifstream.open() doesn't open file

[LMHmedchem]

I have some code that opens a file into a ifstream and writes each line to a vector<string>.

#include <string>
#include <vector>
#include <iostream>
#include <fstream>
#include <sstream>

using namespace std;

void read_output_columns_file(string& output_columns_file) {

   // create an input stream and open the colums_input_file file
   ifstream output_columns_file_istream;
   string new_input_line;
   output_columns_file_istream.open( output_columns_file.c_str() );
  // check to see if the file is open
   if(!output_columns_file_istream.is_open()) {
      cout << "file  " << output_columns_file << "  could not be opened" << endl;
      exit(-4);
   }

   // remove unwanted characters and save data from file in vector
   vector<string> inputs_from_file;

   while( getline(output_columns_file_istream, new_input_line) ) {
      // remove '\r' EOL chars and tab characters
      new_input_line.erase (remove(new_input_line.begin(),new_input_line.end(),'\r'), new_input_line.end());
      new_input_line.erase (remove(new_input_line.begin(),new_input_line.end(),'\t'), new_input_line.end());
      // add line to vector of string
      inputs_from_file.push_back(new_input_line);
   }

   // close istream
   output_columns_file_istream.close();

return;
]

I am getting my trap error that the file was not opened. This worked yesterday, but I had things all in one file. Today, I broke this into a few src files and wrote a make. It compiles and links, but I get this error. The next thing to happen is that inputs_from_file gets parsed to some other locations, and that code gives a stackdump because the vector is empty.

I also tried this with a very simple build, g++ -c, then g++ -o, and I get the same thing, so I don't think it's a problem with the make. Below is the make file in case that could be the issue. I have printed out the file name, and that is correct, it doesn't appear to be a permission issue with the file, etc.

Any suggestions?

LMHmedchem

#  12-02-21 makefile for datasplit.exe
SOURCELOC = ./src

# create build location name
OS   := $(shell uname -s)
ARCH := $(shell uname -m)
KERN := $(shell uname -r | cut -d. -f 1,2)
CMP  :=g34
BDIR := bld_$(OS)_$(CMP)_$(KERN).$(ARCH)

# compiler falgs
CC++ = g++
CFLAGS = $(OPTIMIZE)  -Wall

OPTIMIZE = -O2
LIBS = -lstdc++

## create build directory if it doesn't exist
archdir: $(BDIR)
$(BDIR):
	@mkdir -p $(BDIR)

all: $(BDIR)/datasplit.exe


FORCE:
clean:
	rm $(BDIR)/*.o  $(BDIR)/*.exe

# data_split objects
OBJS = \
         $(BDIR)/datasplit_main.o \
         $(BDIR)/datasplit_read_file.o \
         $(BDIR)/datasplit_print.o

# build datasplit.exe
$(BDIR)/datasplit.exe: $(OBJS) 
	$(CC++) $(OPTIMIZE) -o $@ $(FCFLAGS) $^ $(LIBS)

# compile src c++ objects
$(BDIR)/%.o: $(SOURCELOC)/%.cpp
	$(CC++) $(CFLAGS) -c -o $@ $<

## force recompilation of files if header is changed
$(SOURCELOC)/*.cpp: $(SOURCELOC)/columns.h \
                    $(SOURCELOC)/datasplit_read_file.h \
                    $(SOURCELOC)/datasplit_print.h

	touch $@

[LMHmedchem]

It would appear that we have a cockpit error, in other words it would appear that I am just a moron. When testing the app, my shell pwd wasn't where the app was located (I was a level above it), so I was running,

./test/datasplit.exe -c _v33-1_S2A_columns.txt -m 5

so the file "_v33-1_S2A_columns.txt" wasn't in ./, but in ./test/ with the app, so the filename passed by the shell didn't really exist.

If I run,

./test/datasplit.exe -c ./test/_v33-1_S2A_columns.txt -m 5

then I am fine. That's what I get for trying to be clever and run everything out of one shell.

I guess I should have trapped the existance of the filename and not if the stream had been opened. Is there a simple method to test if a file exists?

Sorry for the annoyance.

LMHmedchem

[Paul McKenzie]

I am getting my trap error that the file was not opened.

So why would we doubt this? Maybe the file honestly cannot be opened.

It compiles and links,

Compiling and linking successfully means absolutely nothing except that the syntax is correct and the functions can be found. It has no bearing on how the program will actually run or if there are logical errors.

The next thing to happen is that inputs_from_file gets parsed to some other locations, and that code gives a stackdump because the vector is empty.

You found a hole in your program -- you didn't check for the empty vector.

I also tried this with a very simple build, g++ -c, then g++ -o, and I get the same thing, so I don't think it's a problem with the make.

Why would you believe it's a problem with the make file?

it doesn't appear to be a permission issue with the file, etc.

Well, unless we have access to your computer, none of us out here will know for sure.

The issue is that you have variables hiding all of these details. We can't see inside of those variables, so we have no idea if what those variables contain are the correct file names, whether they have stray characters in the names you don't see, or even the actual name of the file you're trying to open.

Why not actually hard-code the name of the file you are trying to access into your program, so as to remove all doubt whether it has something to do with your logic? Even this simple program should work if the file actually exists and can be opened.

#include <fstream>
#include <iostream>

int main()
{
  std::ifstream fs("The name of your file");
  if ( fs )
       std::cout << "The file was opened";
  else
       std::cout << "The file was not opened";
}

If this does open the file, then the issue is something other than the file not being able to be opened. Maybe you need to specify the full path, or maybe the logic to get the file name to open is faulty in your larger program (again, we don't know what the file name is, since it is hidden behind those variables).

Edit: I see you found the problem.

Regards,

Paul McKenzie

[Paul McKenzie]

I guess I should have trapped the existance of the filename and not if the stream had been opened. Is there a simple method to test if a file exists?

What OS? There is no portable way to test this.

Maybe boost has something that would make it somewhat portable.

Regards,

Paul McKenzie

[LMHmedchem]

So why would we doubt this? Maybe the file honestly cannot be opened.

For some reason, I was interpreting the file stream not being open as a problem setting up the stream, or forgetting to include something, etc. That's why I was puzzled about the lack of a compiler error. I was just thinking in the wrong direction. The fact that the error coincided with my moving to a make file didn't help.

Why not actually hard-code the name of the file you are trying to access into your program, so as to remove all doubt whether it has something to do with your logic? Even this simple program should work if the file actually exists and can be opened.

This is a good suggestion. I did print the variable name at that point in the code, and it was correct, so I didn't look any further in that direction.

What OS? There is no portable way to test this.

This is windows XP 32-bit under cygwin. If I need to use the in linux, I will just make a generic check if file exists functions and abstract it with an ifdef, meaning two versions of the function with only one getting compiled. I haven't found that to be too bad in the past.

Is it generally reasonable to assume that if the ifstream didn't open, the problem was with the file and not something else?

Thanks,

LMHmedchem

[Paul McKenzie]

This is windows XP 32-bit under cygwin.

Well, for Visual Studio, you have the _access() function that tests for existence. I don't know if CygWin supports this function or not.

I think your best bet for portability is to use the boost filesystem.

http://www.boost.org/doc/libs/1_48_0...reference.html

The exists() member function is used to test for file existence.

Is it generally reasonable to assume that if the ifstream didn't open, the problem was with the file and not something else?

The problem is almost always the file, but there could be some extraordinary circumstance that could occur. What exactly, I wouldn't know.

Regards,

Paul McKenzie

[LMHmedchem]

I guess I am already testing if the file is there by checking to see if the stream opened. If there was something like exists(), I could test when the args are parsed and bail earlier. This is just a widget, it is a rather large widget, but it is something that will only be used in a specific way where it is unlikely the file will be missing anyway. I put the trap in, and it told me it couldn't open the file, but I just misunderstood my own error. I guess I don't need anything more than is already there, but I thought I would ask since I do that kind of thing in bash and it is pretty straightforward.

I am sometimes surprised by functions that are not in the stl (I was shocked to have to write a function for mean and standard deviation the other day), but I guess that folks that do tons of file operations tend toward an interpreter anyway.

Thanks again,

LMHmedchem