Mark Evans wrote:
> A type cast re-types a section of memory without changing it...

Why actually? A "(newtype)expr" should try to convert the value in a legal manner. For the cases where there is no conversion which makes sense, implementations usually define a "pretend as if" type change, although this is not requiered. For example, LCC didn't allow to cast a pointer into an integer till recently - and i believe by a reason.

Just think of it: when you write "float f = (float)integervariable;", you don't get a useless bit pattern in "f", but instead a value of integer variable converted correctly into a float. And if the bit length of types were different, a corresponding adjustment would take place.

-i.

Ilya Minkov says...
>> A type cast re-types a section of memory without changing it...
>Why actually?

By definition. A conversion is not a type cast.  Confusing the two is dangerous for language semantics and type-casting is already dangerous enough as things stand.  That is why I advocate distinct syntax for each operation.

Conversely there are proper places for typecasting, and if the language does conversions where I need typecasts, it is not helping me.

-Mark

By C standard - and Walter would confirm - a "C cast" means a conversion, not changing a type assoziated with an expression. This is also compliant with terminology in Pascal and diverse other languages. The "other meaning" which has been added to C - type pretending - really makes a mess out of it.

And by the way, there *is* a legal way to accomplish a type pretending - which you call typecast - in C: you have to cast to void first, then to the desired type. This is clear since void doesn't define a storage. It is also visually distinct, even if not very legible. The latter was probably the reason why the implementors have taken a shortcut.

Please note that D doesn't actually introduce the concept of type pretending as a separate - but instead follows the same justifiable scheme more strictly. This should be enough, as long as implementors are smart enough not to repeat the same mistake as in C.

My definition is by the standard. And where does yours come from?
And if C bends and misuses some terms, this doesn't mean you have to call everything false names.

-i.

Mark Evans wrote:
> Ilya Minkov says...
> 
>>>A type cast re-types a section of memory without changing it...
>>
>>Why actually?
> 
> 
> By definition. A conversion is not a type cast.  Confusing the two is dangerous
> for language semantics and type-casting is already dangerous enough as things
> stand.  That is why I advocate distinct syntax for each operation.
> 
> Conversely there are proper places for typecasting, and if the language does
> conversions where I need typecasts, it is not helping me.
> 
> -Mark
> 
> 

You may be right but C has confused semantics in the first place.  This item
might be just one more example.  Whatever the names, these are two distinct
operations, which is the main point.  A language should not use the same syntax
to implement both.
Mark

Mark Evans wrote:
> You may be right but C has confused semantics in the first place. This item might be just one more example.  Whatever the names, these
> are two distinct operations, which is the main point.  A language should not use the same syntax to implement both. Mark

WhoopS! I was somewhat wrong. I'm just reading the standard - and though
it *does* define a cast as a conversion - it does not define a way to
make "reinterpret_cast". And casting everything to void *always* means
discarding the value to hell - the result may not be used in any
expression.

Reading further. The standard defines a number of completely nonsense
"legal" casts, the result of which is implementation-defined, but the
*usage* is *undefined*. What a mess! "Standard-compliant behaviour is
considered harmful" :>

I guess C++ got it more or less right - separating the "real" cast,
which is dynamic_cast, a completely safe conversion utility, which has
also made its way to D; the static_cast, which is somewhat unsafe and
only relevant to performance freaks; and finally the reinterpret_cast,
just for the case someone has to fiddle with bits of a pointer or somesuch.

IIRC Walter argumented that D doesn't need reinterpret_cast, since it
can be simulated easily enough if really desired. Create a union,
containing both types, put one, manipulate the other. Seems to make
enough sense to me - one would also not forget to cast back. Just other
programmers also have to be convinced - else it'll fail, and future
implementors may repeat the same mistake!

-i.

Ilya Minkov wrote:

> IIRC Walter argumented that D doesn't need reinterpret_cast, since it
> can be simulated easily enough if really desired. Create a union,
> containing both types, put one, manipulate the other. Seems to make
> enough sense to me - one would also not forget to cast back. Just other
> programmers also have to be convinced - else it'll fail, and future
> implementors may repeat the same mistake!

Yes, I remember asking about / discussing this some months ago
(early last year?) in a thread dedicated to this topic - have to check
the archives.

I believe the conclusion reached was, as you stated, that
'cast(Type)variable' is a conversion cast, and to reinterpret the
type you do 'cast(newType*)&oldVaribale'.

exampli grata ...

int i = 0x3f800000;
printf( "'%g', '%g'\n", cast(float)i, char(float*)&i );

should print "'0.1016e+9', '1.0'"

C 2003/5/10

Post scriptum :

Mathematics where done in my head, so they will probably be wrong
:-)

Patrick Down wrote:
> 
> In article <3EBBE410.EB530CA2@chello.at>, Helmut Leitner says...
> 
> >
> >alias bit boolean;
> >
> 
> There are two problems with the bit type that makes it inadequate as a boolean type. A bit can not be an inout or out parameter of a function and you can't slice a bit array arbitrarily.
> 
> While I understand from an implementation point of view why bits have this restriction I belive that a type that is to be used as a boolean should not have the restrictions that bit currently has.
> 
> For this reason I belive that either
> 
> 1. The bit type needs to have it fuctionality expanded to include the capablities above.  ( With all the implementation baggage this brings.)
> 
> --or--
> 
> 2. There should be a separate boolean type.

First of all, one could just as well chose
  alias int boolean;
or
  type char boolean;
although it seems not very logical.

Apart from that I don't see much implementation problems with bit references and slices in itself. Bit addressing could just be address<<3+index.

I suppose you mean the relationship between these and gc? As the gc must be reworked anyway these problems are bound together and maybe have to be solved together.

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

>Yes, I remember asking about / discussing this some months ago
>(early last year?) in a thread dedicated to this topic - have to check
>the archives.
>
>I believe the conclusion reached was, as you stated, that
>'cast(Type)variable' is a conversion cast, and to reinterpret the
>type you do 'cast(newType*)&oldVaribale'.

Ugh!  Do it like Nice where type(var) gives the conversion and then let (type) var give the reinterpret-cast.  See conversion it is really a function so why not make it look like one.  Then you are not confusing as Evans says.

KM wrote:
> Ugh!  Do it like Nice where type(var) gives the conversion and then let (type)
> var give the reinterpret-cast.  See conversion it is really a function so why
> not make it look like one.  Then you are not confusing as Evans says.

Err, that was Walters recommendation - I, in the afore mentioned
post, stated it was 'ugly' but workable.

The evidence; for those who want to check it out ...

http://www.digitalmars.com/drn-bin/wwwnews?D/7420

Besides the '(type)var' C style cast is being deprecated:
there have been several requests for its removal.

With inlineing this 'do it yourself' reinterpret cast
could be placed in a function and still be efficient.

C 2003/5/11