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.
Comments are owned by the poster. All other content is copyright 1998-2025 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.
