Re: Gtkmm: gratitude and suggestions

[Murray Cumming <murrayc murrayc com>]

On Sat, 2005-10-22 at 16:23 +0400, Maxim Udushlivy wrote:
> Hello, everybody!
> 
> I use gtkmm for almost one year in my project and I want to thank people 
> behind this library. Despite being a community effort it easily plays on 
> a par with commercial toolkits. Gtkmm programming is fun (!): it has 
> true C++ api, good documentation, builds on strong Gtk architecture 
> while hiding its complexities and exposing strengths (well, that sounds 
> like a promotion :)
> 
> And a bunch of small suggestions...
> 
> Why do you pass variables by non-const references instead of pointers? 

Usually because a null pointer would be a programming error. Where it
would have a special meaning, we use a more explicit extra method.

> Stroustrup recommends against doing this way, because it makes code more 
> difficult to read. And you can pass 'NULL' reference anyway: 
> "container.add(*(Gtk::Widget *)0)".

Then the error would at least be in your code, and not in gtkmm.

>  Using pointers may reduce a number 
> of functions: take a look at "bool 
> TextBuffer::get_selection_bounds(iterator & start, iterator & end)". I 
> need to pass iterators even if I want just a return value.

If there isn't already a () method overload for that then there should
be.

>  Currently you 
> can solve this by introducing a new function without parameters, but if 
> there were pointers - set default values to 0 in a header and it's done!

In general, gtkmm tries to be more explicit.
 
> (As I understand, this requires support from gtkmm generator, though)
> 
> About const functions: widgets are non-constant objects by their nature. 
> They can change by outside events, like DND. Aren't these const 
> functions "misconcept" api and bloat documentation?

const means whatever you choose it to mean. Most get functions don't
change any state of the object whatsoever, so they should obviously be
const.

> The solution to above that shouldn't break api: deprecate const 
> functions and those taking non-const references and introduce new that 
> take pointers. How difficult to implement this?

Lots of work, just to make the API less obvious.

Murray