> I personally like that the RefPtr makes it very obvious when an object > is being shared. If the class does it itself then it's not obvious when > reading code like this
> Something something2 = something; > something2.set_foo() //Also changes foo in something. It would be completely safe to do something like this: Gtk::TextBuffer buffer; Gtk::TextView v1(&buffer); Gtk::TextView v2(&buffer); because this is normal c++ practice. The buffer is shared. If you want you have the option to allocate buffer in the heap you can do it, but you needn't to do it. About the example. You could forbid operator= and use an alternative function, like, for example: SomeThing something; something.reference(something2); And you would get what a C++ programmer would expect from the implementation: uniform construction for objects. > I can't imagine how this could be done, personally. C++ is not a very > dynamic language. I tried to do it myself and this is difficult with the current implementation. If some idea comes to my mind, I'll post it here. Maybe I should do some C gtk+ hacking first in order to imagine how to get this working. And another idea I think should be done is to make widgets movable (upcoming c++0x feature). If I can help in anything (I'm not very experienced yet) I'll do it . My goal is to make gtkmm-3.0 as usable and as C++-standard as can be done. And I think that some kind of introspection is almost a must for a good widget toolkit, so I'll think about this in concrete.
_______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
