On Aug 9, 2007, at 2:30 AM, Artem Ananiev wrote:
You say WebKit tries to follow ICU's UChar. If so, the size of
wchar_t must be examined instead of just checking for WIN32 or _WIN32.
Good point. Seems worth fixing that at some point. I'd welcome a
patch that does that.
-- Darin
_
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 definitio
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
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 different
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
> > 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 wind
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 the
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 u
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
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 ne
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 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
UChar to be wchar_t if that is 16 bits wide; always assume
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
13 matches
Mail list logo
