CEGUI String vs std::wstring

[vasmann]

Hello.
I have a little question:
why you suggested to use your own String class versus standard string class?

As for me, in my program I have to use 2 classes that represent same data - String. More over I should write own converters. It is not a problem, but intresting why we should have 2 classes instead of 1.

Thank you.

(Frogive me for poor english)

[Das Gurke]

I asked me the same thing a while ago ... It seems that quite a few big libraries do their own stuff instead of using the STL. Why?

[vasmann]

I asked me the same thing a while ago ... It seems that quite a few big libraries do their own stuff instead of using the STL. Why?

Yes. They use std::map, std::vector, why don't they use std::string(wstring)? Very intresting.

[lindquist]

cegui uses unicode (utf8 or utf32)
string is ansi, wstring is something else. undefined. or for the most common case utf16 which we dont support.

HTH

[scriptkid]

Indeed, that is the main reason. If you search this forum for 'wstring', a few threads show up which also have some motivation explained.

More over I should write own converters. It is not a problem, but intresting why we should have 2 classes instead of 1.

Well, it's not that easy. But the aformentioned threads also have links to documentation about string convertions.

[dmail]

I asked me the same thing a while ago ... It seems that quite a few big libraries do their own stuff instead of using the STL. Why?

Yes. They use std::map, std::vector, why don't they use std::string(wstring)? Very intresting.

Really libraries which are dlls should not be using any part of STL and instead should roll there own.

Converting yourself using STL is very simple:

Code: Select all

   inline std::wstring  str2wstr(std::string const & s)
   {
       std::wstring r(s.size(),0);
       std::transform(s.begin(), s.end(), r.begin(), towlower);
       return r;
   }


[dearymz@163.com]

I really changed "CEGUI::String" to "typedef std::wstring String" every version of CEGUI in my projects, because of memory and time used.
And I dislike do this time and time again. So I hope CE think about this.

Thanks.

[CrazyEddie]

Official std::wstring support will never happen - for reasons discussed elsewhere, many times before.

Also, related to the reasons previously discussed and in response to your comment about memory usage: are you aware that on some compilers wchar_t (and therefore the internal representation of std::wstring) is a 32bit type? Thereby saving virtually no storage at all over CEGUI::String? All that happens in this case is we lose the utf8 support that CEGUI::String provides, and we would have to add external helper functions to provide that support instead.

So, the above paragraph highlights the issue with std::wstring perfectly. And I will briefly reiterate the problem: while std::wstring is 'standard' in the sense that the type exists in all standard C++ implementations, the actual representation and interpretation of the data stored is implementation defined - it can, and indeed does, vary according to the specific compiler in use. Which means to support it we need to have lots of compiler specific conditional code which can break easily, or not work at all should someone use a compiler (or some specific version) that we have not specifically tested and made a special case for.

CE.