File Input - bad alloc

I have written a small program designed to read file input and put this information into a multidimensional array. As it stands, the program reads just one file for now, the name of which I specify when calling readfile.open. However, I have now altered the program so that the readfile function accepts a c-style string (I need to do this so that in the future I can alter the name of the file by looping over variables). The program now crashes with the following message:

terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

The program compiles fine; I am using g++ on red hat. Here is the program source code:

#include <cstdio>
#include <cstdlib>
#include <complex>
#include <math.h>
#include <iostream>
#include <fstream>
#include <string>
#include <sstream>
using namespace std;

complex<double> convert_complex(complex<double>);

ifstream::pos_type size;
complex<double> *zbuff;

int main(int argc, char *argv[])
{
int srcdir, srccol, slice, sinkpar;
int i, j, k, kount;
int Nc = 3;
int spaceh = (24*24*24)/2;
srcdir = 0;

complex<double> Psi[4][Nc][spaceh][4]; // Complex array to store info in file //

string filename;
stringstream(filename) << "bqcd.567.00000.00.1.1.10.0.prop"; // Filename, potentially modifiable //

ifstream readfile;
readfile.open(filename.c_str(), ios::in | ios::binary | ios::ate);
size = readfile.tellg(); // Determine size of input file using the get pointer //
readfile.seekg(0, ios::beg); // Put pointer back to beginning of file //
zbuff = new complex<double>[size]; // < -- Execution stops here. zbuff is simple a one dimensional complex array //
readfile.read(reinterpret_cast <char *> (zbuff), size);


for(k = 0; k < spaceh; k++)
{
for(j = 0; j < Nc; j++)
{
for(i = 0; i < 4; i++)
{
Psi[i][j][k][srcdir] = convert_complex(zbuff[kount]); // Take info in 1-d array zbuff, change endianness of entry, place in correct element of 4-d array Psi //
kount++;
}
}
}

readfile.close();

cout << Psi[1][1][1][srcdir] << endl; // Test output from Psi //
cout << Psi[2][1][2][srcdir] << endl;
cout << Psi[0][0][0][srcdir] << endl;
cout << Psi[0][0][790][srcdir] << endl;

return 0;
}

complex<double> convert_complex(complex<double> in)
{
complex<double> out;
char *p_in = (char *) &in;
char *p_out = (char *) &out;
p_out[0] = p_in[15];
p_out[1] = p_in[14]; // Function to reverse byte order of a single entry of complex array zbuff //
p_out[2] = p_in[13];
p_out[3] = p_in[12];
p_out[4] = p_in[11];
p_out[5] = p_in[10];
p_out[6] = p_in[9];
p_out[7] = p_in[8];
p_out[8] = p_in[7];
p_out[9] = p_in[6];
p_out[10] = p_in[5];
p_out[11] = p_in[4];
p_out[12] = p_in[3];
p_out[13] = p_in[2];
p_out[14] = p_in[1];
p_out[15] = p_in[0];
return out;
}


As I said, the program works perfectly when the filename is given explicitly. Only when I pass the filename as a string does the program crash. Curiously, the crash does not occur at the filename line, but later on, when "new" is called. The bas alloc suggests I have run out of space for something. I don't see how that is possible, since nothing is particularly large here. zbuff is the largest creation here, but there were no complaints before I made this minor change, and I also intent to make zbuff considerably larger in the future!

Any help would be much appreciated.

Warren

you already know where it fails. Look at the variable "size": what's its value? Is it too big for a new() to succeed or possibly negative because your file does not exist?

The debugger (dgb) provides a non-sensical message when I ask it to "print size", which is strange because "size" is apparently basically an integer type:

print size
$2 = {_M_off = -1, _M_state = {__count = 0, __value = {__wch = 0, __wchb = "\000\000\000"}}}


The file definitely exists in the directory, and "size" itself was determined by putting the get pointer at the end of the file. The file is roughly 1.3 Mb in size. In any case, this method worked very well before I altered the way of telling the program the filename. Apparently, for this flexibility with filenames, you need to provide readfile.open with a c-style string.

not sure what

Code:

---

string filename;
stringstream(filename) << "bqcd.567.00000.00.1.1.10.0.prop";

---

does (is it creating a temporary object which is gone after you step over the second line?), but why not just do

Code:

---

string filename("bqcd.567.00000.00.1.1.10.0.prop");

---

You can still modify the string. And that size thing does not look good to me.

BTW: do you notice the code tags in this post ;-) ?

I can't determine what these two lines are doing:

Code:

---

string filename;
stringstream(filename) << "bqcd.567.00000.00.1.1.10.0.prop"; // Filename, potentially modifiable //

---

Maybe you want something like:

Code:

---

stringstream ss;
ss << "bqcd.567.00000.00.1.1.10.0.prop"; // Filename, potentially modifiable //

string filename = ss.str();

---

Also, I don't know why you need a stringstream at all in this case.

ifstream:: pos_type is no basic integer type, but it seems it&#180;s implicitely convertible to an integer type.
As Richard already pointed out something seems to go wrong when opening the file because the m_off member is set to -1, which indicates an invalid file position.

Your suggestion is actually the original form of my program - providing the string explicitly. I can certainly change the name of the file each time I edit the source code, but my goal is to be able to loop through certain variables (mainly integers) which form part of the file name itself. I wish to read multiple files using such a loop, and that data is to be read into the a (larger) multidimensional array.

I've assumed here that I need to use the stringstream class if I want to include variables in the file name. The different numbers in the file name I've used actually correspond to different integers I need to loop over.

Sorry about the missing code tags, it seems I can't edit posts according to the permissions I have.

Quote:

---

Originally Posted by Philip Nicoletti

I can't determine what these two lines are doing:

Code:

---

stringstream ss;
ss << "bqcd.567.00000.00.1.1.10.0.prop"; // Filename, potentially modifiable //

string filename = ss.str();

---

Also, I don't know why you need a stringstream at all in this case.

---

I'll try this suggestion; it seems like a neater way of doing. Although I do need to use the stringstream so that I can loop over multiple files in a future version of the program.