Build failed with JUCE_STRING_UTF_TYPE=16

Hi there,

I am on Windows with JUCE 4.1 using Visual Studio 2015. I add JUCE_STRING_UTF_TYPE=16 to preprocessor and encountered below build error:

: error C2039: 'CharPointer_ASCII': is not a member of 'juce::String' (compiling source file ..\..\..\third_party\juce\modules\juce_core\juce_core.cpp)
: note: see declaration of 'juce::String' (compiling source file ..\..\..\third_party\juce\modules\juce_core\juce_core.cpp)
: note: see reference to function template instantiation 'juce::String &juce::StringHelpers::operationAddAssign<int>(juce::String &,const T)' being compiled

 Can't reproduce this with JUCE 3.2 since it does not have StringHelpers::operationAddAssign. Thanks!

Thanks, we'll check that out.

But you should think twice before using utf-16 as the native format! It's generally acknowledged as the worst of both worlds: It wastes more space than utf-8 but still doesn't have the advantages of utf-32 in being able to map indexes directly to characters.

Sorry, I should point out that JUCE_STRING_UTF_TYPE=32 have same problem.

And thanks for the reminding of utf-16 usage. Our project should support both Mac and Windows and we are working on Windows version first. We must handle CJK strings while system locale set to English, which is the reason why I set JUCE_STRING_UTF_TYPE=16 since char can't handle the CJK well when system locale not match.

VC project is set to Treat WChar_t As Built in Type (/Zc:wchar_t) that made me think JUCE_STRING_UTF_TYPE=16 is the right choice. Now I am not so sure about this...

It sounds like you don't quite understand the purpose of that flag..

Regardless of what you set it to, the String class will have exactly the same behaviour and produce exactly the same results. There's nothing you can do with the UTF-32 flag set that you can't do with it set to UTF-8. It just packs the data differently internally.

The only possible reason for setting it to UTF-32 would be for optimising an application which does very heavy string manipulation that involves a lot of index look-up, and where memory size doesn't have an impact on performance. Unless you can measure a significant performance difference in your app when you change the flag, then don't touch it.

Personally, I'd prefer to remove these options and hard-code it to only use UTF8, which is generally agreed to be the best general-purpose format, and I find it hard to believe there are cases where anything else would be genuinely useful. But last time I threatened to do that a couple of people swore that they really did need the UTF-32 mode for performance reasons!

(BTW, I've fixed the original problem that you reported now)