Re: Gtkmm: gratitude and suggestions

[Maxim Udushlivy <maxim udushlivy gmail com>]

On 10/23/05, Murray Cumming <murrayc murrayc com> wrote:

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.

I meant references don't prevent the programmer from making error, they just enforce somebody's style and don't make code more safe.

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

But you still have to have non-const counterparts because widgets usually (always in most gui code) are not const objects.
 

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

Well, if there's lots of work then it doesn't worth it. Don't agree with "less obvious" conclusion.
 

Murray

Maxim