On 25 July 2017 at 15:20, Martijn Otto via gtkmm-list <gtkmm-list@gnome.org> wrote:
> I had not thought of trying an empty string, though it's good to know that > this is the usual answer to nullptr's that have become objects. > It's the usual answer for where the C API specifies NULL and the C++ API expects a string. It's not general to all objects. > However, it does not have a constructor taking an std::nullptr_t, which > would be a more obvious way to do it, one could then call: > > entry.set_icon_from_pixbuf(nullptr); > > This models the way that std::shared_ptr works, and IMHO it's more > declarative. It should be a simple one-liner to fix this, I'll see about > creating a patch for this later. > what does not have a constructor from std::nullptr_t is Glib::RefPtr in glibmm 3. Your patch should be directed to that, if anywhere, but then there's probably a reason that it does not exist. In glibmm next, for gtkmm 4, Glib::RefPtr *is* a shared_ptr.
_______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
