On Thursday, September 08, 2011 07:13:48 Steven Schveighoffer wrote: > On Wed, 07 Sep 2011 03:30:17 -0400, Jacob Carlborg <[email protected]> wrote: > > On 2011-09-06 19:39, Steven Schveighoffer wrote: > >> I like enums in terms of writing code that processes them, but in > >> terms > >> of calling functions with them, I mean look at a sample fstream > >> constructor in C++: > >> > >> fstream ifs("filename.txt", ios_base::in | ios_base::out); > >> > >> vs. > >> > >> File("filename.txt", "r+"); // or "rw" > >> > >> There's just no way you can think "rw" is less descriptive or > >> understandable than ios_base::in | ios_base::out. > >> > >> -Steve > > > > BTW, I think that using: > > > > Mode.read | Mode.write > > > > Instead of "rw" is the same thing as one should name variables with a > > proper descriptive names instead of just "a" or "b". > > It's not the same. "a" and "b" do not have any meaning, they are just > variable names. "r" stands for read and "w" stands for write. It's > pretty obvious that they do, especially in the context of opening a file. > > I'd equate it to using i, j, k for index variables -- they are not > descriptive, but in context, everyone knows what they mean. > > And in response to the discussion about enum flags not being & or | > together, I emphatically think enums should be used for bitfields. > Remember, enum is not just an enumeration, it's a manifest constant. I > see no reason that we should not use the namespace-creation ability of > enum to create such constants. I don't see the downside.
I think that it makes perfect sense to use enums for flags. What I don't think makes sense is making the type of the variable which holds the flags to be that enum type unless _every_ possible combination of flags has its own flag so that &ing or |ing enums always results in a valid enum. I have no gripe with using enums for flags. It's using an enum to hold a value which is not a valid value for that enum which is the problem IMHO. - Jonathan M Davis
