TITLE: ambiguity question on iostreams "put"

(Newsgroups: comp.std.c++, 25 Jun 97)

CHEN: Michael H. Chen

> Does anyone know what the current draft standard says about
> what sort of compliance compilers should for:
> 
> cout.put('A');
> 
> and
> 
> cout.put(65);
> 
> On my system, i can use the first example, but in order to do the second
> example, I am required to cast using:
> 
> cout.put(char(65));


CLAMAGE: Steve Clamage <stephen.clamage@eng.sun.com>

The "put" member function of ostream classes takes a character
parameter.
For cout, the character type is "char". A literal 65 has type int, and
the conversion from int to char is implicit. These points have remained
unchanged since the beginning of iostreams.

If 'A' has the int value 65, the two operations must be equivalent.

You don't say what your problem is, or what you mean by "required to
cast".  Does the program not compile?  Compile but not link?  Link but
not run?  Run but produce an unexpected result?

I can guess at two possibilities.

1. You get a warning about the implicit cast from int to char. A
compiler can warn about anything it likes ("Warning: this identifier
contains the letter 'z'.") as long as it accepts correct programs.
OTOH, the conversion of 65 to char cannot result in loss of data, so
that particular warning would be foolish and misleading.

2. The vendor has added an overloaded version of "put", and put(65)
either calls that new overload (unexpected program result) or yields
an ambiguity (program doesn't compile). Draft standard section 17.3.4.4
"Member functions" says an implementation can add new signatures for
member functions, but only if they don't change the behavior of valid
programs. Such an implementation of iostreams would violate the
draft standard.

To clarify the last point, a vendor might provide a _Date class,
and for some reason add "put(const _Date&)" to ostream classes.
That extension cannot change the behavior of any valid program,
and so would be allowed.