On 04/12/13 10:44, Albrecht Schlosser wrote: >> Yes, though for some reason "as_window()" is not const, >> (it probably should be), which is why that cheat is necessary at the end >> there. Maybe using const_cast<Fl_Widget*>(w)->as_window() is better, >> which is what I decided to go with in top_window_offset().. will check. > > Using const_cast<> is only another way to write it, but means the > same essentially, doesn't it?
Yes -- just more c++-esque. Should change it I think for two reasons; I already use it for the exact same reason in the new top_window_offset() method (just a few lines up from top_window()), and (2) it's probably clearer readability-wise that the goal is to explicitly cast away const (and not do something else, like a type conversion) > However, if some compilers wouldn't > flag a warning for const_cast<> but would for the old-style cast, > then we could maybe use it, but according to the CMP this shouldn't > be used for fltk 1.1 code, however it should be used for 2.0 code. > 1.3 code is not (yet) specified, so we'd have to make a decision > about this first. Open to alternative suggestions, but all the code provided here basically casts away const in one way or another, as we're defining a const method that starts with a pointer to 'this' (and therefore has to be const), but also need to call a non-const method as_window() through that pointer. > Concerning as_window(): ISTR that the first proposal was const, but > for some reason someone removed the const, but I'm not sure about it. Interesting; I'll try to track that conversation down, I'm kinda curious what the reason could possibly be. Seems the code implementation is pretty simple; it either returns '0' or 'this', and the virtual aspect handles the 'logic'. The method itself clearly makes no changes to the class, so it really could be const. >> 2) Highlights exactly where the cheat is needed (at as_window()) >> so if as_window() ever changes in the future to be const, it's >> easier to find and remove the const cast-away. > > Fair point. > >> Is there a reason as_window() and friends (other virtual >> implementations) are not const methods? Fl_Window::window() is. > > You mean: "Fl_Window* Fl_Widget::window() const" is, right? Yes, emphasis on the method itself being const, not concerned with the return value. window() is a const method, but as_window() is not; seems odd. > Other than what ISTR (see above), I don't know. Probably > "Fl_Window* Fl_Widget::window()" could be const as well, but > can we change it w/o breaking the ABI? I'm thinking you must have meant: "Fl_Window* Fl_Widget::as_window()" could be const as well ..emphasis on as_window() as opposed to window(), which already is const. Yes, too late to change I think, unless protected with our friend the ABI macro. _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev