This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: user-defined types and basic_string
> User-defined constructors are not permitted in PODs.
> I think we don't really need the conversion function.
> To the above should just read
>
> struct character
> {
> unsigned short value;
> };
>
> Or, I think we could just put in a template surrogate for fundamental
> types:
>
> template<typename _Tp>
> struct character
> {
> T value;
> };
>
> along with the two functions:
>
> template<typename T>
> inline bool
> operator==(character<T> lhs, character<T> rhs)
> { return lhs.value == rhs.value; }
>
> template<typename T>
> inline bool
> operator<(character<T> lhs, character<T> rhs)
> { return lhs.value < rhs.value; }
Cool. I stand corrected.
> | // NB: this type should be bigger than char_type, so as to
> | // properly hold EOF values in addition to the full range of
> | // char_type values.
> | typedef unsigned long int_type;
>
> This makes the assumption that range(unsigned long) is a strict
> superset of range(unsigned short). If we were going to assume that,
> why not just use "int" as int_type?
Could do. (Unsigned int though if value_type == unsigned short, oui?)
It seems int_type is one of the points where the generic templates start
to fall down...
> From your yesterday mail, I thought you were talking of a generic way
> to define customization points of char_traits for users.
>
> Actually, I'm not convinced that we should make a big deal about
> defining a specialization for std::char_traits<>. Defining such a
> specialization just amonts to define a trait class in one's own
> namespace, but then there is no need to wrap the fundamental types in
> a struct. Thoughts?
I'm not quite sure I follow you. Can you give examples in C++?
-benjamin