So when you declare a menu array, it is located in read-only memory and therefor `const`. Once you link it to a widget derived form `Fl_Menu_` and use `add()`, Fl_Menu_ will clone the original menu into red-write memory and values within the menu are no longer `const`, so you can safely cast away const. Note however that adding more menu items  may cause Fl_Menu_ to reallocate the menu array and create a new clone, making previously found pointers invalid.

Fl_Menu_::add() returns the index of the newly added menu item. So `int ix = myMenuBar->add("Edit"); Fl_Menu_Item *mi = myMenuBar->menu()+ix;` will return a pointer to the menu item that you just added. 

There are other functions to find the index of a menu item: Fl_Menu_::find_index() , or find the menu item itself: Fl_Menu::find_item(), find_item_with_argument(), find_item_with_userdata(). Yes, it can be cumbersome, and yes, actively changing the menu array may cause relocation of the array. FLTK 1.5 will add menus that use the same parent/child API that FLTK windows and widget use.

I like to use a trick to avoid re-allocating menu item arrays: I reserve an array large enough to hold everything I may ever add, but I keep the spare items invisible using the `FL_MENU_INVISIBLE` flag (or call hide() on the menu item).

Hope this helps a little.