www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Why explicit cast?

reply Andreas Kochenburger <akk nospam.org> writes:
I find it extremely annoying to have to write 'cast' before every C-like 
  cast. The C-syntax is as clear as tap water, so why had this 
complication been added?
Feb 11 2007
next sibling parent Andreas Kochenburger <akk nospam.org> writes:
Sorry for posting this in the wrong newsgroup section, It should have 
appeared in d.D.learn.
Feb 11 2007
prev sibling next sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Andreas Kochenburger" <akk nospam.org> wrote in message 
news:eqo451$8p9$1 digitalmars.com...
I find it extremely annoying to have to write 'cast' before every C-like 
cast. The C-syntax is as clear as tap water, so why had this complication 
been added?

It's grepable (ie, you can search for "cast" to find the casts)
Feb 11 2007
prev sibling next sibling parent "Chris Miller" <chris dprogramming.com> writes:
On Sun, 11 Feb 2007 17:08:41 -0500, Andreas Kochenburger <akk nospam.org>  
wrote:

 I find it extremely annoying to have to write 'cast' before every C-like  
   cast. The C-syntax is as clear as tap water, so why had this  
 complication been added?

It's ambiguous, (a)-b is a cast or subtraction. cast() jumps out at you, you know exactly what a cast is. I remember digging through 'h' files before and wondering what the heck a #define was doing, to realize a minute later that it was a cast; it's not always obvious, especially if it doesn't use spacing you're used to. Casting shouldn't be done that much, so it's a bit inconvenient, and explicitly warns readers of the code what it's doing. However, it's not "too" inconvenient; this argument rarely pops up. And last, as the other reply mentioned, you can search for it easily. - Chris
Feb 11 2007
prev sibling next sibling parent reply janderson <askme me.com> writes:
Andreas Kochenburger wrote:
 I find it extremely annoying to have to write 'cast' before every C-like 
  cast. The C-syntax is as clear as tap water, so why had this 
 complication been added?

I've used languages that simplicity convert casts. They are a pain because its so easy to accidentally convert something into something else you didn't want. Admittedly there are some cases I think casting could be ignored (or perhaps cast(auto)(...) or auto(...) ) however most of the time they are necessary. If you see code with lots of casts in it, its a sign something is wrong. -Joel
Feb 11 2007
parent janderson <askme me.com> writes:
janderson wrote:
 Andreas Kochenburger wrote:
 I find it extremely annoying to have to write 'cast' before every 
 C-like  cast. The C-syntax is as clear as tap water, so why had this 
 complication been added?

I've used languages that simplicity convert casts. They are a pain because its so easy to accidentally convert something into something else you didn't want.

I think I missed the point here. cast is more explicit then C style. Its easier to phase. D is meant to be a very phasable language (which also improves compile times). The longer syntax also makes them easier to spot/grep and act as a warning. Thankfully they are not as bad as C++'s or Ada's casts (which where made long on purpose).
 Admittedly there are some cases I think casting 
 could be ignored (or perhaps cast(auto)(...) or auto(...) ) however most 
 of the time they are necessary.
 
 If you see code with lots of casts in it, its a sign something is wrong.
 
 -Joel

Feb 11 2007
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Andreas Kochenburger" <akk nospam.org> wrote in message 
news:eqo451$8p9$1 digitalmars.com...

 The C-syntax is as clear as tap water, so why had this complication been 
 added?

After having used D for more than two years, I'll have to disagree with this comment ;) Besides, as Joel said, your code really shouldn't have a lot of casts in it, unless you're programming "in C" in D.
Feb 11 2007
parent reply Andreas Kochenburger <akk nospam.org> writes:
Jarrett Billingsley wrote:
 "Andreas Kochenburger" <akk nospam.org> wrote in message 
 news:eqo451$8p9$1 digitalmars.com...
 
 The C-syntax is as clear as tap water, so why had this complication been 
 added?

After having used D for more than two years, I'll have to disagree with this comment ;) Besides, as Joel said, your code really shouldn't have a lot of casts in it, unless you're programming "in C" in D.

First thanks to all those who have answered. Indeed I am programming "in C" in D i.e. I am converting a small compiler from C to D, to test if D would make life easier for me. The program uses a lot of pointers of different types to address bits and bytes and ints and floats etc. in a memory region directly. Probably this kind of system programming is not an ideal application for D. I got also a bit frustrated about the (at least for me, messy) "very" flexible string handling in D: static arrays, dynamic arrays, strings, C-like strings (to be converted with toStringz), then I have to import std.c.string and std.string and then I have to add .ptr to a pointer to a static array string, when I use the C-function strtok from std.c.string it claims char* pointers and does not want char[] because it is a static array and its name is not the pointer to its first element etc etc ..... grrrrrgh
Feb 12 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Andreas Kochenburger wrote:
 Jarrett Billingsley wrote:
 "Andreas Kochenburger" <akk nospam.org> wrote in message 
 news:eqo451$8p9$1 digitalmars.com...

 The C-syntax is as clear as tap water, so why had this complication 
 been added?

After having used D for more than two years, I'll have to disagree with this comment ;) Besides, as Joel said, your code really shouldn't have a lot of casts in it, unless you're programming "in C" in D.

First thanks to all those who have answered. Indeed I am programming "in C" in D i.e. I am converting a small compiler from C to D, to test if D would make life easier for me. The program uses a lot of pointers of different types to address bits and bytes and ints and floats etc. in a memory region directly. Probably this kind of system programming is not an ideal application for D.

Why not? You can certainly make pointers and manipulate pointers all you want with D.
 I got also a bit frustrated about the (at least for me, messy) "very" 
 flexible string handling in D: static arrays, dynamic arrays, strings, 
 C-like strings (to be converted with toStringz), then I have to import 
 std.c.string and std.string and then I have to add .ptr to a pointer to 
 a static array string, when I use the C-function strtok from 
 std.c.string it claims char* pointers and does not want char[] because 
 it is a static array and its name is not the pointer to its first 
 element etc etc ..... grrrrrgh

Seems like your problem is trying to use too much stuff from std.c. All that stuff is there as a last resort, really. If you use D libraries to do the job you won't need toStringz and .ptr everywhere. Even if you do want to use a lot of std.c stuff, you can write a more D-like wrapper around it to hide the toStringz so you don't go crazy. --bb
Feb 12 2007
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Andreas Kochenburger" <akk nospam.org> wrote in message 
news:eqqfqp$9dq$1 digitalmars.com...

 I got also a bit frustrated about the (at least for me, messy) "very" 
 flexible string handling in D: static arrays, dynamic arrays, strings, 
 C-like strings (to be converted with toStringz), then I have to import 
 std.c.string and std.string and then I have to add .ptr to a pointer to a 
 static array string, when I use the C-function strtok from std.c.string it 
 claims char* pointers and does not want char[] because it is a static 
 array and its name is not the pointer to its first element etc etc ..... 
 grrrrrgh

Maybe you can post some of the more.. offensive code and we might be able to show you a more D-like way to do it :)
Feb 12 2007