Re: [boost] Query for interest in including a shim class converting between char*, wchar_t*, string, wstring

Subject: Re: [boost] Query for interest in including a shim class converting between char*, wchar_t*, string, wstring
From: Zhi Tan (rockonedge_at_[hidden])
Date: 2011-08-25 10:16:24

>
> From: Yakov Galka <ybungalobill_at_[hidden]>
>
> On Thu, Aug 25, 2011 at 12:11, Tan, Tom (Shanghai) <TTan_at_[hidden]> wrote:
>
> > As a C++ programmer, often times there's a need to widen or narrow a
> > string to match some 3rd APIs. After writing similar code again and
> > again, I decided to have a wrapper to simplify this trivial but frequent
> > work, hence the TR and TR2 class.  Features include:
> >
>
> If something fails to compile, there must be a reason. Just shutting up the
> compiler doesn't make your code correct. What you're doing is like
> reinterpret_casting an int to float...
>
 no reinterpret_casting is involved here. it's just a wrapping of one of
basic_string's standard constructors.

template<class InputIterator> string (InputIterator begin, InputIterator end)
template<class InputIterator> wstring (InputIterator begin, InputIterator end)
and this usage is a distorted usage.

> [...]
> > -          Many Boost libraries (e.g. Boost.Test) that output plain
> > English (ASCII) message literals can be easily extended to support both
> > wide-char version with this class.
> >
>
> They don't have to support wide-char. Many programmers are not interested
> in
> any wide-char support at all. See
>
> http://programmers.stackexchange.com/questions/102205/should-utf-16-be-considered-harmful
>

As explicitly stated below,  it does not have anything to to with any
encoding/decoding of UNICODE and the like.
It only does widening and narrowing of *plain ACSII Engish text*, where the
operation does not change the meaning and readability of the  literals.

I can understand how some people can live without wide-char all life by
living in a culture where wide-char is not needed(e.g. English speaking
countries), or in a tech culture where UTF8 is used(Linux). But I happen to
live in a culture(Chinese language) where 16-byte wide-chars are a matter of
fact and easier to use. The default on Windows(UTF16) is implemented on
wide-char too. I believe there are many out there like me facing cases
where  *widening *the English text  is only need and correct enough.
While the scope is very specific, the need is real. Think of std::exception

class exception {public:
  exception () throw();
  exception (const exception&) throw();
  exception& operator= (const exception&) throw();
  virtual ~exception() throw();
  virtual const char* what() const throw();
}

exception::what() only returns narrow chars, many exception-derived
classes only provide simple English message too, where widening is
necessary my wide-char app.
The same goes to Boost Informational Macros
<http://www.boost.org/doc/libs/1_47_0/libs/config/doc/html/boost_config/boost_macro_reference.html>,
and compiler predefined macros.

Do not mistake it as a solution to endcodings or locale,
rather, it's a solution between char* and wchar_t*, when you know the
operation is safe,
which is usually the case of writing libraries, where messages are in
short and plain ASCII English literals.

> -          The 2 classes do not involve any encoding/decoding.
> >
>
>  tr.hpp:
>
> > * N.B. it doe not do any code conversion like: MBCS <--> UNICODE
> >
>
> This is just wrong. Your code is useless as it doesn't solve any real
> problem. This is not going to be accepted to boost, especially since it
> misguides programmers to write Unicode incorrect and *broken* code. Yes,
> you
> may find this library useful, and, say, half of non-expert programmers will
> find this library useful. The sad thing is that most of them just don't
> understand what Unicode is or what's text at all.
>

see above. This is NOT a code conversion solution, rather, a wrapping of
standard C++ solution for a real need.

>
> Btw, you're not the first to propose some kind of tools for 'Unicode
> support'. I can count at least 4 other proposals trying to solve different
> aspects by different means. None of them was accepted to boost yet.
>
> --
> Yakov
>
>
>