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