-1 (don't change the API, just do it internally)
On Dec 6, 2010, at 10:51 AM, Albrecht Schlosser wrote:
> 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
________________________________________
Michael Sweet, Easy Software Products
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
