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.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
