CEGUI (Crazy Eddie's GUI) Forums

Hey, this has likely been discussed but I couldn't find it anywhere on the board.

Wouldn't making a String constructor as such:

eliminate the need to to cast all my string literals to utf*?

Call me lazy but I don't wanna type that anymore.

Cheers,
Chris

I'll put a set of const char* overloads on the TODO list.

You can't reliably use the code you posted, since any character code >127 would trigger utf8 decoding on parts of the supplied data. It would need to be implemented as a seperate, properly imlemented, assign overload. Once this is put in I'll get people wanting the full set of overloads (which is to be expected), so if the job has to be done, I may as well do it properly

This will likely not get done for a little while, so in the mean time, you could add your 'temporary fix' constructor in there so that you don't sprain your fingers typing all those (utf8*) casts (just kidding ).

CE.

I'll put a set of const char* overloads on the TODO list.

Thanks!

You can't reliably use the code you posted, since any character code >127

Of course, but it would certainly handle all the string literals I'm typing in (since the lower 128 are the English chars). But you are very right. The correct way would be to implement it for real, rather than just the "easy" way. If I can finish my demo and have some time I'll give you a hand with that and send a patch. If that would be helpful, of course.

Meanwhile, I'll do some finger excercises to avoid those pesky coding injuries.... [up-down-up-down..]

cheers,
Chris

It should not be too much of a major job, I hope to get started on it tomorrow and have it done on Wednesday, I need to finalise some other changes for beta1 first.

CE.

I've had a look at this, and I'd strongly recommend putting those const char* functions in the CEGUI::String class ASAP, regardless of when the "proper" implementations are due. Probably also operator+ (two variantions) and operator+=. I've got a patch, but its trivial enough job as its only a couple of lines.

The main reason for it is that at the moment we're forced to add these ugly uft8* casts in every single line of client code that uses a string. These in turn will need to be pulled out of the client code at the time CEGUI::String adds the support - so its much better to wrap it now, and allow all the clients to use their const char* as nature intended.

Another point in favour is once you put it in, you see that there are quite a few implicit conversions going on from char*. For example, most exceptions are actually done in the following way:

This in turn gets converted to

These things are slipping through due to lack of constructors and operators involving native const char*. There is also an amusing case of char* + string + char*, which somehow gets through with another wily std::string cast. Well, its amusing to a programmer, I suppose.

For clients as well, the cast is incorrect - they don't have a utf8* at all. Its simply a hack, and given it is, its much better in a centralised place that is future proof (ie the string constructor), rather than in dozens of places that will need to all be removed at a later date (unless you want to end up with "dead wood" casts lying around the code).

Sorry to ramble on about a minor point like this after all your great work getting beta1 out (it kicks ass!), but this does affect almost a huge amount of calling client code, so its best to get the interface right as early as possible. The actual >127 conversion code is far less important at this stage, given nobody actually requires it, and it can be easily integrated into a string class that has previously set up the proper char* interface.

This work will be done over the weekend, and will be the "proper" versions. You won't need to rip out the casts when const char* support is added, character strings containing ASCII codes are properly encoded utf8, as as such it is a valid data buffer and not a hack; this was all done by design (see the discussion over on the Ogre forums), I didn't wake up one day and think, "oh dear, how am I going to allow string literals? I know, I'll put this in as a hack, that'll do." It was in fact a carefully weighed decision. The omission of const char* overloads was definately a mistake though.

Yeah, some of those implicit casts going on will possibly surprise a few people

With reference to what you say about codepoints > 127 being less important at this stage; I would image that some users on this forum would take exception to that

Anyway, thanks for the input. This should be in the system over the weekend.

CE.