This was discussed in another thread, but I think it's worth it's own topic:

I beg you Walter _please_ don't use C style casts.  I hate them with a purple passion.

Bad enough that parentheses are used for function declarations and function calls and order of operations and for and while and macros and whatever else, but using them for casts too is awful.

How many times have you had to look at

myfunc((*(qFlag*)((*it)->m_bar)) & (~(flag | flag2) & (int)not_flag));

What does this thing mean?  Are these parentheses even balanced?  I'm not going to count them to find out because it hurts my brain.

Now let's use C++ style casting:

myfunc((*static_cast<qFlag*>((*it)->bar)) & (~(flag|flag2) &
static_cast<int>(not_flag)))

We didn't save any parentheses, but it's a little easier to see where they are.  I can see one or two I didn't need now.

What if we simply use <> instead of () for static casts?

myfunc((*<qFlag*>((*it)->bar)) & (~(flag|flag2) & <int>(not_flag)))

There isn't that nice?  Those casts just pop right out at you.  The way they should.

Let me suggest an even better notation:

myfunc((*static_cast:qFlag*<(*it)->bar> & (~(flag|flag2) &
static_cast:int<not_flag>))

Oh yeah, that's the ticket.  Now, you are not used to looking at that, but compare it to the first one.  I would much rather look at this than that all day.

Angus Graham

Using the < and > as brackets causes too much grief in the scanner (as is >> a nested bracket or a right shift?). I had tried:

    cast(int)(expression)

but it just didn't look too good.

Angus Graham wrote in message <9lsnhn$1k3t$1@digitaldaemon.com>...
>This was discussed in another thread, but I think it's worth it's own
topic:
>
>I beg you Walter _please_ don't use C style casts.  I hate them with a purple passion.
>
>Bad enough that parentheses are used for function declarations and function calls and order of operations and for and while and macros and whatever else, but using them for casts too is awful.
>
>How many times have you had to look at
>
>myfunc((*(qFlag*)((*it)->m_bar)) & (~(flag | flag2) & (int)not_flag));
>
>What does this thing mean?  Are these parentheses even balanced?  I'm not going to count them to find out because it hurts my brain.
>
>Now let's use C++ style casting:
>
>myfunc((*static_cast<qFlag*>((*it)->bar)) & (~(flag|flag2) &
>static_cast<int>(not_flag)))
>
>We didn't save any parentheses, but it's a little easier to see where they are.  I can see one or two I didn't need now.
>
>What if we simply use <> instead of () for static casts?
>
>myfunc((*<qFlag*>((*it)->bar)) & (~(flag|flag2) & <int>(not_flag)))
>
>There isn't that nice?  Those casts just pop right out at you.  The way
they
>should.
>
>Let me suggest an even better notation:
>
>myfunc((*static_cast:qFlag*<(*it)->bar> & (~(flag|flag2) &
>static_cast:int<not_flag>))
>
>Oh yeah, that's the ticket.  Now, you are not used to looking at that, but compare it to the first one.  I would much rather look at this than that
all
>day.
>
>Angus Graham
>
>

Walter wrote:

> Using the < and > as brackets causes too much grief in the scanner (as is
> >> a nested bracket or a right shift?). I had tried:

i /*a

and is this i divided by content of a? or is it a comment?
In case of nested typecases you'll just have to add a space between > >
just one has to add a space between / and content of *.

BTW: Do nested typecasts in pratice make any sense? If in some obscure cases they do, how often does that occur?

"Walter" <walter@digitalmars.com> wrote

> Using the < and > as brackets causes too much grief in the scanner (as is
>>
> a nested bracket or a right shift?).

It's a right shift.  If the person meant to close two casts, well now it doesn't compile and issues the error message "cast not closed, perhaps you used >> when you should have used > >?"  Where's the grief in that?

> I had tried:
>
>     cast(int)(expression)
>
> but it just didn't look too good.

My eyes!  My eyes!  Aaaaa...

Angus Graham

Angus Graham wrote:
> 
> "Walter" <walter@digitalmars.com> wrote
> 
> > Using the < and > as brackets causes too much grief in the scanner (as is
> >>
> > a nested bracket or a right shift?).
> 
> It's a right shift.  If the person meant to close two casts, well now it doesn't compile and issues the error message "cast not closed, perhaps you used >> when you should have used > >?"  Where's the grief in that?
> 
> > I had tried:
> >
> >     cast(int)(expression)
> >
> > but it just didn't look too good.
> 
> My eyes!  My eyes!  Aaaaa...
> 
> Angus Graham

	I the cast of the '<' '>' usage, I bet Walter is trying not to make the
error that was made in C++ with templates.  (Or he may not be as
uncomfortable with the C cast syntax as you.)  Shift operators aside,
there are cases in C++ where use have to use the template keyword in a
function call (Yes, I said cll.) because the compiler doesn't look far
enough ahead to see that you are using a template function and not doing
a less than operation on a function pointer.

	Thing.get<int>();		// I believe this bombs
	Thing.template get<int>();	// Bjarne smiles upon us.

	This was the first time I really admitted to myself that C++ really
isn't the end-all-be-all compiled language.  In a feeble attempt to
maintain C compatibility they created a nasty grammar bug.  The fix
sucks.
	I suspect that by maintaining C compatibility, Walter can be sure he
isn't introducing a similar bug.  There are worse things than the C
casting syntax.  No really, there is. :-)

Dan

> Angus Graham wrote:
> 
> 	Thing.get<int>();		// I believe this bombs
> 	Thing.template get<int>();	// Bjarne smiles upon us.

Gad!  Make the evil go away!  I hate that bug, though to be honest, I've only ever run into it with the GCC compiler.  The Microsoft one and the MIPSpro compiler seem to handle it fine.  Now, admittedly I've used GCC way more than the other two, but maybe there is a way to handle it, it just isn't pretty.

Dan Hursh wrote in message <3B889511.AE07677A@infonet.isl.net>...
> I suspect that by maintaining C compatibility, Walter can be sure he
>isn't introducing a similar bug.  There are worse things than the C casting syntax.  No really, there is. :-)



foo(bar);

Is it a declaration? Is it a function call? Is it a constructor call? Gak.

"Walter" <walter@digitalmars.com> wrote in message news:9mged4$1d4p$1@digitaldaemon.com...
>
> foo(bar);
>
> Is it a declaration? Is it a function call? Is it a constructor call? Gak.

I guess, from C++ point of view - it's a function call, even if it's used as a type cast.

int a = int(b);

In this case, 'int' is a type and a bunch of functions to convert different types to 'int':

"Angus Graham" <agraham_d@agraham.ca> wrote in message news:9lsnhn$1k3t$1@digitaldaemon.com...
> This was discussed in another thread, but I think it's worth it's own
topic:
>
> I beg you Walter _please_ don't use C style casts.  I hate them with a purple passion.
>
Having used Delphi/Pascal for a while (I'm on Java now thanks), The notion of having special syntax for casts seems a bit silly to me. What is a cast to integer but a function that takes one parameter, and returns an integer (ok, so the code generated is different, but semantically it's the same thing) - why do you need new syntax for that?

That's what works for me: myInt := int(myFloat);

>How many times have you had to look at
>myfunc((*(qFlag*)((*it)->m_bar)) & (~(flag | flag2) & (int)not_flag));

That's partly a language thing and partly a lazy programmer thing - I'd prefer to see

 somemeaningfullvarname = (~(flag | flag2) & (int)not_flag);
 thebarparam = *(qFlag*)((*it)->m_bar);
 myfunc(thebarparam & somemeaningfullvarname);

Anthony Steele wrote:

> 
> "Angus Graham" <agraham_d@agraham.ca> wrote in message news:9lsnhn$1k3t$1@digitaldaemon.com...
>> This was discussed in another thread, but I think it's worth it's own
> topic:
>>
>> I beg you Walter _please_ don't use C style casts.  I hate them with a purple passion.
>>
> Having used Delphi/Pascal for a while (I'm on Java now thanks), The notion of having special syntax for casts seems a bit silly to me. What is a cast to integer but a function that takes one parameter, and returns an integer (ok, so the code generated is different, but semantically it's the same thing) - why do you need new syntax for that?
> 
> That's what works for me: myInt := int(myFloat);
> 
>>How many times have you had to look at
>>myfunc((*(qFlag*)((*it)->m_bar)) & (~(flag | flag2) & (int)not_flag));
> 
> That's partly a language thing and partly a lazy programmer thing - I'd prefer to see
> 
>  somemeaningfullvarname = (~(flag | flag2) & (int)not_flag);
>  thebarparam = *(qFlag*)((*it)->m_bar);
>  myfunc(thebarparam & somemeaningfullvarname);

The main argument against Pascal style typecasts is, they are difficult to parse, at least I guess they're acutallly very difficult to parse for a c like language. Pascal is easier since it types are simpler defined.

Try following C code with it:
a = (char **) b;
a = char**(b); // Looks also very ugly doesn't it?

According to a function paradigm I guess following would in example be
proper:
cast<char**>(a);

Well looking at the parser, and because we're lazy types you can cut the cast keyword away. People are lazy, and that's why they don't want to write BEGIN and END all the time, in my eyes that's all behind it :/

In my presonal view the discussions from Pascal vs. C where battled on another field than where the programmers hearts lay, they discussed for typedefs again type, structs agains records, include against uses, etc. but I think in reality it was only the feeling for '{' vs 'BEGIN'. :o)

- Axel