Re: Optimization of code
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Sat, 05 Sep 2009 12:18:44 -0400
It would also have been nice if the notion of derviation from CString had been a supported
concept...then you could do it yourself. Sigh.
joe
On Fri, 4 Sep 2009 23:43:58 -0700, "Tom Serface" <tom@xxxxxxxxxxxxx> wrote:
I guess the good news is most of my strings are in a string table anyway andJoseph M. Newcomer [MVP]
they finally got that right in the latest version. I try really hard not to
have static strings, but I hate it when I do something like:
CString cs;
cs.Format("%d",i);
And get like 10 lines of compiler error. I've seen it enough to just slap
myself and know what the problem is, but it's a drag to have to put the _T()
stuff in there for that. Since CString can convert back and forth it would
be nice to have an override that could take either kind of format string,
but still return the intended "formatted" string.
Tom
"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:pdg3a59af3ohv1a9nt4o6k049cmi898iga@xxxxxxxxxx
It would be interesting if there were a
#pragma strings(unicode)
so that with this pragma
"A"
would be interpreted as the current
L"A"
but then we'd have to add
S"A"
(or choose a letter of your choice) which would be interpreted as the
current
"A"
As usual, the problem is gigalines of legacy code.
For that matter, if the editor supports Unicode and the compilers support
it, I should be
able to write
int æíöø = ÿê_ólÞè_çûrìôsïtý_shòppë + 1;
(which is silly in the particular, but think of all those alphabets, such
as Norwegian,
Swedish, German, French, Hungarian, etc. that use accented characters).
We will know we
have true localization when you can take a C program shown with Japanese
identifiers,
copy-and-paste it from a document into a program where you've done the
same thing with a
German, Korean, and Arabic set of subroutines, and the whole thing
compiles and executes
correctly. [When I was Very Young, we had a French graduate student who
wrote some of our
code. All his variables and labels used French words. After he left, I
had to maintain
it. Fortunately, our project leader was Canadian, so he and I sat down
and used the
editor's "Replace" command until we had it in English. So I don't think
limited the
character set to American English characters makes code "more readable").
Right now, I
can't put a Lituanian name into a string and see what it really says,
because I have to
use \uXXXX to get some character in. I find this less readable than if
the native
characters were used.
joe
On Fri, 4 Sep 2009 07:07:20 -0700, "Tom Serface" <tom@xxxxxxxxxxxxx>
wrote:
I'm not advocating taking away the ability to do ANSI strings, just theJoseph M. Newcomer [MVP]
idea
that the default string type should be Unicode (or have the ability to
make
it so with a switch). I know this will never happen since it goes way
beyond
the standard, but ...
Tom
"r norman" <r_s_norman@xxxxxxxxxxx> wrote in message
news:q242a5hm649m9fl3vi0h7787915emctef2@xxxxxxxxxx
There exist many external devices that programs must communicate with
that require ASCII text strings as part of their protocol. Often
these have to be parsed for processing and character-by-character
manipulation alone would be a terrible burden. I can easily accept
switching to Unicode for all processes contained purely within the
local machine but it would be a disaster to lose ANSI support
altogether.
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- References:
- Re: Optimization of code
- From: Joseph M . Newcomer
- Re: Optimization of code
- From: Eddards
- Re: Optimization of code
- From: Giovanni Dicanio
- Re: Optimization of code
- From: Scot T Brennecke
- Re: Optimization of code
- From: Joseph M . Newcomer
- Re: Optimization of code
- From: Tom Serface
- Re: Optimization of code
- From: r norman
- Re: Optimization of code
- From: Tom Serface
- Re: Optimization of code
- From: Joseph M . Newcomer
- Re: Optimization of code
- From: Tom Serface
- Re: Optimization of code
- Prev by Date: Re: Optimization of code
- Next by Date: Re: Not call OnCtlColor
- Previous by thread: Re: Optimization of code
- Next by thread: Re: Optimization of code
- Index(es):
Relevant Pages
|