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?

Sorry for posting this in the wrong newsgroup section, It should have appeared in d.D.learn.

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

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

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

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

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

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

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

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