cloudtrends / chromiumembedded

Automatically exported from code.google.com/p/chromiumembedded
1 stars 1 forks source link

String16 functionality is not available from CefString #217

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. In a client code define a string16 variable.
2. Pass string16 variable to constructor of CefString.
3. Build error.

What is the expected output? What do you see instead?
Compiler cannot find matching type. Expected that code already defined in 
cef_string_wrappers.h for working with string16 type would be compiled in.

What version of the product are you using? On what operating system?
CEF@216 on Mac. Win has same issues, but some methods somehow available only on 
Win (for WCHAR_T_IS_UTF32).

Please provide any additional information below.
Clients define USING_CEF_SHARED, but the string16-related code in 
cef_string_wrappers.h is conditionally compiled only when BUILDING_CEF_SHARED 
is defined. That seems strange and in my eyes it means that client code is not 
supposed to use string16 at all, while library itself it is ok.

Original issue reported on code.google.com by azasyp...@gmail.com on 12 Apr 2011 at 5:55

GoogleCodeExporter commented 9 years ago
string16 is an internal Chromium type defined in base/string16.h. On Windows 
std::wstring is a 16 bit value so string16 is defined as std::wstring on that 
platform. On Mac std::wstring is a 32 bit value so a separate string16 
definition is used.

The intent currently is that client applications will use the std::string or 
std::wstring types that most system libraries are designed to work with. Is 
there a particular reason why you need string16 for your application?

Original comment by magreenb...@gmail.com on 12 Apr 2011 at 6:18

GoogleCodeExporter commented 9 years ago
> Is there a particular reason why you need string16 for your application?
Our app is envisioned as a cross-platform and string16 seemed to be a good 
compromise between Mac and Win, staying consistent size across platforms. But I 
guess we can settle with native strings on each platform.

It just seems inconsistent that we include a file with some methods defined and 
implemented, but completely unavailable/compiled out for the app.

Original comment by azasyp...@gmail.com on 14 Apr 2011 at 3:21

GoogleCodeExporter commented 9 years ago

Original comment by magreenb...@gmail.com on 15 Jul 2014 at 9:37