Re: Gtkmm: gratitude and suggestions
- From: Murray Cumming <murrayc murrayc com>
- To: Maxim Udushlivy <maxim udushlivy gmail com>
- Cc: gtkmm-list gnome org
- Subject: Re: Gtkmm: gratitude and suggestions
- Date: Sun, 23 Oct 2005 13:59:21 +0200
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.
] [Thread Prev