> What I'd suggest doing is simply explicitly casting the first
> parameter
> to a char*; this _should_ fix your issue (at least it doesn't
> create any
> on gcc under Ubuntu 10.10).
> I suspect the only person who could confirm such a fix would be Ian,
> though....
Yes, that does work, e.g:
(Fl_File_Chooser2.cxx, line 870:)
// fltk3::alert("%s",existing_file_label); // error
fltk3::alert((char*)"%s",existing_file_label); // ok
(This pattern is required in several places, and in Fl_Text_Buffer.cxx,
Fl_Function_Type.cxx, etc...)
Though I have concerns about casting a "fixed" string like that just to
"trick" the compiler into doing the "obvious" conversion.
Google produces a fair few hits for this failure pattern, but I didn't
immediately see any suggestions for a fix we could apply easily, without
requiring that any use of fltk3::alert() do the explicit cast, which may
well confuse end users. And me.
I suppose the best bet *might* be to add a third option that expands to
(const char *, const char*) that would then take precedence over either
of the ambiguous cases here and so avoid the problem...?
--
Ian
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
