No need to fiddle something. The va_list version is only there to support the sealers and would be rarely used by an app developer. Somewhat like fprint vs vfprint. All we need to do is rename the second fltk3::alert to fltk3::va_alert and the ambiguity is gone. It's interesting that va_list expands to char*. ts ts.
On 20.06.2011, at 15:27, s...@sjssoftware.com wrote: > [..] >>> There are two, being: >>> >>> A) FLTK3_EXPORT void alert(const char *,...) __fl_attr((__format__ >>> (__printf__, 1, 2))); >>> B) FLTK3_EXPORT void alert(va_list, const char *); >>> > > const issues aside, (A) says there's an fl_alert() that > takes a char* argument and some other arguments, > while (B) says there's one that takes some arguments and > a char*. Isn't that bound to be ambiguous in some cases? > > For instance, imagine <maybe const> char* a, b, c; fl_alert(a, b, c) > No matter whether the declarations of (A) and (B) include > const, won't there always be some combination of const/non-const > a,b,c that makes the fl_alert call ambiguous? > > Or have I missed something? > > > > > _______________________________________________ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
