Darin Adler wrote:
On Jul 27, 2007, at 4:03 AM, Alexey Proskuryakov wrote:
On 7/27/07 1:51 PM, Simon Hausmann [EMAIL PROTECTED] wrote:
Does anybody know/remember why JSChar is defined to wchar_t on
Windows and if
it is still needed?
I think this was/is needed to match ICU's definition
On Friday 27 July 2007 11:51:40 Simon Hausmann wrote:
[...]
JavaScriptCore/API/JSStringRef.h:
...
#if !defined(WIN32) !defined(_WIN32)
typedef unsigned short JSChar;
#else
typedef wchar_t JSChar;
#endif
...
Quick wrap-up: We changed UChar in the Qt build on Windows to be also
Hi,
during our work on making the Qt port of WebKit compile on Windows with MSVC
and MingW g++ we ran into the following code in
JavaScriptCore/API/JSStringRef.h:
...
#if !defined(WIN32) !defined(_WIN32)
typedef unsigned short JSChar;
#else
typedef wchar_t JSChar;
#endif
...
JSChar
On Jul 27, 2007, at 4:03 AM, Alexey Proskuryakov wrote:
On 7/27/07 1:51 PM, Simon Hausmann [EMAIL PROTECTED] wrote:
Does anybody know/remember why JSChar is defined to wchar_t on
Windows and if
it is still needed?
I think this was/is needed to match ICU's definition of UChar
(Define
On Jul 27, 2007, at 7:45 AM, Darin Adler wrote:
On Jul 27, 2007, at 4:03 AM, Alexey Proskuryakov wrote:
On 7/27/07 1:51 PM, Simon Hausmann [EMAIL PROTECTED] wrote:
Does anybody know/remember why JSChar is defined to wchar_t on
Windows and if
it is still needed?
I think this was/is
On Jul 27, 2007, at 11:18 AM, Lars Knoll wrote:
I do understand this for your Windows port. In Qt we try to have the
same types across all platforms. This is also true for our QChar
abstraction that is built on top of an unsigned short. So for us
typedef'ing this to wchar_t is as wrong as
On Friday 27 July 2007 18:56:40 Darin Adler wrote:
On Jul 27, 2007, at 7:45 AM, Darin Adler wrote:
On Jul 27, 2007, at 4:03 AM, Alexey Proskuryakov wrote:
On 7/27/07 1:51 PM, Simon Hausmann [EMAIL PROTECTED] wrote:
Does anybody know/remember why JSChar is defined to wchar_t on
Windows and
I do understand this for your Windows port. In Qt we try to have the
same types across all platforms. This is also true for our QChar
abstraction that is built on top of an unsigned short. So for us
typedef'ing this to wchar_t is as wrong as unsigned short would be
for your windows port.
One last comment that might help.
The idea here is that this is a low level API. Lower level than, say,
the WebKit API. It's not built on top of the platform APIs like AppKit
on Mac OS X. The idea is that it's potentially independent of WebKit.
That's a good argument for having it match
On Jul 27, 2007, at 11:51 AM, Lars Knoll wrote:
Could you explain what you mean by 'good reason'?
A JavaScript engine API that isolates clients from implementation
details and can be potentially used cross platform is valuable. The
files in the API directory represent an attempt to create
On Jul 27, 2007, at 11:59 AM, Darin Adler wrote:
We were really following ICU's lead here -- ICU being another low
level library not built on top of a framework like Qt or AppKit.
I do see that. In Qt, although we have lot's of the same
functionality as ICU built in, we chose a
11 matches
Mail list logo
