stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <>
Subject [jira] Created: (STDCXX-242) std::istream::get(unsigned char&) missing
Date Wed, 28 Jun 2006 20:49:29 GMT
std::istream::get(unsigned char&) missing

         Key: STDCXX-242
     Project: C++ Standard Library
        Type: Improvement

  Components: 27. Input/Output  
 Environment: all
    Reporter: Martin Sebor

Copied from the Rogue Wave bug tracking database:

Class/File: istream
Fix Priority: Must Fix
Long Description: 
  *** Sep 13 1999 1:51PM *** hanley ***

Deferred until further notice, on Martin Sebor's (RW Stdlib Tech Lead) advice.

  *** Apr 22 1999 2:04PM *** abrookes ***

According to Steve Clamage at Sun we can change the implementations of our stream classes
from typedefs to explicit specializations.  I assume that that extends to the streambuf that
are used to create them.  Doing this would allow us to easily implement the addtional signitures
requested by Sun.  It would also allow us to make simpler, faster implementations.  The current
implementations assume the general case where charT may have to be resized before insertion
and extraction from the streambuf.  Since this isn't necessary for narrow characters the specialization
can be much more efficient in space and time.

I think that it is important to add these specializations.  Before doing it, however, some
thought should be given to the overall scope of the changes so that the greatest savings can
be realized.

I would estimate that this will take at least a week of effort to implement these changes.

Specializations of various stream classes are required on types char
and wchar_t.  Section 17.4.3 allows user programs to specialize
standard templates inside namespace std only on user-defined types,
not on fundamental types.

Since no valid user program could detect whether you supplied
explicit char and wchar_t specializations or allowed them to be
generated from the template, the "as-if" rule (section 1.9) allows
the implementation to supply an explicit specialization.

Steve Clamage,

> Date: Wed, 21 Apr 1999 11:20:04 -0700 (PDT)
> From: Mukesh Kapoor <>
> Subject: RE: get(unsigned char&) not supported in istream [bug 4196970]
> To:
> Do you know which section of the standard allows explicit specializations
> in the standard library?  I looked in 17.4 but couldn't find
> anything about explicit specializations.
> Mukesh
> ------------- Begin Forwarded Message -------------
> From: Allen Brookes <>
> To: "'Mukesh Kapoor'" <>
> Subject: RE: get(unsigned char&) not supported in istream [bug 4196970]
> Date: Wed, 21 Apr 1999 11:01:48 -0700
> This sounds like a good solution.  I have tried to find where in the
> standard it specifies when explicit specialization can be used but
> haven't found it.  Do you have a reference for this?
> Allen
> -----Original Message-----
> From: Mukesh Kapoor []
> Sent: Wednesday, April 21, 1999 9:53 AM
> To:
> Cc: Stephen.Clamage@Eng.Sun.COM
> Subject: RE: get(unsigned char&) not supported in istream [bug 4196970]
> > We are having some trouble with this.  istream in the standard is a
> > typedef for basic_istream<char, char_traits<char> >.  This means that
> > any additions that we make to istream will also be in other
> > instantiations of basic_istream.  Having get(unsigned char&) doesn't
> > make sense for other instantiations.  There is a signiture for get
> with
> > charT& so that if we added this signiture and charT is unsigned char
> > then the signitures would be ambiguous.
> Allen,
> Here is a response from Steve Clamage:
>   From: Steve Clamage <>
>   The streams for char and wchar_t could be explicit specializations,
>   not just instantiations of the template.  It makes sense to
>   specialize them for efficiency, if not for any other reason.
>   In that case, it would be simple, and a good idea in my view, to add
>   additional functions to the char specialization.  The functions
>   get(unsigned char&) and get(signed char&) would be high priority
>   additions, for compatibility with classic iostreams.  Other
>   possibilities would be functions with unsigned char* parameters
>   paired with the existing char* versions.
>   Section of the C++ standard allows such additions. The
>   additions do not affect the behavior of any program that follows
>   the standard, but provide pure extensions.
> Hope this answers your question.
> Mukesh

  *** Apr 9 1999 4:54PM *** abrookes ***

Adding this will be kind of tough.  We can't add member functions to istream since istream
is a typedef.  Adding this version of get to basic_istream would make it available even for
wide characters which would make no sense.  Perhaps we can do this with some sort of specialization.

  *** Mar 23 1999 3:15PM *** abrookes ***

This is an enhancement request.  It is reasonable and can be done without violating the standard.

  *** Mar 23 1999 2:55PM *** abrookes ***

We implement versions of get listed in standard.  Need to determine if this is really a bug.

> The member function get(unsigned char&) is not supported in
> class istream. This works in classic iostreams and several
> existing programs use this functionality. The following small
> test case shows the problem:
> % cat t.c
> #include <iostream>
> #include <strstream>
> main() 
> {
>     using namespace std;
>     char  buffer[20] = "abcd";
>     strstreambuf  strbuf(buffer, sizeof(buffer));
>     istream    istr(&strbuf);
> #ifdef WORKS
>     char uc;
> #else
>     unsigned char uc;
> #endif
>     istr.get(uc);
>     cout << "uc=" << uc << endl;
> }
> % CC t.c
> "t.c", line 17: Error: Could not find a match for std::basic_istream<char, std::char_traits<char>>::get(unsigned
> "t.c", line 18: Warning: The variable uc has not yet been assigned a value.
> 1 Error(s) and 1 Warning(s) detected.
> % CC t.c -DWORKS
> % ./a.out
> uc=a
> Please implement get(unsigned char&) also in your sources. Thanks.
> Mukesh

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message