Sign up

TreeIter.setUserData!Object

This code:

TreeIter iter;
Object o;
iter.setUserData(o);

..results in a warning:

../../.dub/packages/gtk-d-master/gtk-d/generated/gtkd/gtk/TreeIter.d(347,3): Warning: statement is not reachable

Because of the following logic in TreeIter.d:

    static if(is(T == ...))
    {
       ...
    }
    ...
    else
    {
        pragma(msg, "IterData Type not Supported");
        throw new TreeIterError("getUserData", "IterData Type not Supported");
    }
    gtkTreeIter.userData = itData; // not reached
  • What's the point of throwing an exception at runtime, instead of giving an error at compile-time? When using dub, the compilation is stopped due to the warning, anyway, but the cause of the problem is not as obvious as if TreeIter.setUserData just spat out an error.

  • setUserData should support Object and derived classes IMO, without the user having to cast the object to void*.

BTW, given that GtkTreeIter is defined as

struct GtkTreeIter {
  gint stamp;
  gpointer user_data;
  gpointer user_data2;
  gpointer user_data3;
};

...having only one userData on the D side means that, for instance, if my tree iterator needs to store two pointers I have to define and allocate a separate object to hold the user data, while I could just store the pointers directly in the GtkTreeIter. Couldn't the D TreeIter provide access to the 3 pointers, instead of just one? Or any other solution that would allow me to exploit those gpointer.sizeof * 3 bytes on the D side.

Re: TreeIter.setUserData!Object

On 10-01-18 15:44, Luís Marques wrote:

...having only one userData on the D side means that, for instance, if my tree iterator needs to store two pointers I have to define and allocate a separate object to hold the user data, while I could just store the pointers directly in the GtkTreeIter. Couldn't the D TreeIter provide access to the 3 pointers, instead of just one? Or any other solution that would allow me to exploit those gpointer.sizeof * 3 bytes on the D side.

That is probably because i never needed more than one.

I've added properties and get/set functions for userData 2 and 3.
And we now use std.variant in the implementation of the get and set
functions so it supports more types that were implemented before.