See Matt Austern's column in May 2000 C++ Report. Or same article
reprinted in Appendix A of Scott  Meyers Effective STL. . To quote on
of the points made by Matt Austern:
"Case insensitivity isn't about an object, it's about how you use an
object"

On Thu, 6 Mar 2003 20:40:34 +0000 (UTC), brok@rubikon.pl ("Bronek
Kozicki") wrote:

>It's often desired to have non-standard behaviour of "string" class
>(like case insensitive comparision or non-standard character ordering) .
>Feasible and supported by standard library way to achieve this goal is
>to create new string type, using custome defined character traits.
>Example:
>typedef
>std::basic_string<char,ci_char_traits<char>,std::allocator<charT> >
>ci_string;
>
>Problem is, that ci_string conversion to/from std::string must be
>separately implemented, and cannot be "injected" into these classes. In
>any case I can think of, such conversion would make perfect sense.
>
>I propose to extend basic_string interface with one (or both) template
>member functions:
>
>1) copy constructor from "siblings" strings:
>template<class traits2> basic_string(const
>basic_string<charT,traits2,Allocator>& str2, size_type pos = 0,
>size_type n = npos, const Allocator& a = Allocator());
>
>This copy constructor can be made explicit. Allocator2 migh be used as
>second template parameter, to support conversion between strings with
>different allocation type.
>
>2) conversion:
>template<class charT, class traits2,class Allocator>
>convert(basic_string<charT,traits2,Allocator>& str2, const basic_string&
>str);
>
>Again Allocator2 migh be used as second template parameter.
>
>Both functions could be implemented in terms of already existing
>constructor:
>basic_string(const charT* s, size_type n, const Allocator& a =
>Allocator());
>
>If conversion between strings with different Allocator is to be
>performed, Allocator class suitable for destination string should be
>used.
>
>I hope this proposal makes some sense :)
>
>
>B.
>
>---
>[ 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                       ]

---
[ 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                       ]

It's often desired to have non-standard behaviour of "string" class
(like case insensitive comparision or non-standard character ordering) .
Feasible and supported by standard library way to achieve this goal is
to create new string type, using custome defined character traits.
Example:
typedef
std::basic_string<char,ci_char_traits<char>,std::allocator<charT> >
ci_string;

Problem is, that ci_string conversion to/from std::string must be
separately implemented, and cannot be "injected" into these classes. In
any case I can think of, such conversion would make perfect sense.

I propose to extend basic_string interface with one (or both) template
member functions:

1) copy constructor from "siblings" strings:
template<class traits2> basic_string(const
basic_string<charT,traits2,Allocator>& str2, size_type pos = 0,
size_type n = npos, const Allocator& a = Allocator());

This copy constructor can be made explicit. Allocator2 migh be used as
second template parameter, to support conversion between strings with
different allocation type.

2) conversion:
template<class charT, class traits2,class Allocator>
convert(basic_string<charT,traits2,Allocator>& str2, const basic_string&
str);

Again Allocator2 migh be used as second template parameter.

Both functions could be implemented in terms of already existing
constructor:
basic_string(const charT* s, size_type n, const Allocator& a =
Allocator());

If conversion between strings with different Allocator is to be
performed, Allocator class suitable for destination string should be
used.

I hope this proposal makes some sense :)


B.

---
[ 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                       ]