James Kuyper wrote:
>
> Yura Koblents-Mishke wrote:
> [snip]
> >
> > But we are discussing another problem: the comparative
> > quality of the secondary sources, on-line helps and
> > newsgroups.
>
> You may be discussing that, but that's not what the original message was
> asking about. He said such things as: "what are the standard functions",
> "is [this] specific to Microsoft VC++", and "I am trying to write
> portable code", and "what is/are the alternative(s) that are compliant
> to the C++ standards?"  He was asking for specific information about
> standard requirements; at no point did he ask about the quality of
> different sources of that information.

You are right. After rereading it is clear that I
answered not to the original question, but to my own
reflections of the question. Mea culpa.


>
> > > Most compiler
> > > documentation I've read is less than clear as to the distinction between
> > > which features and behavior are required/allowed by the standard, and
> > > which ones are implementation-specific.
> > >
> >
> > Except when the compiler documentation explicitly
> > documents this distinction for every function in the
> > compiler library. And I'd dare to say that the MS-VC++
> > on-line documentation is very unambiguous and clear in
> > this respect.
>
> Not in the versions that I've seen, which are admittedly a bit old. The
> MSVC++ documentation I've got dates back to 1994. It labels every
> function for conformance with one of several different standards. It's a
> simple yes/no check-off. There's no detail distinguishing the parts of
> the function's description that describe behavior mandated by the
> standard, from the parts that are allowed by the standard but not
> mandated. There's very little if any description of the alternatives
> that are allowed by the standard, but which were not chosen by MS.
>

The OP asked: are wprintf and other two functions
standard, or MS_VC++ specific?

The MSVC++ on-line help unequivocally say: the
functions are compatible with ANSI C. For me this is
what OP asked about.

Yes, helps do not explain "to what extent compatible"
is the MS implementation of the standard functions. But
as well as I remember, we did not consider this here
either, except discussing one MS-specific extension for
the format specifiers (%S).


> > > > In your case, the VC++ helps for wprintf say (look
> > > > under "Compatibility") that this function is kosher,
> > > > i.e. ANSI C. The same with sprintf, fprintf.
> > >
> > > I'd not recommend trusting that.
> >
> > Trusting... in what and to what extent? After all, we
> > have to trust compilers at least in compilation.
>
> That's a dangerous attitude. I don't trust them. If something goes
> wrong, I investigate it. If the investigation points to the compiler,
> that's who I blame. I don't say "I trust the compiler, it must be right,
> I'll have to look elsewhere for the problem". I look to the standard
> first; I look to the compiler's documentation only after confirming what
> the standard behavior is. If the documentation is incompatible with the
> standard, I complain to the vendor.
>
> Compiler writers are human beings, just like me and (I presume) you.
> They make mistakes. They try to meet deadlines, and sometimes
> requirements aren't met because of schedule or budget constraints. On
> top of this, you have a corporation which is in fact trying to make C++
> identical to MSVC++. If they can do this by introducing differences from
> standard C++, thereby forcing sufficiently large fraction of the world
> to write code that can't be ported to a standard-conforming compiler,
> that's a gain in their eyes.
>
> Documentation is almost universally inaccurate. Some documents are
> better than others, but they all are somewhat out of sync with the thing
> they document.
>

Agree. But we have to live with this somehow. Who is
manually checking every line of code against the
Standard? Probably, not even you.

It happen that my time was wasted on the
compiler/library/documentation bugs; in early 90-th
this was not unusual. But, IMHO, I encounter my own
bugs three or four order of magnitude more often. This
is why I trust my compiler more than myself (-: and
even, dare I say, more than my wife! :-)


> > > The best source for determining
> > > standard conformance is the standard itself (which costs only $18 in PDF
> > > format in the US).
> >
> > But OP did not consult the Standard, he asked the
> > newsgroups.
>
> Apparently only because he didn't have a copy of the standard, didn't
> know where to get one, or felt that he needed guidance in interpreting
> it. His questions were about the standard. One of the primary purposes
> of this newsgroup is to provide a forum for asking such questions.
>
> > > This newsgroup is a good alternative source, so long
> > > as you can figure out which people to listen to and which to ignore.
> > >
> >
> > Let me reformulate the problem:
> >
> > Anybody agree that the most reliable source is the
> > Standard. But, given that OP clearly prefer other ways
> > (more accessible/fast/easier etc.), what is better: the
> > compiler documentation or this newsgroups? And is it
>
> This newsgroup - unambiguously. There aren't any standard conforming
> compilers out there yet. If the documentation is accurate, it will
> describe behavior inconsistent with the standard in some cases. If the
> documentation was last updated before the standard was approved (which
> is true of the documentation for most current implementations), then it
> won't even have a chance of containing a warning that this description
> conflicts with the standard.
>

Your objections make me rethink my position.

I still believe that the on-line helps are the first
thing to inquire - because this is very fast,
efficient, not interrupts much coding/debugging and
usually provides enough information to solve the
problem on hand. But in future I will attach to this
source a lesser weight.

[snip]
>
> Several people who participate regularly in this newsgroup know the
> standard much better than most compiler documentation writers. If you
> get an answer from one of them, believe it. The single most reliable
> one, in my personal opinion, is Steve Clamage. Other people are almost
> as reliable, but are more likely to state as fact things that are still
> controversial.


Thank you!

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> Yura Koblents-Mishke wrote:
> >
> > If you are using a compiler and helps are availeble,
> > use them. The info is, in theory, less reliable than
> > reading Standard, but, IMHO, good enough.
>
> Not if your objective is to determine standards compliance. The
> compiler's documentation documents its own behavior.

You want to say that, concerning the Standard
compliance, the most authoritative source is the
Standard itself. Who would object?..

But we are discussing another problem: the comparative
quality of the secondary sources, on-line helps and
newsgroups.

> Most compiler
> documentation I've read is less than clear as to the distinction between
> which features and behavior are required/allowed by the standard, and
> which ones are implementation-specific.
>

Except when the compiler documentation explicitly
documents this distinction for every function in the
compiler library. And I'd dare to say that the MS-VC++
on-line documentation is very unambiguous and clear in
this respect.

> > In your case, the VC++ helps for wprintf say (look
> > under "Compatibility") that this function is kosher,
> > i.e. ANSI C. The same with sprintf, fprintf.
>
> I'd not recommend trusting that.

Trusting... in what and to what extent? After all, we
have to trust compilers at least in compilation.

> The best source for determining
> standard conformance is the standard itself (which costs only $18 in PDF
> format in the US).

But OP did not consult the Standard, he asked the
newsgroups.

> This newsgroup is a good alternative source, so long
> as you can figure out which people to listen to and which to ignore.
>

Let me reformulate the problem:

Anybody agree that the most reliable source is the
Standard. But, given that OP clearly prefer other ways
(more accessible/fast/easier etc.), what is better: the
compiler documentation or this newsgroups? And is it
appropriate to suggest starting with helps? This is the
question!

IMHO, the on-line helps, as a rule, would win hands
down in the speed, accessibility and simplicity.
Though, in the reliability department, the jury is out.
IMHO.

Personally, I do not know the answer. Most probably, it
depends on vendor and on specific problem. For the
simpler ones the helps wins, for complicated the
newsgroups.

Most probably, I would use helps at first, than, if
this is really important, the Standard. Newsgroups,
IMHO, are the last resort: for contradictions, vague
wording, for what looks as unnatural behavior etc. And
I suggested to OP what I would do myself.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Yura Koblents-Mishke wrote:
>
> James Kuyper wrote:
> >
> > Yura Koblents-Mishke wrote:
> > >
> > > If you are using a compiler and helps are availeble,
> > > use them. The info is, in theory, less reliable than
> > > reading Standard, but, IMHO, good enough.
> >
> > Not if your objective is to determine standards compliance. The
> > compiler's documentation documents its own behavior.
>
> You want to say that, concerning the Standard
> compliance, the most authoritative source is the
> Standard itself. Who would object?..
>
> But we are discussing another problem: the comparative
> quality of the secondary sources, on-line helps and
> newsgroups.

You may be discussing that, but that's not what the original message was
asking about. He said such things as: "what are the standard functions",
"is [this] specific to Microsoft VC++", and "I am trying to write
portable code", and "what is/are the alternative(s) that are compliant
to the C++ standards?"  He was asking for specific information about
standard requirements; at no point did he ask about the quality of
different sources of that information.

> > Most compiler
> > documentation I've read is less than clear as to the distinction between
> > which features and behavior are required/allowed by the standard, and
> > which ones are implementation-specific.
> >
>
> Except when the compiler documentation explicitly
> documents this distinction for every function in the
> compiler library. And I'd dare to say that the MS-VC++
> on-line documentation is very unambiguous and clear in
> this respect.

Not in the versions that I've seen, which are admittedly a bit old. The
MSVC++ documentation I've got dates back to 1994. It labels every
function for conformance with one of several different standards. It's a
simple yes/no check-off. There's no detail distinguishing the parts of
the function's description that describe behavior mandated by the
standard, from the parts that are allowed by the standard but not
mandated. There's very little if any description of the alternatives
that are allowed by the standard, but which were not chosen by MS.

> > > In your case, the VC++ helps for wprintf say (look
> > > under "Compatibility") that this function is kosher,
> > > i.e. ANSI C. The same with sprintf, fprintf.
> >
> > I'd not recommend trusting that.
>
> Trusting... in what and to what extent? After all, we
> have to trust compilers at least in compilation.

That's a dangerous attitude. I don't trust them. If something goes
wrong, I investigate it. If the investigation points to the compiler,
that's who I blame. I don't say "I trust the compiler, it must be right,
I'll have to look elsewhere for the problem". I look to the standard
first; I look to the compiler's documentation only after confirming what
the standard behavior is. If the documentation is incompatible with the
standard, I complain to the vendor.

Compiler writers are human beings, just like me and (I presume) you.
They make mistakes. They try to meet deadlines, and sometimes
requirements aren't met because of schedule or budget constraints. On
top of this, you have a corporation which is in fact trying to make C++
identical to MSVC++. If they can do this by introducing differences from
standard C++, thereby forcing sufficiently large fraction of the world
to write code that can't be ported to a standard-conforming compiler,
that's a gain in their eyes.

Documentation is almost universally inaccurate. Some documents are
better than others, but they all are somewhat out of sync with the thing
they document.

> > The best source for determining
> > standard conformance is the standard itself (which costs only $18 in PDF
> > format in the US).
>
> But OP did not consult the Standard, he asked the
> newsgroups.

Apparently only because he didn't have a copy of the standard, didn't
know where to get one, or felt that he needed guidance in interpreting
it. His questions were about the standard. One of the primary purposes
of this newsgroup is to provide a forum for asking such questions.

> > This newsgroup is a good alternative source, so long
> > as you can figure out which people to listen to and which to ignore.
> >
>
> Let me reformulate the problem:
>
> Anybody agree that the most reliable source is the
> Standard. But, given that OP clearly prefer other ways
> (more accessible/fast/easier etc.), what is better: the
> compiler documentation or this newsgroups? And is it

This newsgroup - unambiguously. There aren't any standard conforming
compilers out there yet. If the documentation is accurate, it will
describe behavior inconsistent with the standard in some cases. If the
documentation was last updated before the standard was approved (which
is true of the documentation for most current implementations), then it
won't even have a chance of containing a warning that this description
conflicts with the standard.

> appropriate to suggest starting with helps? This is the
> question!
>
> IMHO, the on-line helps, as a rule, would win hands
> down in the speed, accessibility and simplicity.
> Though, in the reliability department, the jury is out.
> IMHO.

Several people who participate regularly in this newsgroup know the
standard much better than most compiler documentation writers. If you
get an answer from one of them, believe it. The single most reliable
one, in my personal opinion, is Steve Clamage. Other people are almost
as reliable, but are more likely to state as fact things that are still
controversial.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,

I understand that wchar_t is part of the standard C++ language types.
But I was wondering what are the standard functions that uses wchar_t
types.
Are  wprintf(), swprintf(), fwprintf(), part of the C++ Language
standard?
Also, is %S option in printf and wprintf  specific to Microsoft VC++?
I could not find any reference to these functions in the C++ Programming
Language book, 3rd edition.
I know that these functions exist in the VC++ compiler but I am not sure

if they exist in other C++ compilers on other platforms.  I am trying to

write a portable code so I am not sure whether I should be using
wprintf(), swprintf() to handle Unicode characters or something else?
what is/are the alternative(s) that are compliant to the C++ standards?
Any hints/suggestions are highly appreciated.

Thanks,

Hani



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hani Mawlawi wrote:

> Hi,

> I understand that wchar_t is part of the standard C++ language types.
> But I was wondering what are the standard functions that uses wchar_t
> types.
> Are  wprintf(), swprintf(), fwprintf(), part of the C++ Language
> standard?
> Also, is %S option in printf and wprintf  specific to Microsoft VC++?
> I could not find any reference to these functions in the C++ Programming
> Language book, 3rd edition.
> I know that these functions exist in the VC++ compiler but I am not sure
> if they exist in other C++ compilers on other platforms.  I am trying to
> write a portable code so I am not sure whether I should be using
> wprintf(), swprintf() to handle Unicode characters or something else?
> what is/are the alternative(s) that are compliant to the C++ standards?
> Any hints/suggestions are highly appreciated.

> Thanks,

> Hani

For wchar_t, the appropriate C++ I/O would be done using streams,
i.e. wcin/wcout IIRC. You'd need a wide string. std::string is just
a template instantiation using char, and there is a similar string
using wchar_t. This allows

wcin >> WideStringInput;
WideStringInput += L" was entered";
wcout << WideStringInput;

This should be portable. OTOH, a lot of issues regarding the
use of wchar_t's are not specified by the C++ standard.
(Like, how they look on screen)

Michiel Salters

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

If you are using a compiler and helps are availeble,
use them. The info is, in theory, less reliable than
reading Standard, but, IMHO, good enough.

In your case, the VC++ helps for wprintf say (look
under "Compatibility") that this function is kosher,
i.e. ANSI C. The same with sprintf, fprintf.


Not sure this is on-topic in this newsgroups, though.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hani Mawlawi wrote:
>
> Hi,
>
> I understand that wchar_t is part of the standard C++ language types.
> But I was wondering what are the standard functions that uses wchar_t
> types.
> Are  wprintf(), swprintf(), fwprintf(), part of the C++ Language
> standard?

Yes, and many more besides. The preferred way to use them is to bring
them into namespace std:

 #include <cwchar>

but they can also be brought into the global namespace using:

 #include <wchar.h>

> Also, is %S option in printf and wprintf  specific to Microsoft VC++?
> I could not find any reference to these functions in the C++ Programming
> Language book, 3rd edition.

"%S" is not described in the C++ standard, but that's not particularly
surprising; neither is "%s". For printf/scanf format strings, as with
most of the rest of the C standard library, the C++98 standard
cross-references the C90 standard, plus the later amendments. This
includes the amendment in the mid-90's which added <whcar.h>. I don't
have a copy of that amendment, so I can't verify whether it specified a
"%S" format string. However, the current C standard, C99, doesn't. From
context, I assume that "%S" is for wchar_t. C99 uses "%ls" for that
type, so I suspect that "%S" should be avoided, even if that is what the
earlier versions used.

> I know that these functions exist in the VC++ compiler but I am not sure
> if they exist in other C++ compilers on other platforms.  I am trying to
> write a portable code so I am not sure whether I should be using
> wprintf(), swprintf() to handle Unicode characters or something else?

If your characters are Unicode characters, you should use a standardized
Unicode library, something which is not currently part of the C++
standard library. There's no guarantee that wchar_t uses Unicode
encodings, nor event that it's big enough to do so. There is no standard
method for using Unicode in C++, though UCN's give the false impression
that there might be.

> what is/are the alternative(s) that are compliant to the C++ standards?
> Any hints/suggestions are highly appreciated.

The preferred method of dealing with wchar_t in C++ code is by the use
of wide streams and strings. The string and stream class templates
always come with two typedefs, one of which refers to the specialization
for 'char', and the other which has the same name prepended with a 'w',
for the specialization for 'wchar_t'. For instance,

 typedef basic_string<char> string;
 typedef basic_string<wchar_t> wstring;

For standard error, standard input and standard output, use wcerr, wcout
and wcin instead of cerr, cin, and cout.

Of course, this still doesn't cope with the Unicode issue; that remains
a complete mess. However, if you're willing to restrict yourself to
platforms where wchar_t uses a Unicode encoding, those will be the right
functions to use.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Yura Koblents-Mishke wrote:
>
> If you are using a compiler and helps are availeble,
> use them. The info is, in theory, less reliable than
> reading Standard, but, IMHO, good enough.

Not if your objective is to determine standards compliance. The
compiler's documentation documents its own behavior. Most compiler
documentation I've read is less than clear as to the distinction between
which features and behavior are required/allowed by the standard, and
which ones are implementation-specific.

> In your case, the VC++ helps for wprintf say (look
> under "Compatibility") that this function is kosher,
> i.e. ANSI C. The same with sprintf, fprintf.

I'd not recommend trusting that. The best source for determining
standard conformance is the standard itself (which costs only $18 in PDF
format in the US). This newsgroup is a good alternative source, so long
as you can figure out which people to listen to and which to ignore.

Microsoft wants to monopolize C++. They want their definition of C++ to
be THE definition of C++; compatibility with ISO C++ is a low priority
with them. Promoting an understanding of ISO C++ is even lower.

> Not sure this is on-topic in this newsgroups, though.

As you've re-defined the question, of course not. In it's actual form,
where the question was about standards conformance, it's very relevant.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hani Mawlawi <hmawlawi@wecan.com> wrote:
> Are  wprintf(), swprintf(), fwprintf(), part of the C++ Language
> standard?

Yes.

You can answer these questions for yourself, you know.  Buy the PDF version of
the C++ Standard, crank up the Acrobat reader, select "Find..." from the menu,
and enter "wprintf" in the dialogue box.

> Also, is %S option in printf and wprintf specific to Microsoft VC++?

Yes.  In Standard C++ there is no format specifier that means "a string of
characters of the opposite width".  In Standard C++ for both *printf() and
*wprintf() one uses the "%ls" format specifier for a string of wide characters
and the "%s" format specifier for a string of (narrow) characters.

> I am trying to write a portable code so I am not sure whether I
> should be using wprintf(), swprintf() to handle Unicode characters
> or something else?

Well, strictly speaking, you should bear in mind that you are not guaranteed
that an implementation uses Unicode for its wide character set, which rather
scuppers your whole idea of "portably" printing Unicode character strings
using wide characters.

However, if you aim for far less code portability (i.e. portability only to
those implementations that use Unicode for their wide character set), then you
will be able to achieve what you want to.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]