[BCB C++] Dopisywanie lini \r\n danych do dużych pliku

[Darek_C++]

Tym razem chciał bym się dowiedzieć jak najlepiej obsłużyć dopisywanie nowych linii danych \r\n do pliku "tekstowego". Dopisywanie odbywać się będzie "z wątku" w metodzie zsynchronizowanej Synchronize(&DopiszDane); Chodzi o to, że pliki te będą robić się coraz większe powiedzmy 10K - 1M linii danych dlatego o to pytam.

[polymorphism]

Jeśli dopisywanie na końcu, to w czym problem?

[Darek_C++]

Nie wiem czy to jest problem dlatego pytam tutaj. Wydawało mi się, że jak chcemy dopisać musimy ten plik "otworzyć", więc im większy tym jego "otwarcie" zajmie więcej czasu / zasobów Rozumiem, że byłem w błędzie i nie tak sprawa wygląda ?

[Cyfrowy Baron]

Możesz posłużyć się klasą FILE, np:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

 void WriteToEndFile(char * fileName, char *Buf)
{
 FILE *fileStream;
 fileStream = fopen(fileName, "r+");

 fseek(fileStream, 0, SEEK_END);
 fwrite(Buf, sizeof(char), strlen(Buf), fileStream);

 fclose(fileStream);
}
//---------------------------------------------------------------------------
void __fastcall TForm1::Button10Click(TObject *Sender)
{
 AnsiString FileName = "c:\\test.txt";
 WriteToEndFile(FileName.c_str(), "przykładowy tekst\r\n" );
}

Podany wyżej kod działa tylko na plikach tekstowych zapisanych w ANSI, ale TEC++ chyba nie obsługuje Unicode.

Jeśli chodzi o Unicode to może to wyglądać tak:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

 void WriteToEndFile(wchar_t * fileName, wchar_t *Buf)
{
 FILE *fileStream;
 fileStream = _wfopen(fileName, L"r+");

 fseek(fileStream, 0, SEEK_END);
 fwrite(Buf, sizeof(wchar_t), wcslen(Buf), fileStream);

 fclose(fileStream);
}
//---------------------------------------------------------------------------
void __fastcall TForm1::Button10Click(TObject *Sender)
{
 String FileName = "c:\\test.txt";
 WriteToEndFile(FileName.c_str(), L"Tekst Unicode\x0D" );
}

Niestety tutaj mam problem o ile wprowadzenie znaku CR (x0D) nie jest problemem o tyle nie przyjmuje mi znaku LF (x0A), nie wiem dlaczego, a bez LF nie będzie łamania linii.

[Darek_C++]

A dlaczego zapis w C fopen() ?

[Cyfrowy Baron]

Po prostu jedna z możliwości.

[Darek_C++]

Myślałem, że dlatego akurat ta ze względu na jej wyróżniająca się wydajność w stosunku co do innych sposobów zapisu po pliku.

[Cyfrowy Baron]

Myślę, że jest wydajna, gdyż nie wczytuje całego pliku, a jedynie dopisuje do niego.

---

Mam pytanie do polymorphism: dlaczego nie wprowadza mi prawidłowo znaku LF - \x0A w przypadku kodowania Unicode? W kodzie go nie umieściłem, gdyż nie pojawia się w pliku jako LF lecz jako pusty znak.

[Cyfrowy Baron]

Chyba znalazłem rozwiązanie. Plik tekstowy kodowany w Unicode musi być traktowany jako binarny a nie tekstowy:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

void WriteToEndFile(wchar_t * fileName, wchar_t *Buf)
{
 FILE *fileStream;
 fileStream = _wfopen( fileName, L"rb+");

 fseek(fileStream, 0, SEEK_END);
 fwrite(Buf, sizeof(wchar_t), wcslen(Buf), fileStream);

 fclose(fileStream);
}
//---------------------------------------------------------------------------
void __fastcall TForm1::Button10Click(TObject *Sender)
{
 String FileName = "c:\\test.txt";
 WriteToEndFile(FileName.c_str(), L"Tekst Unicode\r\n");
}

rb+ lub r+b zamiast r+; rt+; r+t.

[polymorphism]

Możesz posłużyć się klasą FILE, np:

FILE to nie jest żadna klasa, to wskaźnik na strukturę definiującą strumień. Z klasami znanymi z C++ nie ma nic wspólnego.

(...) więc im większy tym jego "otwarcie" zajmie więcej czasu / zasobów

A po co co chwilę otwierać ten plik? Z drugiej strony nie sądzę, żeby czas otwierania pliku zależał od jego wielkości.

Myślałem, że dlatego akurat ta ze względu na jej wyróżniająca się wydajność w stosunku co do innych sposobów zapisu po pliku.

Strumienie C to takie same strumienie jak te z C++, jeśli mowa o ich wydajności lub niewydajności. Największą wydajność będziesz miał korzystając z funkcji systemowych... tylko czy Twój problem wymaga optymalizacji na tym poziomie? Nie sądzę.

dlaczego nie wprowadza mi prawidłowo znaku LF - \x0A w przypadku kodowania Unicode?

Być może dlatego, ponieważ używasz funkcji fwrite na strumieniu sformatowanym. Do niesformatowanego zapisu strumień powinien być otwarty w trybie binarnym. Do wyprowadzania ciągów unikodowych masz funkcję fputws, tyle tylko, że ona konwertuje ciąg do kodowania ANSI (nie wiem, czy w windowsie
jest możliwość użycia strumieni w trybie unikod <--> unikod). Ech, spóźniłem się...

[Cyfrowy Baron]

FILE to nie jest żadna klasa, to wskaźnik na strukturę definiującą strumień. Z klasami znanymi z C++ nie ma nic wspólnego.

Oh, oczywiście. W C+++Builder wszystkie klasy zaczynają się od T. Takie przejęzyczenie - jak zwykli mawiać politycy...

Do niesformatowanego zapisu strumień powinien być otwarty w trybie binarnym.

Tak, już sam na to wpadłem, w swoim poprzednim poście.

Do wyprowadzania ciągów unikodowych masz funkcję fputws, tyle tylko, że ona konwertuje ciąg do kodowania ANSI (nie wiem, czy w windowsie
jest możliwość użycia strumieni w trybie unikod <--> unikod).

Nie jestem pewien czy zrozumiałem o co Tobie chodzi. Funkcja fwrite działa prawidłowo i wprowadza mi do pliku znaki Unicode, testowałem np. na znaku: ﺹ - znak dobry jak każdy inny czcionka Arial - i został w tym pliku umieszczony. Wszystko więc już działa mi prawidłowo.

Z drugiej strony nie sądzę, żeby czas otwierania pliku zależał od jego wielkości.

Myślę, że Darek_C++ założył, że każde otwarcie pliku wiąże się z jego przetworzeniem, np. u mnie otwarcie pliku tekstowego o rozmiarze 54 MB w Notatniku trwa ~5 sekund, czyli w tym przypadku wielkość pliku ma wpływ na czas jego otwierania, a raczej ładowania.

[polymorphism]

Nie jestem pewien czy zrozumiałem o co Tobie chodzi. Funkcja fwrite działa prawidłowo i wprowadza mi do pliku znaki Unicode

Generalnie fwrite służy do wprowadzania danych binarnych, z tą jednak różnicą, że jeśli strumień pracuje w trybie tekstowym, znak \n jest zamieniany na ciąg \r\n _{(pod windowsem)}. Funkcja ta traktuje dane jako ciąg bajtów, zatem nie ma mowy, żeby poprawnie interpretowała 16-bitowe unikodowe znaki - unikodowy \u000A potraktuje jako ciąg 0A, 00, po konwersji wyjdzie 0D, 0A, 00, czyli wszystko się rozjedzie.

[Cyfrowy Baron]

Wciąż nie rozumiem. Przecież napisałem, że to działa. Sprawdziłem plik z danymi wprowadzonymi przez podany ostatnio przeze mnie kod i dane w pliku są umieszczane prawidłowo, a \r\n wprowadzają prawidłowo znaczniki CR+LF. W pliku pomocy jest napisane, żeby przy aktualizacji pliku tekstowego używać metod r+t, a przy aktualizacji pliku binarnego r+b. Jeżeli zamiast \r\n dam \x0a\x0d też znaczniki są prawidłowo dodawane. Zawartość pliku z widocznymi znacznikami sprawdzałem w programie Notepad++. Nie ma już chyba nad czym dyskutować, skoro to już działa prawidłowo.

[Cyfrowy Baron]

Jeszcze gwoli uzupełnienia:

po konwersji wyjdzie 0D, 0A, 00

Gdy plik tekstowy kodowany w Unicode otwierałem metodą r+ r+t, za pomocą funkcji write przy znacznikach \x0d\x0a na końcu pliku otrzymywałem CR . Przy metodzie r+b otrzymuję CRLF. W przypadku plików kodowanych w ANSI przy metodzie r+; r+t funkcja fwrite prawidłowo wstawia znaki końca czyli CRLF.

[Darek_C++]

Myślę, że Darek_C++ założył, że każde otwarcie pliku wiąże się z jego przetworzeniem, np. u mnie otwarcie pliku tekstowego o rozmiarze 54 MB w Notatniku trwa ~5 sekund, czyli w tym przypadku wielkość pliku ma wpływ na czas jego otwierania, a raczej ładowania.

Tak to nie myślałem, ale faktycznie myślałem, że zasoby związane "otwarciem" znacząco wpływa wielkość pliku. Wiec jak jestem przy tym temacie chciałem się dowiedzieć coś więcej na ten temat czy można to zrobić lepiej tzn szybciej i stąd ten post . Stawiałem na:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

ofstream outfile("C://loggg.txt", ios::app);
outfile <<" linia do zapisu\n";
outfile.close();