[DUG] Unicode help in D7

[Jolyon Smith]

The problem with the "it just works" approach is that it only 'just works'
98% of the time.  For a large number of people that will be close enough to
100% that they won't even notice the 2%, but if/when you do run into that
2% the fact that you haven't had to understand or adapt anything leaves you
high and dry when it comes to understanding what's going wrong, how and how
to fix it.

All those oh-so-convenient automatic codepage conversions going on behind
the scenes are great, except when they are either unnecessary and merely
serve to exact a performance penalty you could do without, or actually
cause problems because your code knows better than the compiler what it is
doing and the compiler doesn't even take cues from your code to figure out
what *it* should be doing that you think your code already *told* it to do
so ends up doing what you don't expect but not telling you.

Not to mention the wholly confusing plethora of string related RTL routines
that we now have to live with.

Need to convert a Unicode string to Uppercase ?  That would be
ANSIUppercase() then, obviously.  Or ToUpper().  But to use ToUpper() you
have to turn your back on pre-Unicode compilers since it is wholly new and
lives in a newly introduced "Character" unit (why the contents of this unit
couldn't be added to StrUtils is anybody's guess).

So on the one hand, they went to all this effort to enable a "seamless
transition" to Unicode, but then to write Unicode handling code that
_actually_makes_sense you still have to make changes that amount to a
NO-OP, but you have to go searching for areas where these changes might be
desirable because the compiler will just continue compiling your old,
non-Unicode sensible code anyway.

A recipe for a great "open an old project and recompile" experience (i.e.
demo's), at the expense of a head-numbing, wall-denting "maintenance of
existing code especially where needed to share between pre and post Unicode
compilers" experience.

imho.  ymmv.

Your file streaming example is a good case in point:  "So I can recompile
and my project is automatically Unicode throughout?  'It Just Works' -
GREAT!!"  ... time passes ... "Hey, how come my file output is still not
Unicode ? What happened to 'it just works' ?" (then there's db schemas that
won't automatically "unicodify" on their own, but you code will "just work"
regardless).

The way they did the upgrade is convenient, but it's not consistent (there
may be reasons for the inconsistencies but they are still inconsistencies).
 In fact I seem to recall having seen a stackoverflow question that
involved this stream/stringlist encoding behaviour only earlier this week.


[ disclosure:  I have projects which deal with what most people would
consider very low level string handling and characteristics, so my
experience may be somewhat of a niche, but ime when the foundations are
shaky the wobbles are very often felt throughout the building even if it's
only the basement engineers that actually see the problems.  Those on the
top floor might even think the wobbles they occasionally feel are caused by
the wind - :) ]


On 4 October 2012 09:06, John Bird <johnkbird at paradise.net.nz> wrote:

>   Thats one of the advantages of how they did the upgrade – if you use
> the same D7 code on XE2/3 and using standard methods of writing to files
> such as FileStream or TStringlist.savetofile then you will find that the
> strings in memory are Unicode, and saved to disk will be ANSI by default
> (you have to specify to save as Unicode as a format to get it).   ie it is
> pretty close to “it just works”.  Source code similarly remains ANSI until
> you start saving Unicode strings – in that case it automatically switches
> to unicode.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20121004/9731db3e/attachment.html