dsp@bdal.de ("Daniel Kr   gler (ne Spangenberg)") wrote in message news:<40B58CE2.5010400@bdal.de>...
> Good morning, James Kuyper,
>
> James Kuyper schrieb:
..
> >That template interface only indicates that the default when a traits
> >class is not specifically provided is char traits<charT>. If it
> >weren't for 21.1p3, there'd be nothing in that interface to prohibit,
> >for example, basic string<char, char traits<wchar t> >.
> >
>
> Lets discuss this further. When I said "The class template interface
> from 21.3 is binding", I meant
>
> typedef typename traits::char type value type;
>
> This ensures, whatever traits::char type is (v.i.), it **must** be the
> same as std::basic string<>::value type.

Sorry - I thought that what you thought was binding was the use, in
the default value of the second argument, of charT. In other words, I
thought you were suggesting that since it was done for the default
argument, it must be done with any non-default argument provided by
the user. My objection doesn't apply to what you actually meant.

> >>- The interface description from 21.3 demands that traits::char type is
>
> >>the same as value type. ...
> >>
> >>
> >
> >No, it does not.
> >
> Very short, but less precise. Can you explain?

Sorry - I was confused, and for some reason thought you were referring
to the charT template argument, rather than to the value_type typedef.
The way I achieved that level of confusion is too complicated to
explain, and it doesn't make any sense, so please just ignore what I
said.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

dsp@bdal.de ("Daniel Kr   gler (ne Spangenberg)") wrote in message news:<40B2EAEA.9040800@bdal.de>...
> Good morning,  Prateek R Karandikar
>
> Prateek R Karandikar schrieb:
>
> >template<typename Ch, typename Tr = std::char traits<Ch>, typename A =
>
> >std::allocator<Ch> >
> >class std::basic string
> >{
> >  //..
> > public:
> >  typedef typename Tr::char type value type;
> >  //...
> >};
> >
> >In general, the type Ch may not be the same as the type typename
> >Tr::char type. Is there a requirement that these two be the same types?
>  If
> >yes, why this redundancy? If not, why this ambiguity?
> >
> >
>
> Both are the same. First consider the standard itself, The class
> template interface from 21.3 is binding:
>
> namespace std {
> template<class charT, class traits = char traits<charT>,
> class Allocator = allocator<charT> >
> class basic string {
> public:
> // types:
> typedef traits traits type;
> typedef typename traits::char type value type;
> ..
> };

That template interface only indicates that the default when a traits
class is not specifically provided is char_traits<charT>. If it
weren't for 21.1p3, there'd be nothing in that interface to prohibit,
for example, basic_string<char, char_traits<wchar_t> >.

> - The interface description from 21.3 demands that traits::char type is
> the same as value type. ...

No, it does not.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Good morning, James Kuyper,

James Kuyper schrieb:

>dsp@bdal.de ("Daniel Kr=FCgler (ne Spangenberg)") wrote in message news:=
<40B2EAEA.9040800@bdal.de>...
> =20
>
>>Good morning,  Prateek R Karandikar
>>
>>Prateek R Karandikar schrieb:
>>
>>   =20
>>
>>>template<typename Ch, typename Tr =3D std::char traits<Ch>, typename A=
 =3D
>>>     =20
>>>
>> =20
>>   =20
>>
>>>std::allocator<Ch> >
>>>class std::basic string
>>>{
>>>  //..
>>> public:
>>>  typedef typename Tr::char type value type;
>>>  //...
>>>};
>>>
>>>In general, the type Ch may not be the same as the type typename=20
>>>Tr::char type. Is there a requirement that these two be the same types=
?=20
>>>     =20
>>>
>> If=20
>>   =20
>>
>>>yes, why this redundancy? If not, why this ambiguity?
>>>=20
>>>
>>>     =20
>>>
>>Both are the same. First consider the standard itself, The class=20
>>template interface from 21.3 is binding:
>>
>>namespace std {
>>template<class charT, class traits =3D char traits<charT>,
>>class Allocator =3D allocator<charT> >
>>class basic string {
>>public:
>>// types:
>>typedef traits traits type;
>>typedef typename traits::char type value type;
>>..
>>};
>>   =20
>>
>
>That template interface only indicates that the default when a traits
>class is not specifically provided is char_traits<charT>. If it
>weren't for 21.1p3, there'd be nothing in that interface to prohibit,
>for example, basic_string<char, char_traits<wchar_t> >.
>

Lets discuss this further. When I said "The class template interface=20
from 21.3 is binding", I meant

typedef typename traits::char_type value_type;

This ensures, whatever traits::char_type is (v.i.), it **must** be the=20
same as std::basic_string<>::value_type.

21.1/p.3 Character traits says:

"To specialize those templates to generate a string or iostream class to=20
handle a particular character
container type CharT, that and its related character traits class Traits=20
are passed as a pair of
parameters to the string or iostream template as formal parameters charT=20
and traits. Traits::char_type
shall be the same as CharT."

The very last sentence of this paragraph implies, that the typename=20
char_type from the traits class (which
**must exist** according to table 37), must be the same as the CharT=20
template parameter **of the character
container**, which in this case is the basic_string<> class. And no: It=20
doesn't say, that the traits class
itself must be a instantiated from a template class and "traits<CharT>"=20
may or may not be a valid expression.

>>- The interface description from 21.3 demands that traits::char type is=
=20
>>the same as value type. ...
>>   =20
>>
>
>No, it does not.
>
Very short, but less precise. Can you explain?

Greetings from Bremen,

Daniel


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]