Steve Clamage wrote:
[ discussion of cout.put() called with int ]
> ... 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.

Idle curiousity: is it possible for an implementation to make such a
guarantee for signatures which include class (ie, not built-in) type
parameters?  I'm thinking this sort of thing:

class X {
public:
    void f(T const&);
    //  void f(T2 const&);  an implementation might want to add this (1)
};

// but a valid program might have done this
class myT2 : public T2 {
public:
    operator T();
};

// and used it this way
X x;
myT2 t;
x.f(t);

Adding line (1) would change the behavior of this valid program, albeit to what the user
probably wanted in the first place. So a confirming implementation is not permitted to add
it, right?


--
===============================================================
Stan Sulsky
          Current Technology, Inc.  |   -- sjs@curtech.com --
          97 Madbury Rd.            |   (603) 868-2270 - voice
          Durham, NH 03824   USA    |   (603) 868-1352 - fax
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Stan Sulsky wrote:
>
> Steve Clamage wrote:
> [ discussion of cout.put() called with int ]
> > ... 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.
>
> Idle curiousity: is it possible for an implementation to make such a
> guarantee for signatures which include class (ie, not built-in) type
> parameters?  I'm thinking this sort of thing:
>
> class X {
> public:
>     void f(T const&);
>     //  void f(T2 const&);  an implementation might want to add this (1)
> };

As you noted later in your article, a user might have defined a
class named T2 and this addition could create conflicts.

It seems to me that if a conforming implementation adds member
function signatures to a class, they cannot involve names from
the programmer's namespace.

For example, an implementation might declare a class called _Date
(a name reserved to the implementation) and add signatures involving
_Date without affecting valid C++ programs. Or it might add names
to namespace std and use those.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

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));

My question is, does the current draft standard require compiler makers
to accept just:

cout.put(65);

or does it specify at all?

Thanks.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

mhc@slip.net (Michael H. Chen) writes:

> 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));

The DWP provides basic_ostream::put(char_type), where char_type is
defined as char for streams and wchar_t for wide streams (see DWP,
sections 27.2 and 27.6.2.1).  My implementation (SunPro 4.2) provides
put(unsigned char) as well, leading to an ambiguity when typecasting
from int.

Hence, put(65) should IMHO work with the standard, but may not work
with current implementations.


--
______________________________________________________________________
Marcelo Cantos, Research Assistant       __/_  marcelo@mds.rmit.edu.au
Multimedia Database Systems Group, RMIT   /       _ Tel 61-3-9282-2497
L2/723 Swanston St, Carlton VIC 3053, Aus/ralia ><_>Fax 61-3-9282-2490
Acknowledgements: errors - me; wisdom - God; sponsorship - RMIT
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

mhc@slip.net (Michael H. Chen) wrote:

>My question is, does the current draft standard require compiler makers
>to accept just:

>cout.put(65);

>or does it specify at all?

Yes, it does specify, and in your example, put() should take a single
argument of type char.

In general, the signature for put() looks like:

    template <class charT, class traits = char_traits<charT> >
    class basic_ostream : virtual public basic_ios<charT,traits>
    {
      public:
        ...
        basic_ostream<charT,traits>&   put(char_type c);
        ...
    };

--Bob
====================================================================
Bob Steagall                                 steagall@deltalogic.com
DeltaLogic, Inc.                           http://www.deltalogic.com
1537 Kew Road                                   Voice (216) 321-8200
Cleveland Hts, OH 44118-1204                    Fax   (216) 321-6976
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Michael H. Chen wrote:
>
> 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));

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.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Marcelo Cantos wrote:
>
> mhc@slip.net (Michael H. Chen) writes:
>
> > 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));
>
> The DWP provides basic_ostream::put(char_type), where char_type is
> defined as char for streams and wchar_t for wide streams (see DWP,
> sections 27.2 and 27.6.2.1).  My implementation (SunPro 4.2) provides
> put(unsigned char) as well, leading to an ambiguity when typecasting
> from int.

There shouldn't be any ambiguity when typecasting. It's in the absence
of a typecast that the compiler can't determine whether to convert to
char or to unsigned char.
 -- Pete
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]