| |
| |
Yes, this is a side effect of offering the shortcut to use a statically allocated Menu Item array. You can safely cast away the `const` once you know that your menu array was copied. To be absolutely sure, instead of Fl_Menu_::menu(myMenu) you can call Fl_Menu_::copy(myMenu), and you are guaranteed that the menu array is no longer const.
If you want to avoid the const cast in your application, you can derive your own class and write a method:
Fl_Menu_Item *MyMenuBar::non_const_menu() { if (alloc==0) copy(menu(), NULL); return const_cast<Fl_Menu_Item*>(menu()); }
Historically, the F and L in FLTK were absolute priority. By referencing a const array of menu items, there was no need to copy labels or allocate memory, making the library extremely fast and light. This is the same reason why Fl_Wdget::label() does not duplicate the text, but instead just references it (vs. copy_label()). We are keeping these interfaces alive for back compatibility, and I sometimes surprise myself by compiling apps that I wrote 20 years ago, and they compile with minor changes.
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/11e33b38-e9c2-4c0d-bc3a-ad48e31a4322n%40googlegroups.com.
[ Direct Link to Message ] | |
|
| |
