Major SVN update

[Steven Noonan]

Just committed some major changes to SVN, which I'm about to test on
Linux (confirmed working on Windows). This should resolve the issues
that Gonzo and OMouse brought up.

As always, SVN code is to be considered for testing only, and should
NOT be considered release-quality.

Please let us know if you encounter any problems with the SVN changes.

- Steven

[omo...@gmail.com]

On Nov 7, 4:31 am, "Steven Noonan" <steven.noo...@gmail.com> wrote:
> Just committed some major changes to SVN, which I'm about to test on
> Linux (confirmed working on Windows). This should resolve the issues
> that Gonzo and OMouse brought up.

Which issues are you talking about? The WCHAR stuff in
datastructures/rbtree.cpp? I figured out how to fix that last night but
I'm not sure if it's a proper fix (it does compile at least!).

-Rudolf

[Steven Noonan]

omo...@gmail.com wrote:

Just committed some major changes to SVN, which I'm about to test on
Linux (confirmed working on Windows). This should resolve the issues
that Gonzo and OMouse brought up.
    

Which issues are you talking about? The WCHAR stuff in
datastructures/rbtree.cpp? I figured out how to fix that last night but
I'm not sure if it's a proper fix (it does compile at least!).
  

I'm talking about the stupid reason for being forced to add -I/usr/include/crisscross to the command line. And, by the way, I am REALLY against using wchar_t in CrissCross. Here's why. Running 'gcc -E -dM - < /dev/null | sort' shows the following two defines inside it:

#define __WCHAR_MAX__ 2147483647
#define __WCHAR_TYPE__ long int

This means that we're not wasting TWO bytes for every character of text, we're wasting FOUR, as a quick test of mine proves:

steven@valhalla ~ $ ./test
sizeof(char) = 1
sizeof(wchar_t) = 4
sizeof(short) = 2
sizeof(int) = 4
sizeof(long) = 4

So this means that if we enter 256 bytes worth of data, we'll be wasting a full kilobyte for the sake of being able to use foreign character sets. That's an optimization failure, and I won't tolerate it. If I do implement WCHAR in all functions, it will be disabled in all release builds and only enabled when someone manually requests it by editing the universal_include.h.

- Steven

[Rudolf]

Well that's why we have the ENABLE_UNICODE flag, so that you don't have to worry about it.

[omo...@gmail.com]

Update: it seems GCC 4.x isn't compiled with wchar enabled and as
Steven says,"it's going the way of the dinosaurs". I'm going to Google
around to make sure of course. So yeah, no Unicode for us just yet.

[Steven Noonan]

Well, yeah. I mean, 4-byte wide characters? Who's insane enough to use that? That means a typical 255 character field would take just 4 bytes less than 1K of space in RAM, and 3 bytes of each character is wasted if the language in the field is English. Seems stupid to me.

- Steven