Is this a memory leak? Kernel Resource leak? (C++, parallel studio)

Background: I'm working on some code to read in data from a file. Examples of data are separated by newlines. Also, there is a meta-level to the data and a semicolon acts as a delimiter to indicate the end of a sequence is reached. The file contains many sequences. I'd like open the file, read in a line of the data and store it as vector, do some stuff with the data, then read in the next line... until the end of the file.

The following compiles fine and when run with valgrind on my linux machine, no memory leaks are found. However, when I use the c++ inspector tool in Parallel Studio on my lab's Windows machine it reports to memory related errors in my program, both in this file.

A memory leak is reported and seems to stem from the line:

    ss>>number;

And also a kernel resource leak is reported with the following:

    data.open(filename.c_str());

Can anyone help me to understand why I am getting these errors and what I should do to correct them? I'm not seeing why this is a memory leak and 开发者_JAVA技巧am even less certain about the kernel resource error. Also, if I am doing anything outrageously stupid here, feel free to let me know!

class Network;

namespace data {
static std::string trainfiles[] = {
"/home/samurain/htm_check/data_files/train/sequence1.train", 
"/home/samurain/htm_check/data_files/train/sequence2.train"};

static std::string testfiles[] = {
"/home/samurain/htm_check/data_files/train/sequence1.train", 
"/home/samurain/htm_check/data_files/train/sequence2.train"};
}

const char SEQ_DELIM = ';'; 

struct Example
{
std::vector<int> stimulus;
std::fstream data;

bool clear() {stimulus.clear();} 

bool open_file(std::string & filename)
{
data.open(filename.c_str());
if (!data)
    {
        std::cout <<"error opening file\n";
        return false;
    }
std::cout<<"opening file... " <<filename <<" opened \n";
return true;
}

bool close_file()
{
std::cout<<"closing file... ";
data.close(); data.clear();
std::cout<<"closed\n";
return true;
}

bool read_next(Network * myNetwork, bool & new_seq)
{
if (!data)
{
    std::cout<<"file not opened" <<std::endl;
    return false;
}

if (data.peek() == SEQ_DELIM)
{
    data.ignore(100,'\n');
    myNetwork->clearStates();
    new_seq = true;
}

int number = 300; //assuming input will be integer values, not set to 0 for debugging purposes

std::string line;   

getline(data, line);

if (!data.good())
{
    std::cout<<"end of file reached" <<std::endl;
    return false;
}

std::stringstream ss(line);
while (ss)
{
    ss>>number;
    if (ss.good())
    {
        stimulus.push_back(number);
    }
}
return true;    
}//end read next
};//end of Example

---

Probably, the thing that Parallel Studio is complaining about is that you exposed the basic file operations (open, close, read) to any user of your class, making your Example class little more than a somewhat gimped wrapper around std::fstream with a little bit of data validation. In particular, you're not enforcing that users of Example call open and close in the right manner.

This doesn't bother valgrind because it's a very different tool. Valgrind watches your program as it runs to make sure that it doesn't happen to do anything stupid like leak memory or kernel resources, which presumably it doesn't. PS is doing some kind of static analysis to see if you made it possible to leak resources, which in this case you did (even though you don't then go on to actually exploit this possibility).

I would rewrite this class to be more C++ish. In particular, open_file() should be a constructor, not a method that could be called at any time. close_file() should equivalently be the destructor, rather than just some random method. This should satisfy Parallel Studio that kernel resources can't (usually) be leaked, unless the object itself is leaked (which it would presumably catch the possibility of someplace else, but in any case if the entire object is leaked, it's not your class's fault).

Not sure what PS is complaining about on the memory leak; that line looks fine to me. Unless there's something non-obvious about std::stringstream that I've forgotten.