Re: Char_traits (part 2+)

["Jack Reeves" <jack_reeves at hispeed dot ch>]

> The consensus seems to be that failing to provide a definition for
> char_traits<_CharT> is strictly conforming, although not all that
> friendly to users.
>
I'm afraid that I don't see how providing a definition either without an
implementation, or with one that generates a version that does not
meet the requirements is any friendlier.

>
> Right. Why should libstdc++ get in the way? Also, it's still not clear
> to me that people would be able to specialize if the generic template is
> defined before their specializations are declared.
>
You can add a specialization as long as it is done before any use of the
specialization occurs - more specifically before the compiler has a
reason to instantiate the generic version.

> Given the number of bug reports in this area I suspect you'd be
> surprised at the number of freaks doing this stuff. I certainly was.
>
It only takes one of us. Three's a crowd.

> Can "B" be provided as a generic skeletal stubs file that people fill in
> for their own types (as above) instead of explicitly instantiated into
> the libstdc++.so for all the builtin types?
No. I suggested it because I believe that the implementation (that's yoos
guys) can add explicit specializations for built-in types to namespace std.
Any attempt by users, no matter how they go about it, is undefined behavior.
I figure that line is in the Standard specfically to allow implementations
to
ignore the case where more than one user library trys to provide a
specialization for something like char_traits<unsigned char>.

> I'm curious: I don't feel like you addressed the issue of _Traits
> ambiguity in some of the locale facets (where _Traits is not a template
> parameter, but _Chart and _Iter (which itself has a _Traits param) are.)
> This came up in regards to your original email, where you used
> MyCharType, instead of a std::char_traits<MyCharType> specialization.
> What do you think about this?
>
I can not really address it yet because I have not investigated it enough.
My
suggestion that the library implementation should ignore the
char_traits::assign,
move, and copy functions came from what little investigation I have done.
I am pretty sure there are places where that has accidently been done
already.
I would like to suggest ignoring char_traits::length as well (BTW - found an
off-by-one bug in messages<>::to_string using length. If you don't patch it
I'll do it when I get CVS access working Real Soon Now). char_traits::eq,
lt, etc.
are harder. The whole issue of char_traits and facets strikes me as a mess.
I have to look into it, but haven't done so yet. Sorry.

Jack