Это утечка памяти?Утечка ресурсов ядра?(C ++, параллельная студия) - PullRequest
Новая
       25

Это утечка памяти?Утечка ресурсов ядра?(C ++, параллельная студия)

0 голосов
/ 22 апреля 2011

Справочная информация: я работаю над кодом для чтения данных из файла. Примеры данных разделены новыми строками. Кроме того, существует метауровень к данным, и точка с запятой действует как разделитель, чтобы указать, что конец последовательности достигнут. Файл содержит много последовательностей. Я хотел бы открыть файл, прочитать строку данных и сохранить ее как вектор, сделать что-то с данными, затем прочитать в следующей строке ... до конца файла.

Следующие компилируются нормально, и при запуске с valgrind на моем Linux-компьютере утечки памяти не обнаруживаются. Однако, когда я использую инструмент инспектора c ++ в Parallel Studio на компьютере моей лаборатории с Windows, он сообщает об ошибках, связанных с памятью, в моей программе, оба в этом файле.

Сообщается об утечке памяти, которая, кажется, происходит из строки: 

    ss>>number;

А также утечка ресурсов ядра сообщается со следующим: 

    data.open(filename.c_str());

Может кто-нибудь помочь мне понять, почему я получаю эти ошибки и что я должен сделать, чтобы исправить их? Я не понимаю, почему это утечка памяти, и еще менее уверен в ошибке ресурса ядра. Кроме того, если я делаю что-то невероятно глупое, не стесняйтесь, дайте мне знать! 

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

1 Ответ

0 голосов
/ 22 апреля 2011

Вероятно, на что жалуется Parallel Studio, так это то, что вы раскрыли основные файловые операции (открытие, закрытие, чтение) любому пользователю вашего класса, в результате чего ваш класс Example стал чуть больше, чем просто надульная оболочка вокруг std::fstream с небольшой проверкой данных. В частности, вы не обязываете пользователей Example правильно звонить open и close.

Это не беспокоит Вальгринда, потому что это совсем другой инструмент. Valgrind наблюдает за тем, как работает ваша программа, чтобы убедиться, что она не делает глупостей, таких как утечка памяти или ресурсы ядра, что, по-видимому, не делает. PS проводит какой-то статический анализ, чтобы выяснить, не сделали ли вы возможным утечку ресурсов, что в данном случае и произошло (даже если вы не используете эту возможность).

Я бы переписал этот класс для большего числа C ++. В частности, open_file() должен быть конструктором, а не методом, который может быть вызван в любое время. close_file() должен быть эквивалентным деструктором, а не просто каким-то случайным методом. Это должно удовлетворить Parallel Studio, что ресурсы ядра не могут (как правило) быть утечкой, если только сам объект не просочился (что он предположительно уловил бы возможность где-то еще, но в любом случае, если весь объект просочился, это не ваш класс неисправность).

Не уверен, что PS жалуется на утечку памяти; эта линия выглядит хорошо для меня. Если нет ничего неочевидного в std::stringstream, о котором я забыл.

...