Невозможно открыть файл, созданный с помощью ofstream

Не удается открыть файл .cpp в редакторе gedit в Ubuntu 11.10.
Файл был создан с помощью объекта ofstream в программе, которую я написал на C ++.
Программа компилируется и запускается без ошибок, после чего открывает файл,
читает из него построчно (добавляя каждую строку в объект std :: string) до
достигнув конца, затем возвращает строку в main (), которая затем
выводит его в отдельный файл, который он создает на жестком диске.
Однако при попытке открыть и отобразить файл в gedit редактор просто зависает
и никакой текст не отображается независимо от того, как долго я жду, и если я жду слишком долго, когда я пытаюсь
чтобы закрыть его, он скажет, что он не отвечает, и я должен заставить его выйти.
На значке предварительного просмотра файла в браузере файлов nautilus он показывает, что выходной файл имеет только одну строку текста, в то время как входной файл, конечно, показывает всю страницу, заполненную текстом. Это не должно иметь место, так как выходной файл должен содержать то же количество строк, что и входной файл, изменилось только несколько строк текста.

Кто-нибудь есть какие-либо идеи, что может быть причиной этого?

Обратите внимание, что входной файл довольно длинный и содержит 136871 строк кода, так что, возможно, это как-то связано с этим.

Вот код программы, которая создает выходной файл:

#include <iostream>
#include <fstream>
#include <string>

using namespace std;

string fixIssue_SegmentationFault(ifstream& file_handle);

int main() {

cout<< "Thank you for running FixC_html4_tagsIssues.\n""This little program has been written with the intent of fixing\n""the issues in the C_html4_tags.h file of the MAW programming project.\n"<< endl
<< "Please hit Enter to fix the detected issues." <<endl;
cin.get();

cout<< "Thank you. Please wait as it fixes the issues..." <<endl;
ifstream C_html4_tags_file_handle("/home/mobilexman/Documents/Programming_Projects/MAW/Modules/core/WebCoder_mod/modules/Html_coder/C_html4_coder/C_html4_elements/C_html4_tags/C_html4_tags.cpp");
string output_str = fixIssue_SegmentationFault(C_html4_tags_file_handle);
C_html4_tags_file_handle.close();

ofstream C_html4_tags_replacement_file_handle("/home/mobilexman/Documents/Programming_Projects/MAW/Modules/core/WebCoder_mod/modules/Html_coder/C_html4_coder/C_html4_elements/C_html4_tags/C_html4_tags_replacement.cpp");
C_html4_tags_replacement_file_handle<< output_str.c_str();
C_html4_tags_replacement_file_handle.close();

cout<< "Congratulations. The issues have been fixed." <<endl;

return 0;

}

string fixIssue_SegmentationFault(ifstream& file_handle) {

//////////////////
//Cause of issue:
/////////////////
///////////////////////////////////////////////////////////////////
//map<S_browser, TYPE_attr_values> attr_supported_attr_values_map;
//...
//TYPE_attr_values& attr_supported_attr_values = attr_supported_attr_values_map[dummy_browser];
//...
//attr_supported_attr_values.clear();
//attr_supported_attr_values_map.clear();
//...
//attr_supported_attr_values = attr_supported_attr_values_map[dummy_browser];
/////////////////////////////////////////////////////////////////////////////
//Explanation:
//Inside constructor of C_html4_tags, I created a map for the supported attr values of each Html attribute I created for each Html tag in the constructor.
//The map uses an S_browser object for its key and an object of TYPE_attr_values (which is a typedef of std::vector<S_html_attr_value>) for its mapped value.
//Therefore, I created a TYPE_attr_values& called 'attr_supported_attr_values' to reference the associated mapped value vector of the 'dummy_browser' object,
//which is just a dummy browser object I created so I could create a list of standard Html 4.01 attributes which exist in the specification for now, and later
//create a list of attributes from that list for each browser, according to which attribute values each browser supports (note: this will be done at the
//next level up: C_html4_elements). The code line
////////////////////////////////////////////////////////////////////////////////////////////////
//TYPE_attr_values& attr_supported_attr_values = attr_supported_attr_values_map[dummy_browser];
///////////////////////////////////////////////////////////////////////////////////////////////
//is where I first create that reference and initialize it to the returned reference of the [] operator of the map, which performs an insert operation if the key passed does not already exist inside the map.
//And the code line
//////////////////////////////////////////////////////////////////////////////
//attr_supported_attr_values = attr_supported_attr_values_map[dummy_browser];
/////////////////////////////////////////////////////////////////////////////
//is where I reinitialize (or at least that's what I thought it did when I first wrote the code...) the reference to the returned reference again, for each Html attribute after the first attribute.
//I then attempt to clear after each attribute operations both the referenced vector and then the map before reusing the reference 'attr_supported_attr_values'.
//However, that is what created the segmentation fault. It turns out you cannot use the same reference on more than one object, unlike pointers. So it is invalid to reinitialize that reference
//to point to a new object for each attribute, thus creating the problem. Oddly enough, though, doing this didn't actually produce any compiler errors. It compiles ok, but when attempting to run the program,
//it will return a message saying the program unexpectedly exited when running it normal, and you only get the extra info about the segmentation fault when running the debugger on it.  I'm not sure why
//that is, but its probably by design. And so it did take me a bit to figure out why the 'attr_supported_attr_values = attr_supported_attr_values_map[dummy_browser];' lines was producing the segmentation
//fault, especially since the attribute it ended on was not actually the second attribute of the first tag, but rather the first attribute of the second tag. I still don't know why that is, but at any rate,
//I believe that after I change the 'attr_supported_attr_values' identifier to a pointer instead of a reference, and adjust all lines using it to treat it as a pointer instead of a reference, the problem
//SHOULD be fixed. But we'll certainly see how it goes...

//////////////////////////
//Steps for fixing issue:
////////////////////////
//1. Read each line of C_html4_tags.cpp until reaching the end, checking each line as we go to see if it contains the target string content. In addition, add the content of each line (regardless of whether it contains the target or not)
//to output_str. Note that the target string content is first "TYPE_attr_values& attr_supported_attr_values = attr_supported_attr_values_map[dummy_browser];" which needs to be changed to
//"TYPE_attr_values* attr_supported_attr_values = &attr_supported_attr_values_map[dummy_browser];", and then is the
/////////////////////////////////////
//attr_supported_attr_values.clear();
//attr_supported_attr_values_map.clear();
/////////////////////////////////////////
//lines which needs to be changed to
///////////////////////////////////////
//attr_supported_attr_values->clear();
//attr_supported_attr_values_map->clear();
//////////////////////////////////////////
//2. If the target is found in the current line, perform the necessary changes to the line's content (i.e. buffer_str) before adding it to output_str.
//3. Return output_str.
string output_str;
string buffer_str;
string search_str1 = "TYPE_attr_values& attr_supported_attr_values = attr_supported_attr_values_map[dummy_browser];";
string replacement_str1 = "TYPE_attr_values* attr_supported_attr_values = &attr_supported_attr_values_map[dummy_browser];";
string search_str2 = "attr_supported_attr_values.clear();";
string replacement_str2 = "attr_supported_attr_values->clear();";
string search_str3 = "attr_supported_attr_values_map.clear();";
string replacement_str3 = "attr_supported_attr_values_map->clear();";
size_t pos;
while (getline(file_handle, buffer_str)) {
if (file_handle.good()) { //i.e. no errors while reading lines
if ((pos = buffer_str.find(search_str1, 0)) != string::npos) {
buffer_str.replace(pos, search_str1.size(), replacement_str1);
}

else if ((pos = buffer_str.find(search_str2, 0)) != string::npos) {
buffer_str.replace(pos, search_str2.size(), replacement_str2);
}

else if ((pos = buffer_str.find(search_str3, 0)) != string::npos) {
buffer_str.replace(pos, search_str3.size(), replacement_str3);
}
output_str += buffer_str;
}
}

return output_str;

}

0

Решение

Ваша проблема в том, что getline выдержки и выбросы терминатор строки, означающий, что в результате вы не найдете ни одной новой строки. По всей вероятности, это сделает GEdit очень несчастным (в результате вы увидите поведение, которое вы видели), так как он должен рассчитывать перенос строк для гигантского файла.

Следовательно, вы должны добавлять новую строку для каждой строки при построении выходной строки.

2

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]