Re: Gtkmm: gratitude and suggestions

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

>  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

> 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]