I'll try again on this.

My reading of the current documentation on casts leaves me with the impression that D now has only the equivalent of the C++ dynamic_cast.

This seems unreasonably restrictive given that C++ has traditional C- style cast, dynamic_cast, static_cast, and reinterpret_cast - or maybe it's changed now?

If D is a system programming language should I not be able to tell the compiler that a given set of bits represents what I say it is, and suffer the consequences if I get things wrong?

Steve

On Sunday, 25 December 2011 at 08:37:21 UTC, Steve Teale wrote:
> I'll try again on this.
>
> My reading of the current documentation on casts leaves me with the impression that D now has only the equivalent of the C++ dynamic_cast.
>
> This seems unreasonably restrictive given that C++ has traditional C-
> style cast, dynamic_cast, static_cast, and reinterpret_cast - or maybe it's changed now?
>
> If D is a system programming language should I not be able to tell the compiler that a given set of bits represents what I say it is, and suffer the consequences if I get things wrong?

The topic regarding confusion caused by having one cast syntax for everything is not new to this group. However, to unconditionally cast any reference type to any reference type, simply cast to void* first to avoid the runtime check.

Steve Teale:

> My reading of the current documentation on casts leaves me with the impression that D now has only the equivalent of the C++ dynamic_cast.

I'd like this in Phobos: http://d.puremagic.com/issues/show_bug.cgi?id=5559

Bye,
bearophile

On Sun, 25 Dec 2011 08:37:21 +0000, Steve Teale wrote:

So what do you think is happening here?

      ColorSelectionDialog csd = new ColorSelectionDialog("Choose a
Color");
writefln("csd %s", csd);
void* vp = cast(void*) csd.getColorSelection();
      ColorSelection cs = cast(ColorSelection) vp;
writefln("cs  %s", cs);
      cs.setCurrentColor(cto.baseColor);
writeln("A");

Output:

csd gtk.ColorSelectionDialog.ColorSelectionDialog
cs  gtk.Widget.Widget
Segmentation fault

The segfault is presumably because Widget does not have a setCurrentColor method, but why is the cast being ignored? Is the compiler optimizing the intermediate cast to void away? I don't find the asm from obj2asm helpful.

Steve

On Sunday, 25 December 2011 at 13:39:15 UTC, Steve Teale wrote:
> The segfault is presumably because Widget does not have a setCurrentColor method, but why is the cast being ignored? Is the compiler optimizing the intermediate cast to void away? I don't find the asm from obj2asm helpful.

I don't understand. Casting a void* to a class bypasses all static type checks. This is one of those cases where you "tell the compiler that you know what you're doing" - and if you try to call a method that wasn't in the original class's vtable, that's obviously not true.

On Sun, 25 Dec 2011 15:01:31 +0100, Vladimir Panteleev wrote:
> 
> I don't understand. Casting a void* to a class bypasses all static type checks. This is one of those cases where you "tell the compiler that you know what you're doing" - and if you try to call a method that wasn't in the original class's vtable, that's obviously not true.

Me neither, but it worked before somehow. Anyway, Mike Wey simply fixed gtkD on Christmas day, so now the derived object is handed out instead of the generic Widget.

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:jd6sbg$qb6$1@digitalmars.com...
> Steve Teale:
>
>> My reading of the current documentation on casts leaves me with the impression that D now has only the equivalent of the C++ dynamic_cast.
>
> I'd like this in Phobos: http://d.puremagic.com/issues/show_bug.cgi?id=5559
>

Yea, we need various casts in phobos. It's far too easy to accidentally cast away immutable and const.