I'd like to make progress with STR #2308 [1]. It's almost solved,
but there are two different opinions about one detail.
Please take the time to read this, maybe have a look at the
patches in question, and give your votes.
To make it short: there are two patches that are almost identical,
but differ in one detail. Yuri's patch [2] changes the API of
callback-related methods, whereas mine [3] does not change the API.
It's a minor (more formal) change, but it introduces a new data
type (intptr_t) for Windows 64-bit systems. We agreed that there
will be a typedef (fl_intptr_t) that hides the differences, but
the effect would be that the return type and argument type of some
methods would be changed, and the data sizes would be different on
different platforms. Note that Yuri's proposal of the new typedef
was fl_long, but he agreed that fl_intptr_t would be the better
name.
This is Yuri's new typdef code in Fl_Widget.H:
+#ifdef _WIN64
+#include <stdint.h>
+typedef intptr_t fl_long;
+#else
+typedef long fl_long;
+#endif
Mine is similar (and replaces fl_long with fl_intptr_t).
Yuri's patch has these API changes that my patch avoids:
in FL/Fl_Menu_Item.H:
- void callback(Fl_Callback1*c, long p=0) {callback_=(Fl_Callback*)c;
user_data_=(void*)p;}
+ void callback(Fl_Callback1*c, fl_long p=0) {callback_=(Fl_Callback*)c;
user_data_=(void*)p;}
- long argument() const {return (long)user_data_;}
+ fl_long argument() const {return (fl_long)user_data_;}
- void argument(long v) {user_data_ = (void*)v;}
+ void argument(fl_long v) {user_data_ = (void*)v;}
in FL/Fl_Widget.H:
-typedef void (Fl_Callback1)(Fl_Widget*, long);
+typedef void (Fl_Callback1)(Fl_Widget*, fl_long);
- void callback(Fl_Callback1*cb, long p=0) {callback_=(Fl_Callback*)cb;
user_data_=(void*)p;}
+ void callback(Fl_Callback1*cb, fl_long p=0) {callback_=(Fl_Callback*)cb;
user_data_=(void*)p;}
- long argument() const {return (long)user_data_;}
+ fl_long argument() const {return (fl_long)user_data_;}
- void argument(long v) {user_data_ = (void*)v;}
+ void argument(fl_long v) {user_data_ = (void*)v;}
Note that there is no difference on Unix-like systems, since
sizeof(long) == sizeof(void*) on 32-bit and 64-bit systems,
but on Win64 sizeof(long) = 4 < sizeof(void *) = 8.
Although FLTK itself can be compiled successfully on all relevant
platforms with both patches, my concern is that changing the API
in this way *might* introduce problems with user code, because
Windows developers would have intptr_t on 64-bit and long on 32-bit
systems.
I recommend keeping the API as is and using casts only internally
as proposed in my patch. The discussions showed that we might want
to change the API anyway, but I would prefer to do it "The Right
Way" after FLTK 1.3 has been released (in 1.4 or 3.0) and not so
short before releasing FLTK 1.3. However, one of the patches
should definitely be integrated so that we can compile FLTK 1.3
for Win64.
Yuri wrote in his last message: "but i think that we can safely
change all long to fl_intptr_t in callback related function".
I respect Yuri's opinion and would like you developers to think
about it and give your votes whether we should change the API
now (use Yuri's patch [2]) or postpone API changes and use my
patch [3], which is also much shorter for obvious reasons.
Please vote +1 if you want to change the API (Yuri's patch)
and -1 if you don't want to change the API now (my patch).
Thanks in advance, and sorry, this "short" post is much longer
than intended.
My vote is -1 (don't change the API).
Albrecht
[1] <http://fltk.org/str.php?L2308>
[2] <http://fltk.org/strfiles/2308/fltk-1.3.x-r7709-fl_long.patch>
[3] <http://fltk.org/strfiles/2308/fl_intptr_t-r7907.diff>
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
