What is g++ version of _wfreopen() and _flushall() please?

[Hongliang Wang]

Hi all,

Could anybody tell me if g++ has a wide char support version of freopen() and _flushall() function? Thanks.

[Jens Thoms Toerring]

Hongliang Wang <loud...@gmail.com> wrote:
> Could anybody tell me if g++ has a wide char support version of
> freopen() and _flushall() function?

It's not a question about g++ but about the C library you're
using with it, so a hopefully correct answer can only be "it
depends". If the library is the GNU C library (glibc) then
it supports a non-standard addition to the mode string for
fopen() and freopen(), ",ccs=string", where, citing from
the man page:

"'string' is taken as the name of a coded character set and
the stream is marked as wide-oriented."

There's no _flushall() function in glibc I've ever heard of,
this seems to be something Microsoft invented. Use fflush()
with a NULL pointer to flush all open *output* files - it
shouldn't matter if the file was opened with wide char sup-
port or not. Note that this only flushes the internal buf-
fers of the (GNU) C libraray, if you have to ensure that the
data are physically written to disk (as far as that is pos-
ible) you'll have to do an additional call of sync().

Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de

[Christopher Pisz]

On 11/24/2014 11:48 PM, Hongliang Wang wrote:
> Hi all,
>
> Could anybody tell me if g++ has a wide char support version of freopen() and _flushall() function? Thanks.
>

Why not program in C++ using std::wfstream ?

[Öö Tiib]

Perhaps because the difference between 'freopen' and '_wfreopen'
is only if *file* *names* and *modes* are given as wide character
strings or character strings (L"dick.jpeg" or "dick.jpeg"). Otherwise
it is a 'FILE*' that you get from both.

'wfstream::open' and 'fstream::open' however both take 'char*'
or 'std::string' as file name and the difference is in character
types that are streamed in those *text* streams (not too suitable
for neither L"dick.jpeg" or "dick.jpeg"). So the issue is in different
place sort of. ;-)

[Christopher Pisz]

Perhaps, but one would have to question why they'd have a project in
which they were giving parameters as wide strings, but not dealing with
the data as wide strings.

Furthermore, I'd suspect one would wish to receive the contents of a
.jpeg file as bytes rather than text :P