Hi, I知 trying to create a csv file in Unicode format. I知 using wofstream to create the file. I知 writing a series of strings and double values to the stream. I find that the values written to wofstream stop after writing 9 sets of data. There are about 37 sets of data. What could be the issue? The code that writes data to wofstream is as below: for ( int i=0; i<str.length(); i++ ) { wchar_t wc = ( str[i]<<16 ); os << wc; // os.seekp( -1, ios_base::cur ); } Where str: wstring. os: wofstream gcc version 3.4.4 20050721 (Red Hat 3.4.4-2) The above code is called 30-40 times for different values of str. If I uncomment os.seekp() statement, the file is zero bytes. os.fail() is not showing any error. Unable to figure where things are failing. I知 able to output contents of str on standard ouput. But not able to write to file completely. Regards, Radhika
You did not supply a full testcase so it is hard to tell what is going on. Can you produce a short testcase which shows the problem. It might be because the wide character is an invalid character. Since you are shifting the character by 16, I would almost say this is always going to be an invalid character. If str is already a wstring, then str[i] will already be a wchar_t and you don't have to shift the value.
Hi, Thanks for the reply. I would send the testcase soon. The issue seems to be that the output sent to wofstream stops updating the stream after certain number of characters. In our case it's after 400+ characters. Has anybdy else faced this issue before? I tried using flush(). This writes some more data to stream. But still lot of data is missing. How to sync the data in buffer with data written to file. Please let me know. Regards, Radhika (In reply to comment #1) > You did not supply a full testcase so it is hard to tell what is going on. Can > you produce a short testcase which shows the problem. It might be because the > wide character is an invalid character. Since you are shifting the character > by 16, I would almost say this is always going to be an invalid character. > If str is already a wstring, then str[i] will already be a wchar_t and you > don't have to shift the value.
Created attachment 17044 [details] The testcase for the current issue Please look into the code that's causing the issue. After outputting about 240 characters to file, the subsequent output is not written to the file.
Created attachment 17053 [details] Testcase which demonstrates the error The code writes the wstring "Forecast" 100 times to wofstream. When I executed the program it ouput the wstring 25 times and stopped. The wofstream doesn't set any error bit. Please let me know if there is some buffor which needs to be refreshed. How to do it? Regards, Radhika
Created attachment 17054 [details] nullcodecvt.h needed to compile linuxunicode.cpp
I can't reproduce, neither with stock FSF gcc3.4.6 neither with current gcc4.3.2 and mainline (I'm assuming you expect a 1002 bytes output). I suggest testing a current FSF GCC release, and file a new PR in case you are still having problems.
Hi Paolo, The expected result is the string "Forecast" should be output 100 times to wofstream. But it's ouput only 25 times. Regards, Radhika
As I said, I'm seeing the expected final size, that is 1002. Also, I don't think your testcase is correct, you don't want do_always_no_conv to return true, nothing takes care in your codecvt of packing of properly converting each in-memory wchar_t (4 bytes each) to the external chars you want.
... and, by the way, exactly because your codecvt is broken - doesn't properly convert each in-memory wchar_t to a single external char - you maintain to see 1 / 4 of the expected "Forecast" strings: actually you are seeing the expected total number of chars but each time, each char in "Forecast" is followed by 3 '\0' chars, the in-memory last three bytes of each wchar_t of L"Forecast".
Hi, I'm afraid if it's an issue with codecvt as such. The same code generates the expected ouput on all other unix platforms except Linux. The expected output is not 1002 bytes as suggested. Even if I output the string just 10 times, it outputs only once correctly and only few character from the second string is output. Regards, Radhika
Sorry, but I don't think your codecvt can wrok in any meaningful way as-is. Either you provide more information as to why - basing on the exact citations from the Standard - it should work, or we are not going to do anything.
(In reply to comment #3) > Created an attachment (id=17044) [edit] As others have mentioned, the codecvt facet in your test case is broken. The standard allows the codecvt::do_in() and do_out() members to return noconv only when both intern_type and extern_type are the same type.
Hi, Even if I avoid using our implementation of codecvt, i still get the same output of missing data. Regards, Radhika
Then, post your new (correct, I hope) codecvt
Feedback not forthcoming.