 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
stevejay
Guest
|
 Posted: Sat Nov 26, 2005 2:24 pm Post subject: stringbuf question |
 |
|
Hi,
Consider the following fragment of code (compiled on MVC++ 7.1):
#include <sstream>
int main()
{
typedef unsigned char byte_t;
std::basic_stringbuf<byte_t> my_stream;
unsigned char a = 254;
unsigned char b = 255;
if (my_stream.sputc(a) ==
std::basic_stringbuf<byte_t>::traits_type::eof())
throw 1;
if (my_stream.sputc(b) ==
std::basic_stringbuf<byte_t>::traits_type::eof())
throw 2; // throws
}
I'd really like to know why the second call to sputc() results in eof()
being returned and 2 being thrown, but by changing the first line of
main() to
typedef char byte_t
the code works (and I can get the correct values back from the
stringbuf using sbumpc()).
I came across this issue through testing some functions that operate on
streambuf objects to write integer values as a series of chars using
sputc(). It is convenient to use stringbufs for simple tests, rather
than, say, filebufs.
I had presumed that it would not matter what char type the
basic_stringbuf<> type was parameterised on. Any light that you can
throw on this would be great!
Bye,
Steve
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
James Kanze
Guest
|
| Posted: Sun Nov 27, 2005 4:00 am Post subject: Re: stringbuf question |
|
|
stevejay wrote:
| Quote: | Consider the following fragment of code (compiled on MVC++
7.1):
#include <sstream
int main()
{
typedef unsigned char byte_t;
std::basic_stringbuf
|
You just entered the world of undefined behavior here. There's
no guarantee that the above line will compiler, there's no
definition of what it does if it compiles, and there's nothing
you can add to the code which will change this.
This line is the exact equivalent of:
std::basic_stringbuf<byte_t,std::char_traits my_stream ;
And the standard doesn't define a generic instance for
std::char_traits, nor does it require an implementation to
provide one. All that is guaranteed are the specializations for
char and wchar_t.
At least some implementations (g++ and VC++, for example) DO
provide a generic version. From reports from others trying to
do what you are doing, their implementations are not compatible.
When all is said and done, your best bet is just to forget that
iostream's is a template.
| Quote: | unsigned char a = 254;
unsigned char b = 255;
if (my_stream.sputc(a) ==
std::basic_stringbuf<byte_t>::traits_type::eof())
throw 1;
if (my_stream.sputc(b) ==
std::basic_stringbuf<byte_t>::traits_type::eof())
throw 2; // throws
}
I'd really like to know why the second call to sputc() results
in eof() being returned and 2 being thrown, but by changing
the first line of main() to
typedef char byte_t
the code works (and I can get the correct values back from the
stringbuf using sbumpc()).
|
Well, if byte_t has type char, then basic_stringbuf<byte_t> is
in fact stringbuf. And of course, there's no undefined behavior
there.
| Quote: | I came across this issue through testing some functions that
operate on streambuf objects to write integer values as a
series of chars using sputc(). It is convenient to use
stringbufs for simple tests, rather than, say, filebufs.
|
I would expect that basic_filebuf<unsigned char> act the same
way as basic_stringbuf.
| Quote: | I had presumed that it would not matter what char type the
basic_stringbuf<> type was parameterised on. Any light that
you can throw on this would be great!
|
Just forget that you're dealing with a template. stringbuf and
wstringbuf work. It's possible to make basic_stringbuf and
basic_filebuf work with other types, but it is a lot of work.
Particularly in the case of basic_filebuf, which will ask the
locale for a codecvt<CharT, ???>, which you then have to
provide. (The ??? is mstate_t from the char_traits -- I forget
what it is called.)
--
James Kanze mailto: [email]james.kanze (AT) free (DOT) fr[/email]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
stevejay
Guest
|
| Posted: Sun Nov 27, 2005 5:57 pm Post subject: Re: stringbuf question |
|
|
| Quote: | I had presumed that it would not matter what char type the
basic_stringbuf<> type was parameterised on.
|
Oop, figured it out while I was waiting for my question to appear (I
checked the size of std::basic_streambuf<unsigned int>::int_type).
That allowed me to see it was a traits issue, and that only type char
has the correct specialisations.
Bye,
Steve
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Alberto Ganesh Barbati
Guest
|
| Posted: Sun Nov 27, 2005 5:57 pm Post subject: Re: stringbuf question |
|
|
stevejay wrote:
| Quote: | Hi,
Consider the following fragment of code (compiled on MVC++ 7.1):
#include <sstream
int main()
{
typedef unsigned char byte_t;
std::basic_stringbuf
unsigned char a = 254;
unsigned char b = 255;
if (my_stream.sputc(a) ==
std::basic_stringbuf<byte_t>::traits_type::eof())
throw 1;
if (my_stream.sputc(b) ==
std::basic_stringbuf<byte_t>::traits_type::eof())
throw 2; // throws
}
|
in this case it won't improve the result, but you should not compare
with plain == but with function
std::basic_stringbuf<byte_t>::traits_type::eq_int_type()
| Quote: | I'd really like to know why the second call to sputc() results in eof()
being returned and 2 being thrown, but by changing the first line of
main() to
typedef char byte_t
the code works (and I can get the correct values back from the
stringbuf using sbumpc()).
|
because b happens to have exactly the value traits_type::eof()
| Quote: | I came across this issue through testing some functions that operate on
streambuf objects to write integer values as a series of chars using
sputc(). It is convenient to use stringbufs for simple tests, rather
than, say, filebufs.
I had presumed that it would not matter what char type the
basic_stringbuf<> type was parameterised on. Any light that you can
throw on this would be great!
|
It seems that VC++ 7.1 implementation of char_traits<unsigned char> is
failing the following requirement of table 37 (21.1.1):
"X::eof() yields: a value e such that
X::eq_int_type(e,X::to_int_type(c)) is false for all values c."
so definitely it looks like a bug in the implementation.
Ganesh
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Carl Barron
Guest
|
| Posted: Sun Nov 27, 2005 5:58 pm Post subject: Re: stringbuf question |
|
|
stevejay <stevemjohns2003 (AT) yahoo (DOT) co.uk> wrote:
| Quote: | Hi,
Consider the following fragment of code (compiled on MVC++ 7.1):
#include <sstream
int main()
{
typedef unsigned char byte_t;
std::basic_stringbuf
unsigned char a = 254;
unsigned char b = 255;
if (my_stream.sputc(a) ==
std::basic_stringbuf<byte_t>::traits_type::eof())
throw 1;
if (my_stream.sputc(b) ==
std::basic_stringbuf<byte_t>::traits_type::eof())
throw 2; // throws
}
I'd really like to know why the second call to sputc() results in eof()
being returned and 2 being thrown.
|
first there is no gauarantee that blind coversion from
buffer_type::char_type to buffer_type::int_type works correctly. The
traits_type class provides conversion functions for this, and comparing
two buffer_type::int_types. There may be bugs in char_traits<unsigned
char> as I don't have mvc, I don't know. but cw 6.x with a working
std::char_traits<unsigned char> works with the following.
#include <iostream>
#include <sstream>
int main()
{
typedef std::basic_stringbuf<unsigned char> buffer_type;
typedef buffer_type::traits_type
traits_type;
typedef buffer_type::int_type
int_type;
unsigned char data [] = {'xfe','xff',' '};
buffer_type buf;
int_type eof = buffer_type::traits_type::eof();
for(unsigned char *p=data;*p;++p)
{
int_type c = traits_type::to_int_type(*p);
int_type d = buf.sputc(c);
if(traits_type::eq_int_type(d,eof))
{
std::cerr << "Error writing " << c << 'n';
}
}
for(int_type c =
buf.sbumpc();!traits_type::eq_int_type(c,eof);c=buf.sbumpc())
{
std::cout << c << ' ' ;
}
std::cout << "n Done n";
}
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
stevejay
Guest
|
| Posted: Sun Nov 27, 2005 9:54 pm Post subject: Re: stringbuf question |
|
|
stevejay wrote:
| Quote: | (I checked the size of std::basic_streambuf<unsigned int>::int_type).
|
Obviously I meant to write "I checked the size of
std::basic_streambuf<unsigned char>::int_type".
Bye,
Steve
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
stevejay
Guest
|
| Posted: Sun Nov 27, 2005 9:55 pm Post subject: Re: stringbuf question |
|
|
Carl Barron wrote:
<snip>
| Quote: | There may be bugs in char_traits<unsigned
char> as I don't have mvc, I don't know. but cw 6.x with a working
std::char_traits<unsigned char> works with the following.
#include <iostream
#include
int main()
{
typedef std::basic_stringbuf
typedef buffer_type::traits_type
traits_type;
typedef buffer_type::int_type
int_type;
unsigned char data [] = {'xfe','xff',' '};
buffer_type buf;
int_type eof = buffer_type::traits_type::eof();
for(unsigned char *p=data;*p;++p)
{
int_type c = traits_type::to_int_type(*p);
int_type d = buf.sputc(c);
if(traits_type::eq_int_type(d,eof))
{
std::cerr << "Error writing " << c << 'n';
}
}
for(int_type c =
buf.sbumpc();!traits_type::eq_int_type(c,eof);c=buf.sbumpc())
{
std::cout << c << ' ' ;
}
std::cout << "n Done n";
}
|
Hi,
FYI on MSVC++7.1, the above code results in "Error writing " being
printed when c is 0xff.
Bye,
Steve
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
P.J. Plauger
Guest
|
| Posted: Sun Nov 27, 2005 9:57 pm Post subject: Re: stringbuf question |
|
|
"Alberto Ganesh Barbati" <AlbertoBarbati (AT) libero (DOT) it> wrote
| Quote: | It seems that VC++ 7.1 implementation of char_traits<unsigned char> is
failing the following requirement of table 37 (21.1.1):
"X::eof() yields: a value e such that
X::eq_int_type(e,X::to_int_type(c)) is false for all values c."
so definitely it looks like a bug in the implementation.
|
Actually, an implementation is obliged to provide specializations
of char_traits only for char and wchar_t. We also provide a
template definition that happens to behave usefully in a number
of contexts, but that template is neither required to be present,
nor required to work completely right, nor forbidded to be
present. The "bug" is in the program, because it invokes
undefined behavior.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
James Kanze
Guest
|
| Posted: Mon Nov 28, 2005 8:24 am Post subject: Re: stringbuf question |
|
|
Alberto Ganesh Barbati wrote:
[...]
| Quote: | I had presumed that it would not matter what char type the
basic_stringbuf<> type was parameterised on. Any light that
you can throw on this would be great!
It seems that VC++ 7.1 implementation of char_traits<unsigned
char> is failing the following requirement of table 37
(21.1.1):
"X::eof() yields: a value e such that
X::eq_int_type(e,X::to_int_type(c)) is false for all values c."
so definitely it looks like a bug in the implementation.
|
Well, the standard doesn't require the implementation to provide
a generic implementation of char_traits, so as soon as you try
to use it, you encounter undefined behavior. In fact, I don't
quite see how you could define a generic implementation which
would guarantee that the above is true; you have to define an
int_type without knowing what the char_type is.
--
James Kanze mailto: [email]james.kanze (AT) free (DOT) fr[/email]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Carl Barron
Guest
|
| Posted: Tue Nov 29, 2005 1:12 am Post subject: Re: stringbuf question |
|
|
In article <438a33a3$0$12334$636a15ce (AT) news (DOT) free.fr>, James Kanze
<kanze (AT) none (DOT) news.free.fr> wrote:
| Quote: |
Well, the standard doesn't require the implementation to provide
a generic implementation of char_traits, so as soon as you try
to use it, you encounter undefined behavior. In fact, I don't
quite see how you could define a generic implementation which
would guarantee that the above is true; you have to define an
int_type without knowing what the char_type is.
The standard does specify what the members of char_traits<CharT |
repesent or do. It does not require char_traits
from char, wchar_t, but if char_traits<foo> is provided, the standard
specifies what each member of foo must do.
That said a simple int_type as as struct containing
the char_type and and an end of file indicator such as
template <typename CharT>
struct IntType
{
Chart c;
bool is_eof;
IntType(CharT a =CharT(),bool b=false):c(a),is_eof(b){}
};
typedef IntType<CharT> int_type;
seems to satisfy this [21,1.2 Jan 2005 draft] par 2, namely:
Requires: For a certain character container type char_type, a related
container type INT_T shall be a type or class
which can represent all of the valid characters converted from the
corresponding char_type values, as well as an
end-of-file value, eof(). The type int_type represents a character
container type which can hold end-of-file to
be used as a return type of the iostream class member functions.224)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Alberto Ganesh Barbati
Guest
|
| Posted: Tue Nov 29, 2005 10:18 am Post subject: Re: stringbuf question |
|
|
P.J. Plauger wrote:
| Quote: |
Actually, an implementation is obliged to provide specializations
of char_traits only for char and wchar_t. We also provide a
template definition that happens to behave usefully in a number
of contexts, but that template is neither required to be present,
nor required to work completely right, nor forbidded to be
present. The "bug" is in the program, because it invokes
undefined behavior.
|
I may agree on the fact that char_traits<unsigned char> is not required
to be present, but I disagree on the fact that (if present) it's not
required to work right. At least that's my interpretation of 21.1/4
(emphasis added):
"This subclause specifies a struct template, char_traits<charT>, and two
explicit specializations of it, char_traits<char> and
char_traits<wchar_t>, *all of which* appear in the header <string>
and *satisfy the requirements below*."
Despite academic arguments, providing something that "looks like" a
char_traits but really isn't is probably the best way to confuse the
final user. The OP of this thread is a clear example of that.
Just my opinion,
Ganesh
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Tue Nov 29, 2005 2:07 pm Post subject: Re: stringbuf question |
|
|
Alberto Ganesh Barbati wrote:
| Quote: | P.J. Plauger wrote:
Actually, an implementation is obliged to provide
specializations of char_traits only for char and wchar_t. We
also provide a template definition that happens to behave
usefully in a number of contexts, but that template is
neither required to be present, nor required to work
completely right, nor forbidded to be present. The "bug" is
in the program, because it invokes undefined behavior.
I may agree on the fact that char_traits<unsigned char> is not
required to be present, but I disagree on the fact that (if
present) it's not required to work right.
|
For what definition of "right"?
| Quote: | At least that's my interpretation of 21.1/4 (emphasis added):
"This subclause specifies a struct template,
char_traits<charT>, and two explicit specializations of it,
char_traits<char> and char_traits<wchar_t>, *all of which*
appear in the header <string> and *satisfy the requirements
below*."
Despite academic arguments, providing something that "looks
like" a char_traits but really isn't is probably the best way
to confuse the final user. The OP of this thread is a clear
example of that.
|
The problem is that the standard doesn't really define what a
generic version should do. A generic version which meets the
requirements given in table 37 of §21.1.1 for every possible
instantiation type is simply impossible. (How do you define
int_type, to_int_type, etc., when the character type is a user
defined type?)
Given all the confusion that it is causing, I suspect that not
providing a generic implementation at all is the best solution.
I'll admit that that wouldn't have been my opinion originally;
providing a generic implementation that worked for some specific
cases would have seemed a good thing. But then, I'm probably
more aware of the issues that some others -- it wouldn't occur
to me to try to use the generic type unless the implementation
documented its presence, and either the set of types for which
they had validated it, or a detailed description of what it did,
so that I could evaluate whether it fit my needs or not. I'm
not in the habit of using some random class without knowing
exactly what it does, AND I know enough of the standard here to
be aware that a truly generic implementation isn't possible.
As for the current problem: if the implementation explicitly
documents that char_traits can be instantiated over unsigned
char, then it is an error in the implementation if it cannot be.
If it documents that a generic version of char_traits exists,
with a list of legal instantiations which does not contain
unsigned char, then it is just as obviously an error in the user
code if it attempts to use it. If there is no documentation
(which is the case for g++, for example), then I think that
there is a weakness (a lack of quality) in the implementation,
but also that there is an unacceptable lack of rigor on the part
of anyone trying to use it.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Tue Nov 29, 2005 3:54 pm Post subject: Re: stringbuf question |
|
|
Carl Barron wrote:
| Quote: | In article <438a33a3$0$12334$636a15ce (AT) news (DOT) free.fr>, James Kanze
[email]kanze (AT) none (DOT) news.free.fr[/email]> wrote:
|
| Quote: | Well, the standard doesn't require the implementation to
provide a generic implementation of char_traits, so as soon
as you try to use it, you encounter undefined behavior. In
fact, I don't quite see how you could define a generic
implementation which would guarantee that the above is true;
you have to define an int_type without knowing what the
char_type is.
|
| Quote: | The standard does specify what the members of
char_traits<CharT> repesent or do. It does not require
char_traits<T> for types different from char, wchar_t, but
if char_traits<foo> is provided, the standard specifies
what each member of foo must do.
|
The standard is actually somewhat contradictory with regards to
what it requires. §21.1/1 says "This subclause [...] and
defines a class template char_traits<charT>, along with two
specializations, char_traits<char> and char_traits<wchar_t>,
that satisfy those requirements." According to this, the
generic implementation is required, and in the most of obvious
reading, must meet all of the requirements. (It is somewhat
ambiguous whether the "that satisfy those requirements" applies
only to what follows the "along with", or to all of the
preceding elements.)
The problem, however, isn't really there -- I think that there
is consensus that the standard only meant to require the two
explicit instantiations. The problem is that a "correct"
generic instantation is not possible; you can't correctly define
int_type, and the functions concerning it, without some concrete
knowledge or assumptions concerning charT. (There is also a
problem that the requirements on a character traits depend on
the character encoding, which doesn't necessarily depend on the
type.)
Arguably, this means that an implementation cannot provide a
generic version. Given the apparent confusion it causes, that
is certainly the route I'd go were I doing it today. A priori,
however, one might think that a generic implementation that is
good for some cases is better than no generic implementation at
all. That's certainly what I would have thought when I first
read this section of the standard.
If there is a flaw or an error in the Dinkumware (or the g++)
implementation, it is only that they didn't document the
restrictions. On the other hand, g++ (and, I suspect,
Dinkumware) don't document that the generic version exists; a
careful programmer will take the attitude that the standard
doesn't require it, and it's not documented, so I can't count on
it existing, or working correctly if it does exist. Strictly
speaking, for example, Dinkumware could say that the only valid
character values for their generic version are US ASCII,
regardless of the type. And I would say that unless there is
documentation stating what the valid character values are for a
given type, its behavior is fully unspecified, and I don't know
what to expect (and so cannot say whether the implementation is
correct or not).
| Quote: | That said a simple int_type as as struct containing the
char_type and and an end of file indicator such as
|
| Quote: | template <typename CharT
struct IntType
{
Chart c;
bool is_eof;
IntType(CharT a =CharT(),bool b=false):c(a),is_eof(b){}
};
|
| Quote: | seems to satisfy this [21,1.2 Jan 2005 draft] par 2, namely:
|
| Quote: | Requires: For a certain character container type char_type, a
related container type INT_T shall be a type or class which
can represent all of the valid characters converted from the
corresponding char_type values, as well as an end-of-file
value, eof(). The type int_type represents a character
container type which can hold end-of-file to be used as a
return type of the iostream class member functions.224)
|
That's a good point, and I think you're correct with regards to
the standard (so I have to take back that a generic version
isn't implementable). On the other hand, I do think that it
would violate a lot of user expectations. And the standard went
out of its way to allow an implementation to use a built-in
integral type for int_type, even when charT is the largest
integral type. (Note that the requirement isn't that int_type
must be able to hold all possible values of char_type, plus an
additional type, but only that it be able to represent all valid
characters, plus an end-of-file value.)
At any rate, it seems to be a univeral problem: both g++ and Sun
CC (the two compilers I have access to) have generic versions of
char_traits, which fail for certain types. At least for certain
definitions of "fail" -- to_int_type() returns a value which
compares equal to eof() for some value of the char_type, for
some char_type (even limiting char_type to the built-in integral
types). Like (apparently) Dinkumware, they both use a built-in
integral type for int_type (although not the same type).
The practical answer is simple: forget that the iostream and
string are templates, and only use the defined instantiations.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Carl Barron
Guest
|
| Posted: Wed Nov 30, 2005 10:54 am Post subject: Re: stringbuf question |
|
|
In article <1133263088.390322.313640 (AT) g47g2000cwa (DOT) googlegroups.com>,
kanze <kanze (AT) gabi-soft (DOT) fr> wrote:
| Quote: |
The problem is that the standard doesn't really define what a
generic version should do. A generic version which meets the
requirements given in table 37 of §21.1.1 for every possible
instantiation type is simply impossible. (How do you define
int_type, to_int_type, etc., when the character type is a user
defined type?)
int_type does not need to be a built in integral type although in |
many cases it could be. Therefore int_type can be a struct with
a charT and a boolean end of file indicator.
template <class CharT>
struct Int_type
{
charT char_value;
bool is_eof;
int_type(CharT a,bool b=false):char_val(a),is_eof(b){}
};
class char_traits<charT>
{
typedef charT char_type;
typedef typeame Int_type<charT> int_type;
static int_type eof() {return int_type(' ',true);}
static int_type to_int_type(char_type c) {return
int_type(c,false);}
static bool to_char_type(int_type c)
{ return c.char_value;}
static eq_int_type(int_type a,int_type b)
{
if(a.is_eof || b.is_eof) return a.is_eof==b.is_eof;
return a.char_value == b.char_value;
}
// ...
};
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Alberto Ganesh Barbati
Guest
|
| Posted: Thu Dec 01, 2005 1:14 am Post subject: Re: stringbuf question |
|
|
kanze wrote:
| Quote: | (Note that the requirement isn't that int_type
must be able to hold all possible values of char_type, plus an
additional type, but only that it be able to represent all valid
characters, plus an end-of-file value.)
|
I believe that's a key point. The standard fails to specify what are the
"valid characters". It's not even explicit for char and wchar_t! For
char the best bet is the basic execution character set, although one
would expect at least the execution character set (which however is not
guaranteed to fit in a char). Similarly for wchar_t. But for other
"character container" types, we really are in no-man's land.
In theory, Dinkumware could simply document that, as a "character
container type", unsigned char can hold values from 0 to 254 only. With
such restriction, the VC7.1 implementation would satisfy the
requirements in clause 21.1.1 (albeit it would not be very useful).
| Quote: | The practical answer is simple: forget that the iostream and
string are templates, and only use the defined instantiations.
|
I sadly but definitely agree.
Ganesh
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
