API for stream (char vs wchar_t)
 

Dear all,

I am looking for suggestion on API recommendation when dealing with
filename. Should I expose an API with a char* or wchar_t (or both) to
my users ? Since I am reading image file (binary file), I would be
using std::ifstream, however std::ifstream API with wchar_t is only
available on Microsoft compilers.

Thanks for comments,

Re: API for stream (char vs wchar_t)
 

On Mon, 2011-02-14, mathieu wrote:
> Dear all,
>
> I am looking for suggestion on API recommendation when dealing with
> filename. Should I expose an API with a char* or wchar_t (or both) to
> my users ? Since I am reading image file (binary file), I would be
> using std::ifstream, however std::ifstream API with wchar_t is only
> available on Microsoft compilers.

What if you just let your API deal with istreams and ostreams, and
let the user do the opening of files (or whatever she chooses)?

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Re: API for stream (char vs wchar_t)
 

On Feb 14, 7:33*pm, mathieu <mathieu.malate...@gmail.com> wrote:
> Dear all,
>
> * I am looking for suggestion on API recommendation when dealing with
> filename. Should I expose an API with a char* or wchar_t (or both) to
> my users ? Since I am reading image file (binary file), I would be
> using std::ifstream, however std::ifstream API with wchar_t is only
> available on Microsoft compilers.

Plain English, no other languages? char*.

If not (welcome to the real world...)

It's much worse than streams having wchar_t version only with MS.
wchar_t means UTF-16 under Windows, and it means UTF32 under unix-like
systems. char* under Unix-like systems of today means UTF-8, and most
often means MBCS under Windows (UTF-8 is less often seen there).

So IMO... You need your code functionality (typically UTF-8 or 16;
note that ICU, Qt, Windows, Java and CLR use UTF-16), and you should
slap platform-specific layer on top of that.

Goran.

Re: API for stream (char vs wchar_t)
 

On Feb 14, 8:33*pm, mathieu <mathieu.malate...@gmail.com> wrote:
> Dear all,
>
> * I am looking for suggestion on API recommendation when dealing with
> filename. Should I expose an API with a char* or wchar_t (or both) to
> my users ? Since I am reading image file (binary file), I would be
> using std::ifstream, however std::ifstream API with wchar_t is only
> available on Microsoft compilers.

With file names and paths you can use boost::filesystem. It is quite
portable and supports wchar_t. char is "a byte" in C++. Does buffer of
bytes contain text and in what encoding that text is? That is meta-
information and C++ compiler does not help with it at all. wchar_t is
at least character type for compiler and if your users need particular
encoding somewhere then it is less error prone for them to convert
from wchar_t buffer than from char buffer.

Re: API for stream (char vs wchar_t)
 

On Mon, 14 Feb 2011 10:33:50 -0800, mathieu wrote:

> I am looking for suggestion on API recommendation when dealing with
> filename. Should I expose an API with a char* or wchar_t (or both) to my
> users ? Since I am reading image file (binary file), I would be using
> std::ifstream, however std::ifstream API with wchar_t is only available on
> Microsoft compilers.

char on Unix, wchar_t on Windows.

On Unix, filenames are strings of bytes with no associated encoding. On
Windows, they're wide-character strings.

Trying to use one approach on both operating systems will be sub-optimal,
although it may be close enough depending upon the application (e.g. for a
user-level application, you can probably assume that any filenames which
you encounter will be in the encoding of the locale, but that won't work
for an administrative utility, which may have to deal with files belonging
to various users, each using a different locale).