On 04/12/13 16:17, Ian MacArthur wrote:
>> The static_cast<> mod flew in all my tests on redhat9 and irix6.5,
>> and those are as old as the friggin hills.
>
> You say static_cast<> here?
Bleh, mental typo. I meant this:
$ grep const_cast Fl_Window.cxx
return const_cast(w)->a
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Fix Version: 1.3-current (r9876)
Sorry, as Ian points out on fltk.dev, meant to say const_cast<>
in the above, not static_cast<>.
Link: htt
On 13 Apr 2013, at 00:07, Greg Ercolano wrote:
> On 04/12/13 13:19, Ian MacArthur wrote:
>> I'm in favour of allowing the C++ style casts.
>> I expect that it probably works with all the extant compilers now?
>> Does anyone know for sure?
>
> The static_cast<> mod flew in all my tests on r
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Fix Version: 1.3-current (r9876)
Oh, I should add..
all mods to date (r9876, including static_cast<>) build OK on:
redhat9, irix6.5, centos 5
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Fix Version: 1.3-current (r9876)
Updated fixes in r9875 and r9876.
About to close, unless there's more to add.
Regarding const mods to at_w
On 04/12/13 13:19, Ian MacArthur wrote:
> I'm in favour of allowing the C++ style casts.
> I expect that it probably works with all the extant compilers now?
> Does anyone know for sure?
The static_cast<> mod flew in all my tests on redhat9 and irix6.5,
and those are as old as the
On 12 Apr 2013, at 18:44, Albrecht Schlosser wrote:
> Using const_cast<> is only another way to write it, but means the
> same essentially, doesn't it? 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 accordin
On 04/12/13 11:05, Albrecht Schlosser wrote:
> Hmm, I'm not a "const and ABI specialist", I mean I don't know
> all the implications that would arise if we changed this method.
Ya, I'll have to double check that one, but I think changing
the prototypes (args, return values) of exis
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(w)->as_window() is better,
>> which is what I decided to go with in top_window_offset(
On 04/12/13 01:20, MacArthur, Ian (Selex ES, UK) wrote:
>> @manolo: Great -- agree with all, except perhaps loosing const here:
>>
>> - const Fl_Window *win = (const Fl_Window*)this;
>> + Fl_Widget *win = (Fl_Widget*)this;
>>
>> I think we can maintain const protection on the variable this way:
>
On 12.04.2013 19:44, Albrecht Schlosser wrote:
> On 12.04.2013 18:57, Greg Ercolano wrote:
>> 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?
>
> Other than w
On 12.04.2013 18:57, Greg Ercolano wrote:
> Albrecht> We're only calling const methods anyway, as x(), y(), window(),
> Albrecht> and this code is not subject to be changed in the future.
>
> Yes, though for some reason "as_window()" is not const,
> (it probably should be), which is why that cheat
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
Hi Roman,
1) I didn't write that I didn't want that global flag, and I understood
what you wanted to achieve with it. That's all okay so far.
2
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Fix Version: 1.3-current (r9871)
Albrecht> We're only calling const methods anyway, as x(), y(), window(),
Albrecht> and this code is not sub
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
Ops, the second line from the bottom should be of course without return:
void Fl_Meu_Item::no_close_flags(int m){menu_no_close_flags_ = m;}
Lin
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
Hi Albrecht,
1) To have global function (although as static in Fl_Menu_Item)
no_close_flags(int f) is to allow user simply to change begaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Fix Version: 1.3-current (r9871)
@Greg: Yes to all proposed changes.
There's no reason, but laziness, to loose const protection.
Link: http
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
#2: I believe that the following part of this proposal should not be added
as given:
"change code in function Fl_Menu_::picked() from line appro
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
#1: I don't like the idea to encourage users to add custom flags in such
central structures like Fl_Menu_Items, as proposed with
#define FL_MENU_
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
Roman, this looks like a good idea, I recommend adding it, however with two
caveats. I'll post them in followup messages.
WRT ABI issues: adding
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Fix Version: 1.3-current (r9871)
+1 for renaming to w instead of win (or maybe widget to avoid name clashes
with w(), but that's not importan
> I have put the functions in Fl_Menu_Item namespace only because maming
> them
> that way seems to make sense. As far as I know, static functions (and
> static class variables) do not break ABI: they are not "really" class
> members, just additional ordinary functions and global variables with
> f
> @manolo: Great -- agree with all, except perhaps loosing const here:
>
> - const Fl_Window *win = (const Fl_Window*)this;
> + Fl_Widget *win = (Fl_Widget*)this;
>
> I think we can maintain const protection on the variable this way:
>
> const Fl_Widget *win = this;
> :
> return (
23 matches
Mail list logo