FLTK logo

STR #1750

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File | SVN ⇄ GIT ]

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:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]

No files


Trouble Report Comments:

Post Text ]
Name/Time/Date 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 ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.