The only big one left that I can can think of is converting case.  This is better performed by some kind of lookup table though, especially for Unicode (though the table for Unicode should be sparse I suppose).

One other thing I see done often is converting from an int to a digit or from int to letter i.e.      value + '0'    or     value = entry - 'A'   but in those cases casts don't seem inappropriate.

Sean

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CD69A81.E649D7F@deming-os.org...
> Walter wrote:
>
> > ...in the past, I got pretty frustrated with Pascal
> > disallowing arithmetic operations on chars. All the casting necessary
just
> > wound up being an irritating eyesore. I think of chars more as a special type of integers than as actual characters.
>
> I think that if we look at D, most of the old needs for arithmetic
manipulation
> of chars is now gone.  Think of what chars were used for in C:
>     * As explicit 8-bit integers (since short might or might not be 8
bit) - D
> now has 'byte' and 'ubyte'
>     * As strings - now D handles them much better than C, now almost no
need for
> tests for the null terminator
>     * Comparing strings - not really needed if you have strcmp() or a D
> equivalent
>     * As cases in switch()es - but no reason that still can't work in D
>
> I don't think that you will need to cast chars to bytes very often in D...

> > Needing casts for ordinary mundane operations means there's a bug in the language design.
>
> Careful, Walter - that logic is a very slippery slope :)
>
>
>
> long *ptr;
> .....
> ptr = cast(long*)(cast(byte*)ptr +1 );   /* add one byte to the pointer */
>
>
>
> Remember, adding one byte to a pointer is a mundane operation...but it
requires
> *2* casts.

Should have declared it as a byte* then, not a long*.  It's gonna be slower to access unaligned longs anyway, that is, if it doesn't cause an unaligned memory access fault.

Yeah, you see this kind of stuff alot inside badly written file I/O routines.  But if written properly it would take 2 separate pointers but only one cast.

I think this has been addressed before, but math on void* should be identical to math on byte*.  i.e.   void* p;  p += 2;  should move p forward 2 bytes.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:ab426q$310j$2@digitaldaemon.com...
>
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:ab3v7p$2ug8$1@digitaldaemon.com...
> > "Pavel Minayev" <evilone@omen.ru> wrote in message news:ab3sve$2sgd$1@digitaldaemon.com...
> > > "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:ab3p6p$2p7t$1@digitaldaemon.com...
> > > > That's your C heritage speaking  :)
> > > "If I want to add 10 to 'A', it should be not the compiler who tells
me
> > that
> > > I can't do it!"
> > > I dont remember now who said it, but I second. =)
>
> Needing casts for ordinary mundane operations means there's a bug in the language design.

Yes, but of course it depends upon your definition of "ordinary mundane operations".  I think that if adding 10 to "A" is an ordinary mundane operation, there is a bug in the language design.  :-)

--
 - Stephen Fuld
   e-mail address disguised to prevent spam

"Sean L. Palmer" wrote:

> The only big one left that I can can think of is converting case.  This is better performed by some kind of lookup table though, especially for Unicode (though the table for Unicode should be sparse I suppose).

Shouldn't case conversion be handled by a library routine?  Pass it an array (could be a subrange of another array, of course).  If it gets inlined, it should be as fast as coding it by hand - and if it's in a library routine (i.e. rarely used directly), I don't mind it if it uses a few extra casts.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Stephen Fuld wrote:
> "Walter" <walter@digitalmars.com> wrote in message
> news:ab426q$310j$2@digitaldaemon.com...
>>
>>Needing casts for ordinary mundane operations means there's a bug in the
>>language design.
> 
> 
> Yes, but of course it depends upon your definition of "ordinary mundane
> operations".  I think that if adding 10 to "A" is an ordinary mundane
> operation, there is a bug in the language design.  :-)

Surely the mundanity of adding 10 to A is a question of
application domain, not language design? For example,
doing math on characters is the bread and butter of
crypto apps...

-RB

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:ab6g1s$2gau$3@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:ab426q$310j$2@digitaldaemon.com...
> >
> > "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:ab3v7p$2ug8$1@digitaldaemon.com...
> > > "Pavel Minayev" <evilone@omen.ru> wrote in message news:ab3sve$2sgd$1@digitaldaemon.com...
> > > > "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:ab3p6p$2p7t$1@digitaldaemon.com...
> > > > > That's your C heritage speaking  :)
> > > > "If I want to add 10 to 'A', it should be not the compiler who tells
> me
> > > that
> > > > I can't do it!"
> > > > I dont remember now who said it, but I second. =)
> >
> > Needing casts for ordinary mundane operations means there's a bug in the language design.
>
> Yes, but of course it depends upon your definition of "ordinary mundane operations".  I think that if adding 10 to "A" is an ordinary mundane operation, there is a bug in the language design.  :-)
>
> --
>  - Stephen Fuld
>    e-mail address disguised to prevent spam
>


I can go along in this. Adding ints to chars is in my
opinion not a normal operation, but maybe that is
because of the kind of code I write.
I was happy to learn that D defined a separate type
for byte and ubyte, instead of mixing it with char
like C does, like chars and bytes have anything to
do with each other conceptually...


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CD6C52D.512F96B@deming-os.org...
> "Sean L. Palmer" wrote:
>
> > The only big one left that I can can think of is converting case.  This
is
> > better performed by some kind of lookup table though, especially for
Unicode
> > (though the table for Unicode should be sparse I suppose).
>
> Shouldn't case conversion be handled by a library routine?  Pass it an
array
> (could be a subrange of another array, of course).  If it gets inlined, it should be as fast as coding it by hand - and if it's in a library routine
(i.e.
> rarely used directly), I don't mind it if it uses a few extra casts.
>
> --
> The Villagers are Online! villagersonline.com
>
> .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
> .[ (a version.of(English).(precise.more)) is(possible) ]
> ?[ you want.to(help(develop(it))) ]
>
>


I agree with you, casting doesn't seem inapproriate
to me at all when adding numbers and characters.
They are two different types, after all.
And come to think of it, I think that looking at it
from a purely theoretical perspective instead of an
implementation perspective, a character is much more
different from an int than a float. But having to
cast two int's to float when dividing them doesn't
seem inapproriate either:

int i = 10, j = 6;
double d = cast (double) i / cast (double) j;

Ofcourse for addition you do not need to cast.
I think in the end it is what you are used to.
Hell I am doing some PHP programming at the moment
and there you can pass an array of objects to
print() just fine. It will just print the
word 'array'!   :O


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

Russell Borogove wrote:

> Surely the mundanity of adding 10 to A is a question of
> application domain, not language design? For example,
> doing math on characters is the bread and butter of
> crypto apps...

Maybe for ROT13 crypto (wink)

I would argue that the vast majority of cryptography actually is performed on integers.  RSA & the like certainly don't care if your underlying data is character data or not.  They see it as numbers, and the interpretation of (and generation of) those numbers is an orthogonal problem.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

OddesE wrote:

> Ofcourse for addition you do not need to cast.
> I think in the end it is what you are used to.
> Hell I am doing some PHP programming at the moment
> and there you can pass an array of objects to
> print() just fine. It will just print the
> word 'array'!   :O

PHP is cool :)   Not exactly a very D-like language, but cool nonetheless.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CD6DEFC.B48B4051@deming-os.org...
> OddesE wrote:
>
> > Ofcourse for addition you do not need to cast.
> > I think in the end it is what you are used to.
> > Hell I am doing some PHP programming at the moment
> > and there you can pass an array of objects to
> > print() just fine. It will just print the
> > word 'array'!   :O
>
> PHP is cool :)   Not exactly a very D-like language, but cool nonetheless.
>
> --
> The Villagers are Online! villagersonline.com
>
> .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
> .[ (a version.of(English).(precise.more)) is(possible) ]
> ?[ you want.to(help(develop(it))) ]
>


Yeah it's cool! They took a lot of the syntax of
C, but dropped it's type system entirely.
They also have a great standard library.
They are very unix/linux oriented though, but
that's also refreshing. At least they try to remain
platform independant, something that cannot be
said for ASP.

--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail