[MPlayer-dev-eng] int vs. bool

[Reimar Döffinger]

On Mon, Dec 03, 2012 at 09:53:19PM +0100, Ingo Brückl wrote:
> Reimar Döffinger wrote on Sat, 1 Dec 2012 17:16:15 +0100:
> 
> > And a GUI_TRUE and GUI_FALSE define would avoid most of the issues,
> > a few more if combined with an enum.
> > I just have the feeling that it will at best make the code uglier.
> 
> These defines certainly would. They are too bulky.
> 
> (Just curious: What issues would be avoided with an enum in that case?)

Type safety, at least with the right compiler settings you can make
sure that if (bool_var == TRUE) actually works and has the same effect
as if (bool_var)

> > Otherwise the BOOL type name and TRUE/FALSE from Windows might be usable, I
> > think it is simply defined to unsigned normally.
> 
> Well, rather than a data type (that couldn't force correct usage of the two
> possible values in C anyway, so int would be ok) I'd be in need of nice and
> short symbolic constants for 0 and 1.
> 
> TRUE/FALSE are defined in GLib, too, and I could use True/False from X11 as
> well, but I don't want to make the whole GUI code (especially the future
> "common" part) depend on GLib or X11 headers.

Since AFAIK those are macros, providing fallback implementations should
not be an issue.
However it would mean you'd have to be sure that X11/Glib headers are
always included before the fallback header to avoid redefinition
warnings.

> I cannot see a problem in defining true/false if checked with #ifdef first,
> but I could warm to something like yes/no otherwise.

As long as you are absolutely sure nobody will ever try to use a C++
compiler on the code. true/false are not macros in C++, so an ifdef does
not help.
Nobody uses yes/no, so this would probably be irritating/confusing for
anyone new to the code.
Though maybe I am just biased due to being used to just use 0/1 without
thinking more about it.