🚀 go-pugleaf

On 4/16/96 4:58AM, in message <4l020g$i9j@srvr1.engin.umich.edu>, HASDI 
RODZMANN HASHIM <hasdi@news-server.engin.umich.edu> wrote:

> Hi guys! I think my earlier post got lost so here it is again.... This is
> for a student compiler project of mine.... 
> 
> If you have a choice, do you want the parethesis pair over the caster
> (C-style) or over the castee (Pascal-style)? eg...
> 
> int a;
> float b;
> 
> a = (int)b; /* cast to int */
> a = int(b); /* allowable in C++ */
> 
> ...as for Pascal...
> a := integer(b); { "a" in an integer and "b" is a real }
> 
> Thanx!
> 
I believe you would want the parens over the type not the variable.  Your first 
example a = (int)b looks like the way I would do it anyway.  I am sure someone 
will correct me on this one.

-John Machin
machin@gnn.com

HASDI RODZMANN HASHIM wrote:
> 
> Hi guys! I think my earlier post got lost so here it is again.... This is
> for a student compiler project of mine....
> 
> If you have a choice, do you want the parethesis pair over the caster
> (C-style) or over the castee (Pascal-style)? eg...
> 
> int a;
> float b;
> 
> a = (int)b; /* cast to int */
> a = int(b); /* allowable in C++ */
> 
> ...as for Pascal...
> a := integer(b); { "a" in an integer and "b" is a real }
> 
> Thanx!

Pascal style. TypeName(SomeVar) looks like a function call.

-- 

http://www.midnightbeach.com/jon	Personal Pages
http://www.midnightbeach.com/jon/pubs	Programming Publications
http://www.midnightbeach.com/hs		Home School Resource List

HASDI RODZMANN HASHIM wrote:
> 
> If you have a choice, do you want the parethesis pair over the caster
> (C-style) or over the castee (Pascal-style)? eg...
> 
> a = (int)b; /* cast to int */
> a = int(b); /* allowable in C++ */
> 


I would prefer the Pascal style where the parenthesis go around the
thing being casted.  This is so that the cast looks like a function
and it then seems consistent when overriding the cast operator.

Tarang

hasdi@news-server.engin.umich.edu (HASDI RODZMANN HASHIM) wrote:

>Hi guys! I think my earlier post got lost so here it is again.... This is
>for a student compiler project of mine.... 

>If you have a choice, do you want the parethesis pair over the caster
>(C-style) or over the castee (Pascal-style)? eg...

>int a;
>float b;

>a = (int)b; /* cast to int */
>a = int(b); /* allowable in C++ */

>...as for Pascal...
>a := integer(b); { "a" in an integer and "b" is a real }

>Thanx!

Hi,
I like the pascal version because you can easily see what you are
actually typecasting e.g.

a := 10000; b := 10000;
c := longint(a * b);     { Bad, overflow occurs before typecast }
c := longint(a) * b;     { Good, typecast then multiply }

I don't know how you distinguish between these cases in C++ (I have
never done any serious programming in C).
        Jes R Klinke

On 16 Apr 1996, HASDI RODZMANN HASHIM wrote:

> Hi guys! I think my earlier post got lost so here it is again.... This is
> for a student compiler project of mine.... 
> 
> If you have a choice, do you want the parethesis pair over the caster
> (C-style) or over the castee (Pascal-style)? eg...

  C-style.  Especially since C types can contain multiple tokens;

  const char *(p) is less clear IMO than (const char *)p.

--
James Robinson            "Because we are returning a copy for postfix ++ 
james-robinson@uiowa.edu  expressions, statements such as (c++)++; won't
robinson@cs.uiowa.edu     work as expected."            -- Weiskamp & Flamig,
                                           _The_Complete_C++_Primer_, 2nd ed.

On Tue, 16 Apr 1996, Jes R. Klinke wrote:

> a := 10000; b := 10000;
> c := longint(a * b);     { Bad, overflow occurs before typecast }
> c := longint(a) * b;     { Good, typecast then multiply }
> 
> I don't know how you distinguish between these cases in C++ (I have
> never done any serious programming in C).
>         Jes R Klinke

How about:

c = (long)(a * b);
c = (long)a * b;

This form seems to work for me... :)

					Rich

In article <4l020g$i9j@srvr1.engin.umich.edu>
           hasdi@news-server.engin.umich.edu "HASDI RODZMANN HASHIM" writes:

>Hi guys! I think my earlier post got lost so here it is again.... This is
>for a student compiler project of mine.... 

This is entirely down to what your compiler actually compiles (other
than students!). If it is C use C cases, if it is Pascal use Pascal
conversions. If it is something else use whatever fits the type system
of the language. Pascal conversions wouldn't work at all well with complex
C type declarations and may not even produce an unambiguous grammar.

>If you have a choice, do you want the parethesis pair over the caster
>(C-style) or over the castee (Pascal-style)? eg...

I would use whatever is appropriate for the rest of the language.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

In article <3173E842.7D17@willows.com>, Tarang Deshpande
<tarang@willows.com> wrote:

> HASDI RODZMANN HASHIM wrote:
> > 
> > If you have a choice, do you want the parethesis pair over the caster
> > (C-style) or over the castee (Pascal-style)? eg...
> > 
> > a = (int)b; /* cast to int */
> > a = int(b); /* allowable in C++ */
> > 
> 
> 
> I would prefer the Pascal style where the parenthesis go around the
> thing being casted.  This is so that the cast looks like a function
> and it then seems consistent when overriding the cast operator.

On the one hand, I prefer the "C" style cast because it is explicit that a
cast is taking place, whereas the functional style requires you to know
whether the function is a cast function or not. Since casting is an
important thing to know about in a statically typed language (ignoring
RTTI for this discussion), I prefer the emphasis on casting; I think it
makes code more readable.

On the other hand, the functional style emphasizes that some function may
actually be called, and that that function may do significantly more than,
for example, sign extension. However, I was just reading "Item 5: Be wary
of user-defined conversion functions" in Scott Meyers' More Effective C++,
and he basically concludes that you should never define cast operator
functions in a class because they can be called unexpectedly (unless, of
course, you really really want to :-).

Instead of either solution, I prefer the Dylan approach: there is a
function "as()" that takes a type parameter and an object parameter and
returns an object of the specified type, created using the object
parameter. It looks like this:

  foo := as(<type>, bar);

The thing I like about this is that "as()" is defined as part of the
language (like, say "new" in C++), so you always know that you are
performing a cast, but  it also indicates that a function is, or may, be
called. Of course, C++ can't currently handle this approach because it
doesn't have values that represent types. Perhaps RTTI provides this
solution?

-- 
Chris Page        | Internet chain letters, advertisements and SPAMs suck...
Don't Panic!      | 
page@best.com     |                   Cut it out! :-P

I just took a look at More Effective C++ and noted the explicit casting
operator "static_cast". This emphasizes the cast, making the source more
readable, but also uses a functional form, thereby indicating that a
function call may take place. In addition, there are some other cast
operators that provide better control over casting.

-- 
Chris Page        | Internet chain letters, advertisements and SPAMs suck...
Don't Panic!      | 
page@best.com     |                   Cut it out! :-P

The Amorphous Mass (robinson@blue.weeg.uiowa.edu) wrote:
: On 16 Apr 1996, HASDI RODZMANN HASHIM wrote:

:   C-style.  Especially since C types can contain multiple tokens;

:   const char *(p) is less clear IMO than (const char *)p.

Hmm.... another thing about pascal is that dereferencer is postfix 
instead of prefix. That way, I can cast a void * (Pascal - pointer) into 
something else...

C-style:
	typedef myrecord_s {...} myrecord,*myrec;

	my_int = ((myrecord*)myvar)->intA; /* yeach! */
or...
	my_int = (*(myrecord*)myvar).intA; /* see above */	

Pascal-syle:
	myrecp : ^myrecord;
	myrecord : record ... end;

	myInt := myrecp(myvar)^.intA; { looks clean }
	myInt := ^myrecord(myvar)^.intA; { compile error? }

Remix:
	my_int = myrecp(myvar)*.intA;
or...
	my_int = myrecord*(myvar)*.intA; /* ouch! */

Some people mentioned about type-casting != type-conversion and C++ use
makes distinction between them using cast-notation (c-style) and
function-notation (pascal-style). I think I am getting the hang of the
differences; I had to talk to my professor and read C++ draft to figure
out what it going on. 

The way I understand it, type-conversion is to transform the bits of one
variable so that it is representable as the type to be converted into. eg. 
(int)my_float. type-casting doesn't transform the bits at all, but force
the compiler to treat that variable as the specified type... which is
highly unportable. Why would anyone want to typecast then? Can somebody
clarify this for me? 

As a side note, using typedef so that you can use "myrecord" instead of
"struct myrecord_s" has been a real major bug to me. Unfortunately, this
is necessary to avoid shift/reduce conflicts. Makes me wonder how C++
parser works. (If I stick to Pascal-style, this would also mean I have to
redesign the declaration section, C-style or Pascal? But that's another
story.)

Thanks guys!

Hasdi

Posting from comp.lang.c.....

HASDI RODZMANN HASHIM wrote:
> 
> Hi guys! I think my earlier post got lost so here it is again.... This is
> for a student compiler project of mine....
> 
> If you have a choice, do you want the parethesis pair over the caster
> (C-style) or over the castee (Pascal-style)? eg...
> 
> int a;
> float b;
> 

Prefer this one.

> a = (int)b; /* cast to int */

Never done this .. looks like a function .. misleading. Does it work in C?

> a = int(b); /* allowable in C++ */
> 

except in Pascal, of course.

> ...as for Pascal...
> a := integer(b); { "a" in an integer and "b" is a real }
> 
> Thanx!

-- 
    ___                      mailto:dwater@hursley.ibm.com
  /  /  /  _       /     /  _  __ __   _   __   _
 /  /  / /_/ |/  /  /  / /_/  /  /_   /_/ / / / /_/ /| /
/  /  / /  / /|  /_/_/ /  /  /  /_  /  |  / / / /  / / |/

Tarang Deshpande wrote:
> 
> HASDI RODZMANN HASHIM wrote:
> >
> > If you have a choice, do you want the parethesis pair over the caster
> > (C-style) or over the castee (Pascal-style)? eg...
> >
> > a = (int)b; /* cast to int */
> > a = int(b); /* allowable in C++ */
> >
> 
> I would prefer the Pascal style where the parenthesis go around the
> thing being casted.  This is so that the cast looks like a function
> and it then seems consistent when overriding the cast operator.

Why do you want it to look like a function? This makes it misleading.
What do you mean by 'overriding the cast operator'?

In C you can have a type of any name, so it is very misleading to have a
cast look like a function. On my compiler it flags it as a syntax error
anyway (is this the same with others?) - so I am quite happy that this
isn't allowed. Consider the following :

#include <stdio.h>

typedef double sin;

.
.
. loads of source lines....
.
.

int main( void )
{

  float f = 3.123485;

  printf( "%f", sin(f) );

}

looks like sin(f) is taking the sine of f but in fact it is meant to
cast it to a double.

Even if it did compile, I wouldn't pass this in a code inspection.

Unless you can give me a good reason this is useful.

Max.
-- 
    ___                      mailto:dwater@hursley.ibm.com
  /  /  /  _       /     /  _  __ __   _   __   _
 /  /  / /_/ |/  /  /  / /_/  /  /_   /_/ / / / /_/ /| /
/  /  / /  / /|  /_/_/ /  /  /  /_  /  |  / / / /  / / |/

HASDI RODZMANN HASHIM (hasdi@news-server.engin.umich.edu) wrote:
[snip]
: The way I understand it, type-conversion is to transform the bits of one
: variable so that it is representable as the type to be converted into. eg. 
: (int)my_float. type-casting doesn't transform the bits at all, but force
: the compiler to treat that variable as the specified type... which is
: highly unportable. Why would anyone want to typecast then? Can somebody
: clarify this for me? 

Sure.  You typecast when you know better than the compiler.  For example,
without typecasting, malloc() would need to have a version for char *,
int *, and whatnot, and allocating memory for a user-defined structure
would not be possible.  As it is, it returns a void * which is explicitly
or implicitly cast to the correct type.  A more dangerous (but nonetheless
oft-seen) use is to enable you to code assumptions on data.  For instance,
if you have 4 chars that you know to be actually int, like so:

char really_an_int[4];

you can:

int x = *(int *)really_an_int;

Mind you, this is stinking code, but it does get used.

In article <4l4ldb$nkl@srvr1.engin.umich.edu>
           hasdi@news-server.engin.umich.edu "HASDI RODZMANN HASHIM" writes:

>The way I understand it, type-conversion is to transform the bits of one
>variable so that it is representable as the type to be converted into. eg. 
>(int)my_float. type-casting doesn't transform the bits at all, but force
>the compiler to treat that variable as the specified type... which is
>highly unportable. Why would anyone want to typecast then? Can somebody
>clarify this for me? 

You've misunderstood. Casting is simply a way of forcing type conversions
explicitly - changes of representation i.e. the bits patterns or even the
number of bits occupied by the value are in general required. For example

    int i;
    double d;

    i = 1;

    x = i;

This involves an implicit conversion and the result will be that x contains
1.0 (or something as close as possible to it).

    x = (double) i;

has exactly the same result. However the conversion to double is performed
explicitly by the cast instead of implicitly by the assignment. Pointer
casts can also result in a change of representation for the pointer. However
there is no effect in what is being pointed to so you can end up with a
pointer pointing to something that was created as a different type. E.g.

    int x = 1;
    char *p = (char *)&x;

&x is a pointer to int which is cast to a pointer to char. The representation
of the pointer may change if the system uses different representations
fort int * and char * (some systems do). If you dereference p you will
be accessing what it points to as a char although the value containted in x
is represented as an int.


>As a side note, using typedef so that you can use "myrecord" instead of
>"struct myrecord_s" has been a real major bug to me.

Why? Structure tags allow you tag the fundamental structure types. typedefs
are a general mechanism in C to create aliases for any type including
structures.

>Unfortunately, this
>is necessary to avoid shift/reduce conflicts.

You may have to define the grammar differently but I see no need for
conflicts. The main issue is that in C tags have their own namespace. That
is only possible if they can be distinguished from other types of
identifier syntactically.

>Makes me wonder how C++ parser works.

There's nothing special here however C++ doesn't give tags a separate
namespace.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

union Int_Over_Float {
 	 Int integer;
 	 Float floating_point;
	};
	typedef union Int_Over_Float Int_Over_Float;

	Int_Over_Float f;
	Int i;

	f.floating_point = 3.14;

	i = f.integer;

is _not_ the same as

	Float f = 3.14;
	Int i = (Int)f;

They are completely different. The first results in i being something I
wouldn't like to guess at, while the second results in i == 3.

Max.

-- 
    ___                      mailto:dwater@hursley.ibm.com
  /  /  /  _       /     /  _  __ __   _   __   _
 /  /  / /_/ |/  /  /  / /_/  /  /_   /_/ / / / /_/ /| /
/  /  / /  / /|  /_/_/ /  /  /  /_  /  |  / / / /  / / |/

Max Waterman <dwater@wight.hursley.ibm.com> writes:

>union Int_Over_Float {
> 	 Int integer;
> 	 Float floating_point;
>	};
>	typedef union Int_Over_Float Int_Over_Float;

C _is_ case sensitive. There may be some local typedef standards that
require you to have something like

  typedef int Int;
  typedef float Float;

but I have never fully understood how this could help porting a program.
If your code assumes that int is a 32-bit number, it's portability is
restricted to 32-bit architectures, anyway. If you need a 32-bit type,
why don't you ("You" is not Max Waterman in this case, but a less 
personal you) give it a name that documents that you assume that it
will be a 32-bit type.

Kurt
--
| Kurt Watzka                             Phone : +49-89-2180-6254
| watzka@stat.uni-muenchen.de