GNOME Bugzilla – Bug 785899
Mentions of NULL for C strings should be converted to "" for C++ strings
Last modified: 2018-05-22 12:14:41 UTC
There was a thread on the mailing list recently where someone had tried to pass the string "nullptr" to a gtkmm function, thinking that was what the documentation was telling them to do in order to unset an Image. Of course, that's not the way to do it: usually, a NULL C string means an empty std::string or Glib::ustring after conversion. But the documentation never accounts for this, so NULL just becomes nullptr. You have to either figure out what this _really_ means, or become confused like that user did. Can the documentation conversion process do this for us and produce more useful docs? This assumes the new advice wouldn't be wrong for any functions (but the current advice already is, so that wouldn't be a loss anyway) (I feel like this has probably been discussed already but can't see a bug; sorry if it's a dupe)
NULL pointers in function arguments in glib and gtk+ have several equivalents in glibmm and gtkmm, such as - nullptr (rarely) - an empty string - Glib::RefPtr<SomeClass>() - an unset() method - an overloaded method without the NULL argument - an invalid object, e.g. Gdk::Event() It would be next to impossible (or at least too difficult) to have gmmproc automatically select the correct translation of NULL in each case. A more realistic alternative would be to replace NULL by a link to a description of the alternatives. Not perfect, but less confusing than nullptr.
(In reply to Kjell Ahlstedt from comment #1) > NULL pointers in function arguments in glib and gtk+ have several > equivalents in > glibmm and gtkmm, such as... Right, but I'm referring to a subset of situations, in which the real intent seems obvious. That is: if the NULL occurs in the doc comment for an argument or return value whose type is known - then the fact that the destination type is a string immediately signals that NULL in C should be translated to "" in C++. But then perhaps I'm presupposing more than the toolchain can handle, i.e. type-specific behaviour combined with interaction between the code and document processors.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glibmm/issues/24.