www.digitalmars.com         C & C++   DMDScript  

D - typecasts (again) a cast with 2 params

reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
having just run fowl a simple missing &, I wondered what the responce to
allowing a typecast to not take one type as a param but two
so instead of (or as well as)  `cast( type )var;` there would be a `cast(
to-type, from-type) var;`
so that any changes in var would be reflected by an error.
for instance
uint stuff[] = new uint[4];
...
void * foo = cast(void *)(&(stuff[1])); // fine but there are times when you
want this.
however
void * foo = cast(void *)(stuff[1]); // rather different and may not be what
was required;

these would become
void * foo = cast(void *, uint*)(&(stuff[1])); // fine but there are times
when you want this.
however
void * foo = cast(void *, uint)(stuff[1]); // I really mean cast uint
element 1 to a void *
if, by mistake you wrote
void * foo = cast(void *, uint*)(stuff[1]);
then the compiler could warn you that the rhs was of the incorrect type.
uint not uint*

my reasoning is this, with one hand D offers GC which make robust OO
programming a little easier, and allows much simpler exception as each
unwound method frame does not now require cleaning up as much (the gc does
it later, only auto's need explicit cleanup to be added by the compiler).
then on the other the single 'C' cast (even if not 'C' style) allows,
without warning anything to be transmuted into anything else.
I would like to see the 'C' cast only allow for "safe" casts
numerics <-> numeric, or pointer<->pointer but not numeric<->pointer.
pointers to struct should be treated like objects 'C' casts; only allowed if
they inherit (or in the case of a struct, a pointer to the first member).
otherwise a two type cast is required. informing yourself, other programmers
and the compiler that you do know what you are doing.

Mike.
Feb 05 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:b1s5ev$mg9$1 digitaldaemon.com...
 my reasoning is this, with one hand D offers GC which make robust OO
 programming a little easier, and allows much simpler exception as each
 unwound method frame does not now require cleaning up as much (the gc does
 it later, only auto's need explicit cleanup to be added by the compiler).
 then on the other the single 'C' cast (even if not 'C' style) allows,
 without warning anything to be transmuted into anything else.
 I would like to see the 'C' cast only allow for "safe" casts
 numerics <-> numeric, or pointer<->pointer but not numeric<->pointer.
 pointers to struct should be treated like objects 'C' casts; only allowed

 they inherit (or in the case of a struct, a pointer to the first member).
 otherwise a two type cast is required. informing yourself, other

 and the compiler that you do know what you are doing.

I understand your reasoning. D has a number of features to reduce the need for casting in ordinary programming, but they'll always be needed as an escape from the typing system. But, of course, escaping from the type system means you're on your own. I think your idea has merit, but it doesn't address the common casting problem of getting the wrong number of *'s when converting pointer types, etc.
Mar 06 2003
parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Walter" <walter digitalmars.com> wrote in message
news:b495tq$16l3$1 digitaldaemon.com...
 "Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
 news:b1s5ev$mg9$1 digitaldaemon.com...
 my reasoning is this, with one hand D offers GC which make robust OO
 programming a little easier, and allows much simpler exception as each
 unwound method frame does not now require cleaning up as much (the gc


 it later, only auto's need explicit cleanup to be added by the


 then on the other the single 'C' cast (even if not 'C' style) allows,
 without warning anything to be transmuted into anything else.
 I would like to see the 'C' cast only allow for "safe" casts
 numerics <-> numeric, or pointer<->pointer but not numeric<->pointer.
 pointers to struct should be treated like objects 'C' casts; only


 if
 they inherit (or in the case of a struct, a pointer to the first


 otherwise a two type cast is required. informing yourself, other

 and the compiler that you do know what you are doing.

I understand your reasoning. D has a number of features to reduce the need for casting in ordinary programming, but they'll always be needed as an escape from the typing system. But, of course, escaping from the type

 means you're on your own. I think your idea has merit, but it doesn't
 address the common casting problem of getting the wrong number of *'s when
 converting pointer types, etc.

nothing is going to stop what should be int foo( void * param ) { bar ** ptr = cast(bar**)param; } being written as int foo( void * param ) { bar * ptr = cast(bar*)param; } but will stop int foo( int ** param ) { bar ** ptr = cast(bar**)(*param); } for being written as int foo( int ** param ) { bar ** ptr = cast(bar**)param; } int foo( int ** param ) { bar ** ptr = cast(int* to bar**)(*param); // valid } int foo( int ** param ) { bar ** ptr = cast(int* to bar**)(param); // not valid param is not an int* } int foo( int param ) { bar ** ptr = cast(int* to bar**)(param); // invalid param is not int* } int foo( int param ) { bar ** ptr = cast(int* to bar**)(&param); // valid }
Mar 07 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:b49ljo$1g27$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:b495tq$16l3$1 digitaldaemon.com...
 "Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
 news:b1s5ev$mg9$1 digitaldaemon.com...
 my reasoning is this, with one hand D offers GC which make robust OO
 programming a little easier, and allows much simpler exception as each
 unwound method frame does not now require cleaning up as much (the gc


 it later, only auto's need explicit cleanup to be added by the


 then on the other the single 'C' cast (even if not 'C' style) allows,
 without warning anything to be transmuted into anything else.
 I would like to see the 'C' cast only allow for "safe" casts
 numerics <-> numeric, or pointer<->pointer but not numeric<->pointer.
 pointers to struct should be treated like objects 'C' casts; only


 if
 they inherit (or in the case of a struct, a pointer to the first


 otherwise a two type cast is required. informing yourself, other

 and the compiler that you do know what you are doing.

I understand your reasoning. D has a number of features to reduce the


 for casting in ordinary programming, but they'll always be needed as an
 escape from the typing system. But, of course, escaping from the type

 means you're on your own. I think your idea has merit, but it doesn't
 address the common casting problem of getting the wrong number of *'s


 converting pointer types, etc.

nothing is going to stop what should be int foo( void * param ) { bar ** ptr = cast(bar**)param; } being written as int foo( void * param ) { bar * ptr = cast(bar*)param; } but will stop int foo( int ** param ) { bar ** ptr = cast(bar**)(*param); } for being written as int foo( int ** param ) { bar ** ptr = cast(bar**)param; } int foo( int ** param ) { bar ** ptr = cast(int* to bar**)(*param); // valid } int foo( int ** param ) { bar ** ptr = cast(int* to bar**)(param); // not valid param is not an int* } int foo( int param ) { bar ** ptr = cast(int* to bar**)(param); // invalid param is not int* } int foo( int param ) { bar ** ptr = cast(int* to bar**)(&param); // valid }

It does add some redundancy which will reduce some bugs, as you illustrated. But when *** is cast to ** instead of *, it isn't caught.
Mar 11 2003
parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:

nothing is going to stop what should be int foo( void * param ) { bar ** ptr = cast(bar**)param; } being written as int foo( void * param ) { bar * ptr = cast(bar*)param; } but will stop int foo( int ** param ) { bar ** ptr = cast(bar**)(*param); } for being written as int foo( int ** param ) { bar ** ptr = cast(bar**)param; } int foo( int ** param ) { bar ** ptr = cast(int* to bar**)(*param); // valid } int foo( int ** param ) { bar ** ptr = cast(int* to bar**)(param); // not valid param is not


 int*
 }

 int foo( int  param ) {
     bar ** ptr = cast(int* to bar**)(param);  // invalid param is not


 }

 int foo( int param ) {
     bar ** ptr = cast(int* to bar**)(&param); // valid
 }

It does add some redundancy which will reduce some bugs, as you

 But when *** is cast to ** instead of *, it isn't caught.

func ( bar *** param ) { bar ** pp = cast( bar *** to bar ** )param; ..... } instead of func ( bar *** param ) { bar * pp = cast( bar *** to bar * )param; ..... } nothing will every catch that error I accept that, but what it does catch is changes in params/members and missing '&' and *'s (no matter how many &*'s are involved as long as you've got the right types in the cast expr) and especially when passing params as void * to c, where you know what you want you can write func ( bar ** foo ) { void * pp = cast( bar *** to void * )&param; // has to have the & or its an error ..... } which will catch the missing & or * [void * pp = cast( bar* to void*)*param;] {&param or param would cause error} or course you need to get the from type correct but as it stands void * pp = cast(void*)*bar; void * pp = cast(void*)bar; void * pp = cast(void*)&bar; are all valid and might be correct there is no way to get the compiler to check you've got the right number of &,* 's for what you think should be passed (be it Bar ******* or Bar*) if this is not what you mean by 'But when *** is cast to ** instead of *, it isn't caught.' can you post an example please.
Mar 11 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:b4lnf4$cik$1 digitaldaemon.com...
 if this is not what you mean by 'But when *** is cast to ** instead of *,

 isn't caught.'

It is what I meant, you have it right.
Mar 11 2003
parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Walter" <walter digitalmars.com> wrote in message
news:b4loik$d8q$1 digitaldaemon.com...
 "Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
 news:b4lnf4$cik$1 digitaldaemon.com...
 if this is not what you mean by 'But when *** is cast to ** instead of


 it
 isn't caught.'

It is what I meant, you have it right.

so am I right in assuming you do not see enough merit in having a two param typecast, because the programmer can inform the cast to perform the wrong action. I (obviously) think its a step in the right direction and I can work around it with a templated cast func (although template syntax is rather verbose) or a nexted func to do the lhs typecheck.
Mar 11 2003
parent "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:b4lrq6$lse$1 digitaldaemon.com...
 so am I right in assuming you do not see enough merit in having a two

 typecast, because the programmer can inform the cast to perform the wrong
 action.

Yes.
 I (obviously) think its a step in the right direction and I can work

 it with a templated cast func (although template syntax is rather verbose)
 or a nexted func to do the lhs typecheck.

Apr 04 2003