Paul Elliott schrieb:
Yes, but the DTRO_holder objects could be local variables, or class members. Also the DTRO_holder object could have a method that returns a REFERENCE to the underlying DTRO, therefore REFERENCES to the DTRO could be class members or local variables. The user would not be encouraged or required to take the address of such a REFERENCE.
Sigh. To me this looks like fighting at shadows. Let us get concrete.Eliminating plain C pointers to widgets inside glademm generated code might be easy, if a Glib::RefPtr is ready to use.
Murray: Any problems left when storing widget references in RefPtrs left? Otherwise I _might_ take a look into using them within glademm. [Would be just to please political opinions]
Are we 100% percent sure there is no way around this problem? What if we got a smart C++ expert such as Stroustrup or Koenig thinking about it? Admitting this is tantamount to conceding that there are some respects for which C++ is inferior to JAVA. This I am extremely unwilling to do.
Gtkmm did a great job at eliminating pointers in user code during the last years! (I still remember 0.99)
If you want to minutely control lifetime of widgets, there's no way around new/delete but most people will never need this. [glademm went this way for compatibility reasons]
Also C pointers are faster than smartpointers. fullstop. Smartpointers do only have benefits if otherwise you needed to worry about lifetime issues [that's not the case within glademm generated code (glademm takes care of it)]. No single line within glademm causes the user to use pointers in _his/her_ code.
Christof
Attachment:
signature.asc
Description: OpenPGP digital signature