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
