Please dont. Please! I have seen in Fl_Widget (1.3) somebody already put Fl_CString for the labels but did not do the same for label() copy_label(), derived classes, various inputs, outputs etc (to be fair it is indicated as fixme in fl_types.H). Apart from that there is another typedef Fl_String. Now the user has to dig out through headers or documentation to decrypt what it is (c-(non c++)string? constant string? or some other animal? Can he use standard strlen with it to allocate buffer size? what about str(l)cpy?) ... just to realise that it is ordinary const char *.
Also I do not think fltk should duplicate yet another string library (allready tons of them, including in std::) just to indicate utf-8 encoding, so my vote is also -1 for new class definition with all overloaded operators/conversions. FLTK is easy to learn also because it uses standard types whenever possible and user instantly sees what to expect from parameter or return type. So my vote would be very conservative: Indicate that something accepts utf-8 just by the parameter name, eg: Fl_Widget(int x, int y, int w, int h, const char * utf8_label=0); and revert to good-old (const) char *. utf-8 was invented to be compatible with it. R. PS: Down with fl_types.H! Sorry for my opinionated 2c. Matthias Melcher wrote: > On 06.12.2009, at 17:43, Duncan Gibson wrote: > >> Any comments / suggestions? >> > > Comment: it is a mess. > > Suggestion: I thought about all kinds of ways of handling strings in FLTK > 1.3. Here are the options I came up with: > > - use a "class Fl_String" for strings and a "class Fl_Char" for single > characters and provide a meaningful set a string functions for handling utf8 > and conversion from other sets > pro: yay, string handling! Finally I can write "abc"+"def" in my code > con: this may be fast, but is by no means light > > - use "char*" for strings and "unsigned" for characters. Provide a bunch of > global functions to handle these > pro: fast, light > con: messy, no information hiding, not intuitive, not obvious to the user, > namespace mess > > - use typedef to set Fl_String to char*, Fl_Char to unsigned, etc., then > provide global functions > pro: fast, light > con: almost as messy as the above, but maybe a bit more obvious to > understand > > > I am really torn between al three versions. I would probably give "class > Fl_String" and "typedef Fl_Char unsigned" the highest preference. > > Matthias _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
