D - Casting arrays
- Russ Lewis (35/35) May 01 2002 The D section on arrays mentions casting twice:
- Russ Lewis (8/8) May 01 2002 You should also be able to cast arrays of class references to arrays of
- Walter (9/39) May 04 2002 Some good questions. I'll try to answer them with a more general stateme...
-
OddesE
(10/12)
May 05 2002
"Walter"
- Pavel Minayev (5/6) May 05 2002 "If I want to add 10 to 'A', it should be not the compiler who tells me ...
- OddesE (11/17) May 05 2002 that
- Walter (4/13) May 05 2002 Needing casts for ordinary mundane operations means there's a bug in the
- Russ Lewis (12/25) May 06 2002 Careful, Walter - that logic is a very slippery slope :)
- Sean L. Palmer (11/19) May 06 2002 Should have declared it as a byte* then, not a long*. It's gonna be slo...
- Walter (9/20) May 09 2002 the
- Stephen Fuld (9/22) May 06 2002 me
- Russell Borogove (6/16) May 06 2002 Surely the mundanity of adding 10 to A is a question of
- Russ Lewis (11/15) May 06 2002 Maybe for ROT13 crypto (wink)
- Sean L. Palmer (10/26) May 07 2002 Maybe it should just be allowed to add chars to chars, then you can just
- OddesE (17/42) May 07 2002 the
- OddesE (15/39) May 06 2002 I can go along in this. Adding ints to chars is in my
- Walter (3/10) May 09 2002 Doing that makes it nice for overloading.
- Pavel Minayev (4/7) May 06 2002 Is it? Sometimes, it is very convenient to operate on characters just as
- Stephen Fuld (11/18) May 06 2002 Well, that is normally done in some library so it is coded only a few ti...
- Walter (4/10) May 05 2002 Yes, it is. But remember I came to C from Pascal (I actually wrote a
- Stephen Fuld (18/28) May 07 2002 Can you discuss why? I am certainly not claiming that Pascal is "the
-
OddesE
(56/67)
May 07 2002
- Stephen Fuld (17/64) May 07 2002 features.)
- Roberto Mariottini (33/51) May 09 2002 ^^^ semicolon is ...
- Walter (8/13) May 09 2002 Because it seemed I was always fighting the compiler in Pascal. With C, ...
- Stephen Fuld (12/26) May 10 2002 out
- Russ Lewis (16/20) May 06 2002 I think that if we look at D, most of the old needs for arithmetic manip...
- Sean L. Palmer (13/28) May 06 2002 The only big one left that I can can think of is converting case. This ...
- Russ Lewis (10/13) May 06 2002 Shouldn't case conversion be handled by a library routine? Pass it an a...
- OddesE (29/42) May 06 2002 is
- Russ Lewis (7/13) May 06 2002 PHP is cool :) Not exactly a very D-like language, but cool nonetheles...
- OddesE (15/28) May 06 2002 Yeah it's cool! They took a lot of the syntax of
- Jonathan Andrew (2/20) May 06 2002 PHP is a lot of fun, especially the ability to change variable names
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
Russ Lewis <spamhole-2001-07-16 deming-os.org> 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
"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
"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.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
"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
"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...thatThat's your C heritage speaking :)"If I want to add 10 to 'A', it should be not the compiler who tells meI 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
"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...Needing casts for ordinary mundane operations means there's a bug in the language design."OddesE" <OddesE_XYZ hotmail.com> wrote in message news:ab3p6p$2p7t$1 digitaldaemon.com...thatThat's your C heritage speaking :)"If I want to add 10 to 'A', it should be not the compiler who tells meI can't do it!" I dont remember now who said it, but I second. =)
May 05 2002
Walter wrote:"OddesE" <OddesE_XYZ hotmail.com> wrote in message news:ab3v7p$2ug8$1 digitaldaemon.com...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))) ]"Pavel Minayev" <evilone omen.ru> wrote in message news:ab3sve$2sgd$1 digitaldaemon.com...Needing casts for ordinary mundane operations means there's a bug in the language design."OddesE" <OddesE_XYZ hotmail.com> wrote in message news:ab3p6p$2p7t$1 digitaldaemon.com...thatThat's your C heritage speaking :)"If I want to add 10 to 'A', it should be not the compiler who tells meI can't do it!" I dont remember now who said it, but I second. =)
May 06 2002
requiresNeeding 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
"Sean L. Palmer" <spalmer iname.com> wrote in message news:ab6fii$2fg9$1 digitaldaemon.com...theNeeding casts for ordinary mundane operations means there's a bug in*/language design.long *ptr; ..... ptr = cast(long*)(cast(byte*)ptr +1 ); /* add one byte to the pointerI don't think that's an ordinary operation.Remember, adding one byte to a pointer is a mundane operation...but itrequires*2* casts.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 pforward2 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
"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...me"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 tellsYes, 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 spamthatNeeding casts for ordinary mundane operations means there's a bug in the language design.I can't do it!" I dont remember now who said it, but I second. =)
May 06 2002
Stephen Fuld wrote:"Walter" <walter digitalmars.com> wrote in message news:ab426q$310j$2 digitaldaemon.com...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... -RBNeeding 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. :-)
May 06 2002
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
"Russell Borogove" <kaleja estarcion.com> wrote in message news:3CD6DB74.3010802 estarcion.com...Stephen Fuld wrote: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"Walter" <walter digitalmars.com> wrote in message news:ab426q$310j$2 digitaldaemon.com...>>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... -RBNeeding 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. :-)
May 07 2002
"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...theStephen 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 inmundanelanguage design.Yes, but of course it depends upon your definition of "ordinaryHmm this doesn't look good to me...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';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... -RBor 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
"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...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"OddesE" <OddesE_XYZ hotmail.com> wrote in message news:ab3v7p$2ug8$1 digitaldaemon.com...me"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 tellsYes, 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 spamthatNeeding casts for ordinary mundane operations means there's a bug in the language design.I can't do it!" I dont remember now who said it, but I second. =)
May 06 2002
"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
"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
"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...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 spamYes, 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
"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>Yes, it is. But remember I came to C from Pascal (I actually wrote a mini-Pascal compiler once), and never looked back....I think of chars more as a special type of integers than as actual characters.That's your C heritage speaking :)
May 05 2002
"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...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"Walter" <walter digitalmars.com> wrote in message news:ab1mag$s75$1 digitaldaemon.com... <SNIP>Yes, it is. But remember I came to C from Pascal (I actually wrote a mini-Pascal compiler once), and never looked back....I think of chars more as a special type of integers than as actual characters.That's your C heritage speaking :)
May 07 2002
"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...<SNIP>enhancementYes, 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" fortoward 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,similarsyntax, 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
"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...features.)"Walter" <walter digitalmars.com> wrote in message news:ab426p$310j$1 digitaldaemon.com...<SNIP>enhancementYes, 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" fortoward 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,similarsyntax, but clean up a lot of the cruft and add some importantThen you might really like Turing. They eliminated the semicolons altogether and made the begin/end stuff consistant.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.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. snipBut 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
"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');^^^ semicolon is not 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
"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...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.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?
May 09 2002
"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...out"Walter" <walter digitalmars.com> wrote in message news:ab426p$310j$1 digitaldaemon.com...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 pointYes, 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?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 arounditif 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
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
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:just...in the past, I got pretty frustrated with Pascal disallowing arithmetic operations on chars. All the casting necessarymanipulationwound 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 arithmeticof 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 8bit) - Dnow has 'byte' and 'ubyte' * As strings - now D handles them much better than C, now almost noneed fortests 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
"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
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message news:3CD6C52D.512F96B deming-os.org..."Sean L. Palmer" wrote:isThe only big one left that I can can think of is converting case. ThisUnicodebetter performed by some kind of lookup table though, especially forarray(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(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
May 06 2002
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'! :OPHP 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
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message news:3CD6DEFC.B48B4051 deming-os.org...OddesE wrote: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 mailOfcourse 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'! :OPHP 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
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 mailPHP 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