Let me summarize... 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]
I forgot to append the note [1] in my original post, so I'll add here that we used bool already in fltk 1.1 (intentionally or not). I found it in the following files: FL/Fl_Text_Display.H src/fl_draw_pixmap.cxx src/fl_font_xft.cxx src/Fl_Gl_Window.cxx src/Fl_lock.cxx src/Fl_mac.cxx src/Fl_Text_Display.cxx src/Fl_x.cxx Since we didn't get any complaints so far, I assume that using bool is okay for today's C++ compilers. Michael Sweet wrote: > ... given that we are discontinuing support for GCC 2.x, now is probably the right time to use bool for any boolean values in the FLTK API. Greg Ercolano wrote: > 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. Agreed. IMO we should leave general API changes for 1.4 or later. Matthias Melcher wrote: > Sorry, yes, I introduces a few bools. I'll be happy to replace them with char. My question was more about STR 2243, where the suggested patch uses bool, and I was wondering if we should use bool or replace it with int, as I mentioned in the STR. But, yes, I also saw that you used bool in Fl_Text_*... Given the replies above, I'd say that we can/should leave bool where applicable, but probably not in public API's (unless it ha been used in FLTK 1.1 already). Ian (SELEX GALILEO, UK) wrote: > Well... char may be a poor choice here; on a lot of modern CPU's (and > particularly ARM cores for example) it is often more expensive to access > a char than a int32, and does not save any memory because the alignment > is forced to 32 (or even 64!) bit anyway. > > So, for a "fast and light" implementation, it is possible that some sort > of int is a better bet than a char. Yes, I guess that int would probably be a good choice for API and internal variables. Maybe bool or char could be used as member variables in classes, if memory usage is a concern (if we assume that there is no padding between member variables...). --- Conclusion: It is okay to _use_ bool, but we should avoid it in public API's in FLTK 1.3 (exceptions are possible). We should not change the API's in FLTK 1.3, but maybe in a later version... Is this okay/acceptable? Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
