| | [ Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File ]
STR #1750
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Unassigned |
|---|
| Summary: | FLUID should not generate casts |
|---|
| Version: | 2.0-feature |
|---|
| Created By: | StanS |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
| |
| #1 | StanS
10:48 Jul 25, 2007 |
| The code generated by FLUID contains old-style "C" casts.
For instance, adding "my_func" with "my_arg" as its second
argument generates
o->callback((Fl_Callback*)my_func, (void*)my_arg);
Now, if my_func has the wrong signature, or if my_arg isn't
a pointer, or whatever, the casts allow the code to compile
anyway, and the error isn't detected until the application crashes.
This adds no value, in fact quite the opposite.
PS. This applies to 1.1.x as well as 2.0; the software prevents
entering a feature request for 1.1.x | |
| |
| #2 | matt
23:52 Jul 26, 2007 |
| I disagree. The signature of the callback my be different because "user_data" can be a void* or an int by definition. The void* then again can be cast into anything the user likes (which is why it is caled user_data).
I much rather prefer this cast, than maing the callbak function with the "correct" signature, but then casting inside the callback, because it would still require a cast, and the actual type of the user data would be unneccesarily obscured.
On a much higher level, yes, it would be wonderful to avois casting alltogether, but using a "union" for example if nothing more but a hidden cast. You could derive a new class for every kind of user data and pass the original class, but that seems lie a ton of unneeded code for a asimple problem. Beyond that, I don't know about any construct in C++ that would allow this kind of user_value passing. | |
| |
| #3 | StanS
05:18 Jul 27, 2007 |
| The first argument to Fl_Widget::callback is declared to be
void(*f)(Fl_Widget*, void*). If I insist on supplying
it with void(*g)(Wombat*, Voodoo*), I should bear the responsibility
of doing the cast myself. Which I could do, by telling FLUID that
the callback function is (Fl_Callback*)(g).
I'm not convinced that having the cast generated automatically
is useful. Reasonable people may disagree. | |
| |
| #4 | matt
05:38 Jul 27, 2007 |
| Ah, I see your point. Thanks for clarifying. | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
FLTK Apps 
