From: Yakov Galka <ybungalobill@gmail.com>

On Thu, Aug 25, 2011 at 12:11, Tan, Tom (Shanghai) <TTan@husky.ca> 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-consi...

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