www.digitalmars.com         C & C++   DMDScript  

D - Casting arrays

reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
The D section on arrays mentions casting twice:
    1) Casting char[] to wchar[] and vice versa, where the original
value was a string constant
        (wchar[])"abc";   /* legal, creates a wchar string */
        (ascii)"\u1234";   /* illegal, can't cast non-ascii wchars to
ascii */
    2) Casting arrays to pointers
        char abc[];
        char *p = (char*)abc;

But can you can an array variable from one type to another?
    char abc[];
    ubyte other[] = (ubyte[])abc;  /* note: ubyte is 8 bits, just like
char */

The doc doesn't say (that I've found).  I think that you should be able
to do this, PROVIDED THAT the underlying types have the same size.

If we go with this rule, then we also can cast char[] to wchar[].  They
don't have the same size, so the compiler automatically rewrites the
char[] as the new wchar[] in a new array:
    char abc[] = "hi";
    wchar wabc[] = (wchar[])abc; /* wabc now = (wchar[])"hi" */

* Casts between types of the same size would NOT create a new array.
* Casts between char & wchar WOULD create a new array that has the same
string in the new representation

Now if we do this, I would also recommend that we not let numeric
operations on char or wchar anymore; instead, you cast them to an
integer:

    char abc[] = "asdf";
    abc += 1;  /* illegal, can't do numeric operations on char */
    ((byte[])abc) += 1;  /* legal, modifies the abc array */
        /* abc now = "bteg" */

--
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))) ]
May 01 2002
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
You should also be able to cast arrays of class references to arrays of
related class references, with the proper typechecking on each element (if
typechecking would have been done on a cast of a single reference).

--
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))) ]
May 01 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CD0174F.5E91B48B deming-os.org...
 The D section on arrays mentions casting twice:
     1) Casting char[] to wchar[] and vice versa, where the original
 value was a string constant
         (wchar[])"abc";   /* legal, creates a wchar string */
         (ascii)"\u1234";   /* illegal, can't cast non-ascii wchars to
 ascii */
     2) Casting arrays to pointers
         char abc[];
         char *p = (char*)abc;

 But can you can an array variable from one type to another?
     char abc[];
     ubyte other[] = (ubyte[])abc;  /* note: ubyte is 8 bits, just like
 char */

 The doc doesn't say (that I've found).  I think that you should be able
 to do this, PROVIDED THAT the underlying types have the same size.

 If we go with this rule, then we also can cast char[] to wchar[].  They
 don't have the same size, so the compiler automatically rewrites the
 char[] as the new wchar[] in a new array:
     char abc[] = "hi";
     wchar wabc[] = (wchar[])abc; /* wabc now = (wchar[])"hi" */

 * Casts between types of the same size would NOT create a new array.
 * Casts between char & wchar WOULD create a new array that has the same
 string in the new representation

 Now if we do this, I would also recommend that we not let numeric
 operations on char or wchar anymore; instead, you cast them to an
 integer:

     char abc[] = "asdf";
     abc += 1;  /* illegal, can't do numeric operations on char */
     ((byte[])abc) += 1;  /* legal, modifies the abc array */
         /* abc now = "bteg" */

Some good questions. I'll try to answer them with a more general statement. I'm uncomfortable with casting that results in data being allocated and copied - too much going on behind the scenes. I admit that's a philosophical point. The second is that, 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.
May 04 2002
next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ab1mag$s75$1 digitaldaemon.com...

 ...I think of chars more as a special type of integers
 than as actual characters.

That's your C heritage speaking :) -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
May 05 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"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. =)
May 05 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"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

 I can't do it!"

 I dont remember now who said it, but I second. =)

Ofcourse, but a cast isn't such a bad thing here is it? -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
May 05 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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  :)


 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.
May 05 2002
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "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  :)


 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.

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. -- 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))) ]
May 06 2002
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
 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

 *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
May 06 2002
parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:ab6fii$2fg9$1 digitaldaemon.com...
 Needing casts for ordinary mundane operations means there's a bug in



 language design.

..... 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

 *2* casts.


I don't think that's an ordinary operation.
 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

 2 bytes.

I'm ahead of you there, you can do arithmetic on void* as if they were byte pointers. This eliminates the misleading C eyesore of constant casting to (char*) when you are not accessing chars, but are doing pointer arithmetic.
May 09 2002
prev sibling parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"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  :)




 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
May 06 2002
next sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
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
May 06 2002
next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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))) ]
May 06 2002
prev sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3CD6DB74.3010802 estarcion.com...
 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

Maybe it should just be allowed to add chars to chars, then you can just typecast the thing you're adding in, like so: char b = a + '010'; or char b = a + cast(char)10; that's one less cast than is required if addition only works for ints, not chars. Fairly acceptable. Sean
May 07 2002
parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:ab8b1j$1bl5$1 digitaldaemon.com...
 "Russell Borogove" <kaleja estarcion.com> wrote in message
 news:3CD6DB74.3010802 estarcion.com...
 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




language design.

Yes, but of course it depends upon your definition of "ordinary



 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

Maybe it should just be allowed to add chars to chars, then you can just typecast the thing you're adding in, like so: char b = a + '010';

Hmm this doesn't look good to me...
 or

 char b = a + cast(char)10;

This looks good. Doesn't this already work? I think this is how it should be. Adding one char to another seems perfectly reasonable to me, especially now we have a dedicated concatenation operator, so there won't be any confusion. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
May 07 2002
prev sibling next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"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  :)




 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
May 06 2002
parent "Walter" <walter digitalmars.com> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:ab6lvs$2qp5$1 digitaldaemon.com...
 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...

Doing that makes it nice for overloading.
May 09 2002
prev sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:ab6g1s$2gau$3 digitaldaemon.com...

 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.  :-)

Is it? Sometimes, it is very convenient to operate on characters just as if they were numbers. Just consider converting string to integer...
May 06 2002
parent "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:ab7ia5$jo5$1 digitaldaemon.com...
 "Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
 news:ab6g1s$2gau$3 digitaldaemon.com...

 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.  :-)

Is it? Sometimes, it is very convenient to operate on characters just as if they were numbers. Just consider converting string to integer...

Well, that is normally done in some library so it is coded only a few times and thus is not mundane (no matter how many times the code is executed). I didn't say such things should be impossible, just that they aren't "mundane and ordinary". Also, except for hex values, the conversion of strings containing an "A" to an integer seems not very usefull. :-) -- - Stephen Fuld e-mail address disguised to prevent spam
May 06 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:ab3p6p$2p7t$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:ab1mag$s75$1 digitaldaemon.com...
 <SNIP>
 ...I think of chars more as a special type of integers
 than as actual characters.


Yes, it is. But remember I came to C from Pascal (I actually wrote a mini-Pascal compiler once), and never looked back.
May 05 2002
parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ab426p$310j$1 digitaldaemon.com...
 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:ab3p6p$2p7t$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:ab1mag$s75$1 digitaldaemon.com...
 <SNIP>
 ...I think of chars more as a special type of integers
 than as actual characters.


Yes, it is. But remember I came to C from Pascal (I actually wrote a mini-Pascal compiler once), and never looked back.

Can you discuss why? I am certainly not claiming that Pascal is "the perfect language", but IMHO, it is a better "starting point" for enhancement toward that goal than is C. See for example, the Turing language, which bears about the same resemblance to Pascal as D does to C. (that is, similar syntax, but clean up a lot of the cruft and add some important features.) http://www.holtsoft.com/turing/home.html Turing has objects without all the complexity of C++ and it supports those things necessary for writing system software (like type cheats and absolute addresses), without easily allowing people to get in trouble with them. (They have written an OS in it.) It also adds the DBC stuff and a lot of other nice things. Note that D has some things that I like that Turing doesn't, so this is not a slam toward D. Just pointing out another similar but different approach. -- - Stephen Fuld e-mail address disguised to prevent spam
May 07 2002
next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:ab92qn$213l$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:ab426p$310j$1 digitaldaemon.com...


 Yes, it is. But remember I came to C from Pascal (I actually wrote a
 mini-Pascal compiler once), and never looked back.

Can you discuss why? I am certainly not claiming that Pascal is "the perfect language", but IMHO, it is a better "starting point" for

 toward that goal than is C.  See for example, the Turing language, which
 bears about the same resemblance to Pascal as D does to C. (that is,

 syntax, but clean up a lot of the cruft and add some important features.)

Pascal's syntax is actually one of the things I do not like about it. begin and end just get to be a pain in the you-know-where and do not really add much. The way it handles semicolons in if..then..else statements are in my humble opinion very inconsistent and so do the semicolons between arguments in procedure and function declarations. For example, this is legal pascal: if i < 10 then WriteLn ('Yep it is smaller') // <-- no semicolon else WriteLn ('Nope, sorry it is larger'); but adding a semicolon where you think it should go is actually illegal. the then keyword ofcourse also totally sucks, C-s braces are much more elegant. Also parameters in procedure declarations: To me a semicolon means 'end of statement', but here this does not hold. Also the semicolon at the end of the signature seems strange to me. procedure DoSomething (i: integer; c: char); begin WriteLn ('Something'); end; But what *is* good about this is that it makes the signature exactly the same as the prototype, which really improves cut'n pastability. ;) But what about the totally redundant difference between a function and a procedure? I like the way a C procedure is implemented as a function that returns void. It is much more elegant. It might seem like I am trying to trash pascal, but actually I am really not. I often defend Delphi against C-minded friends, because I really love it. I particularly like things such as: - properties, also in D - published keyword - sets - method pointers, D has delegates - no fall-through switch - the Result variable - the way units work, C's #include sucks to the bone! D essentially does the same as Pascal. - the native string type D has arrays of chars which are capable of all important operations you might want to do on strings. Now you know why I am so enthousiatic about D! :) -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
May 07 2002
next sibling parent "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:ab97l5$25ee$1 digitaldaemon.com...
 "Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
 news:ab92qn$213l$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:ab426p$310j$1 digitaldaemon.com...


 Yes, it is. But remember I came to C from Pascal (I actually wrote a
 mini-Pascal compiler once), and never looked back.

Can you discuss why? I am certainly not claiming that Pascal is "the perfect language", but IMHO, it is a better "starting point" for

 toward that goal than is C.  See for example, the Turing language, which
 bears about the same resemblance to Pascal as D does to C. (that is,

 syntax, but clean up a lot of the cruft and add some important



Pascal's syntax is actually one of the things I do not like about it. begin and end just get to be a pain in the you-know-where and do not really add much. The way it handles semicolons in if..then..else statements are in my humble opinion very inconsistent and so do the semicolons between arguments in procedure and function declarations.

Then you might really like Turing. They eliminated the semicolons altogether and made the begin/end stuff consistant.
 the then keyword ofcourse also totally sucks, C-s
 braces are much more elegant.

Braces are an exact syntactical shortcut for begin/end in Turing. snip
 But what about the totally redundant difference between a
 function and a procedure? I like the way a C procedure is
 implemented as a function that returns void. It is much more
 elegant.

Well, that is really just syntax difference. Turing guarantees, (enforced at compile time) that functions (as opposed to procedures) have no side effects. This eliminates a lot of aliasing problems that cause bugs and hurt performance.
 It might seem like I am trying to trash pascal, but actually
 I am really not. I often defend Delphi against C-minded
 friends, because I really love it. I particularly like
 things such as:

 - properties, also in D
 - published keyword
 - sets
 - method pointers, D has delegates
 - no fall-through switch
 - the Result variable
 - the way units work, C's #include sucks to the bone!
   D essentially does the same as Pascal.
 - the native string type
   D has arrays of chars which are capable of all
   important operations you might want to do on strings.

 Now you know why I am so enthousiatic about D!  :)

I understand. You might enjoy checking out Turing for comparison. Unfortunately, it isn't open source or free, but it is low cost and there are some docs available free. -- - Stephen Fuld e-mail address disguised to prevent spam
May 07 2002
prev sibling parent "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"OddesE" <OddesE_XYZ hotmail.com> ha scritto nel messaggio
news:ab97l5$25ee$1 digitaldaemon.com...
 Pascal's syntax is actually one of the things I do not like
 about it. begin and end just get to be a pain in the
 you-know-where and do not really add much. The way it handles
 semicolons in if..then..else statements are in my humble opinion
 very inconsistent and so do the semicolons between arguments in
 procedure and function declarations.

 For example, this is legal pascal:

 if i < 10 then
   WriteLn ('Yep it is smaller')        // <-- no semicolon
 else
   WriteLn ('Nope, sorry it is larger');

mandatory here Curious, I think the same for C. In Pascal a block is a list of instructions, so you'll have: begin inst1 ; inst2 ; inst3 end. The same is for procedures or functions arguments: ( arg1 ; arg2 ; arg3 ), you have the same in C with the colon: ( arg1 , arg2 , arg3 ). Instead It's difficult to say when in C there is a need for semicolon: int f() { } // <-- no semicolon struct a { ... }; // <-- semicolon int g() { if (a < b) c = a; // <-- semicolon else { c = d; } // <-- no semicolon e = f; // <-- semicolon }
 but adding a semicolon where you think it should go is actually
 illegal. the then keyword ofcourse also totally sucks, C-s
 braces are much more elegant.

Braces are more small. And Pascal was designed when not all computer keyboards had braces on it (mine still today has not). [...]
 But what about the totally redundant difference between a
 function and a procedure? I like the way a C procedure is
 implemented as a function that returns void. It is much more
 elegant.

It seems more a trick... In original C there was no 'void' keyword, so no procedures at all. void was introduced to be more Pascal-like. Ciao
May 09 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:ab92qn$213l$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:ab426p$310j$1 digitaldaemon.com...
 Yes, it is. But remember I came to C from Pascal (I actually wrote a
 mini-Pascal compiler once), and never looked back.


Because it seemed I was always fighting the compiler in Pascal. With C, I was able to get around the typing system when I needed to. I might point out that no Pascal compiler was ever successful without a boatload of extensions. This was not true of C. In D, for every bit of safety the language gives you, you can get around it if you must.
May 09 2002
parent "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:abfovc$1q9q$1 digitaldaemon.com...
 "Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
 news:ab92qn$213l$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:ab426p$310j$1 digitaldaemon.com...
 Yes, it is. But remember I came to C from Pascal (I actually wrote a
 mini-Pascal compiler once), and never looked back.


Because it seemed I was always fighting the compiler in Pascal. With C, I was able to get around the typing system when I needed to. I might point

 that no Pascal compiler was ever successful without a boatload of
 extensions. This was not true of C.

 In D, for every bit of safety the language gives you, you can get around

 if you must.

Yes, Pascal doesn't give you enough freedom, but IMHO C gives you far too much. That is why I like Turning (Pascal with more freedom when you need it) and D (eliminates so of C's problems but still lets you get the job done). Both are "in between" Pascal and C, Turing being closer to Pascal, D being closer to C. -- - Stephen Fuld e-mail address disguised to prevent spam
May 10 2002
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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... -- 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))) ]
May 06 2002
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
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


 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

 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

 now has 'byte' and 'ubyte'
     * As strings - now D handles them much better than C, now almost no

 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...

May 06 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
"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))) ]
May 06 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"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


 better performed by some kind of lookup table though, especially for


 (though the table for Unicode should be sparse I suppose).

Shouldn't case conversion be handled by a library routine? Pass it an

 (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

 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
May 06 2002
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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))) ]
May 06 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"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
May 06 2002
parent Jonathan Andrew <jon ece.arizona.edu> writes:
 
 
 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
 
 

PHP is a lot of fun, especially the ability to change variable names inside your code! You could wreak a lot of havoc with that one... :)
May 06 2002