On 10.11.2010, at 08:40, Greg Ercolano wrote: > Albrecht Schlosser wrote: >> Do we officially (want to) use "bool" in FLTK 1.3 ? >> >> There are some places in the code where it's used already [1], but >> AFAICT bool was not used in FLTK, or at least it was not the >> *usual* way to define boolean values. FLTK 2.0, however, uses bool >> frequently. >> >> If we start using bool, are there known drawbacks (e.g. converting >> function arguments), or something else? At least it's only defined >> for C++ (not C)... >> >> Would there be any incompatibilities to be expected, if we changed >> some methods' API ? >> >> Any opinions ? > > I always thought ints were fine for bools. > I guess if there's bools in there we can leave em. > > But if there's a desire to switch all true/false things > from ints to bools, I'd say delay till 1.4.x for that.. > it'd be best if 1.1.10 -> 1.3.x transitions are as easy > as possible for app programmers. > > As a side note on bools, I often find I eventually want > true/false values to be custom enums instead that take > descriptive names, eg: > > do_something(LIGHT_ON, SOUND_ON); > > ..instead of: > > do_something(true, true); > > And often true/false things end up later needing multiple states > (like SOUND_OFF, SOUND_ON, SOUND_FADEOUT, SOUND_FADEIN..) > > So from an API point of view, it might be more flexible > and forward thinking to use custom enum datatypes instead > of bools, so that new states besides on/off can be added if needed.
Sorry, yes, I introduces a few bools. I'll be happy to replace them with char. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
