How does fwrite handle tchar?

Investigate what it will take to port an app to use wide characters. I have a question on using tchar macro. Since tchar is really wchar_t or char depending on UNICODE #define, then does it mean when I write a block of memory containing say a tchar array, fwrite is actually going to write one file encoding with UNICODE and one without? That I do not need to use two different functions depending what tchar is correct?

Once the data is written, then it means a file I create in the US version of the product is different from say the Chinese version of it, is this correct?

Thanks in advance,

MC

if you have define UNICODE then it would write unicode if not then it wont. You should rememeber that fwrite has a paramater for the size of input your going to write. It will write the sizeof( UNICODE ) if UNICODE is defined and sizeof( CHAR ) if not.

It will write the sizeof( UNICODE ) if UNICODE is defined and sizeof( CHAR ) if not.

No it wont. fwrite() doesn't care whether UNICODE is defined or not, and it has absolutely nothing to do with a TCHAR.

fwrite() takes void* as its buffer parameter. Therefore it doesn't care about the type that gets passed to it. It's up to the programmer to specify the correct length accounting for UNICODE or not.

For example, to write a string to file:

Code:

TCHAR mystring[] = _T("Hi there");
int strlength = _tcslen(mystring);
fwrite(mystring,sizeof(TCHAR),strlength,fp);

What im talking about is

Code:

fwrite(mystring,sizeof(TCHAR),strlength,fp);
sizeof(TCHAR) would be write 1 byte(depends on the system) for evry element if UNICODE is not defined

and 2 bytes or whatever widechar is equivalent size to is if _UNICODE is defined.

I dont understand what your argument is. ??

*Edited

If your writing elements the size of a char then it would be char ofcourse if not then its in unicode. Whats hard to understand there??

Theres nothing to worry about fwrite not writing in UNICODe as long as UNICODE is defined. And your fwrite paraamaters are correct

Yes, but read what you wrote in your first post, the part I quoted in my post. My argument was with that quote which was clearly wrong. Maybe you just misworded your statement, but it came out sounding very misleading.

Originally Posted by bithub

Yes, but read what you wrote in your first post, the part I quoted in my post. My argument was with that quote which was clearly wrong. Maybe you just misworded your statement, but it came out sounding very misleading.

Must be my english. FYI english is not my first language so it must be it.

no worries

OK so from what I understand then if I have an application that creates a binary file (using fopen, fwrite, fclose...) currently and my data structure contains strings represented by the char data type, if I were to replace char with TCHAR, take care of the generic string function proptotypes etc...I can continue to use the existing fopen/fwrite/fclose to generate files. The only problem will be if I distribute the product in Asian countries it will create a file that contains data in unicode (since they will be running the Asian version created with the UNICODE preprocessor directive defined) whereas in the US it will create data in multibyte (since they will be running the US version created with UNICODE undefined). These two files obviously won't be compatible. Let's say for the moment this is not a concern as we do not anticipate files in different locales to be compatible. Do we need to do anything different when opening the file with fopen? or should fwopen/fwwrite be used?

MC