Just wanted to point out that I get a compile error when using multiple flags for a parameter that takes an enum value, such as that required by createSound and createStream.
[code:2y2sezhu]Result = FMOD_System_CreateStream(FMODInstance,
The code shown above produces the following compiler error: [b:2y2sezhu]cannot convert parameter 3 from ‘int’ to ‘FMOD_MODE'[/b:2y2sezhu]. Before you suggest it, adding an explicit cast to FMOD_MODE doesn’t work either.
If it makes any difference, I’m compiling my application under VC8.
- Bruce asked 12 years ago
[quote="brett":9ikyy0u9]actually, you’re partially wrong because the biggest problem is not that, it is the fact they don’t know where to look when they see unsigned int.[/quote:9ikyy0u9]
I see where you’re going here. The idea is so that the user can guess the expected type from the function prototype. While I agree that [b:9ikyy0u9]function(modetype,string)[/b:9ikyy0u9] is clearer than [b:9ikyy0u9]function(unsigned int,string)[/b:9ikyy0u9], you don’t need to use enums to accomplish this. C++ enums were designed so that you choose one value from the enumeration; no more, no less. You’re applying them to a situation they weren’t designed for. The right tool for the job would be a typedef.
Before you shoot me down on this, hear me out. I’m fully aware that a typedef is nothing more than an alias for another type, and that the compiler makes no distinction between the typedef alias and its underlying type. However, the user will see the typedef’s name in an FMOD function declaration and immediately know where to look for valid flags to pass to that function. That [i:9ikyy0u9]is[/i:9ikyy0u9] your goal, right?
[code:9ikyy0u9]typedef unsigned int TYPE1;
typedef unsigned int TYPE2;
const TYPE1 TYPE1_VALUE1 = 0x0001;
const TYPE1 TYPE1_VALUE2 = 0x0002;
const TYPE1 TYPE1_VALUE3 = 0x0004;
const TYPE2 TYPE2_VALUE1 = 0x0001;
const TYPE2 TYPE2_VALUE2 = 0x0002;
bool Function (string Foo,TYPE1 Flags);[/code:9ikyy0u9]
Given the above declarations, if a user is dense enough to pass (for example) TYPE2_VALUE1 as the second parameter to Function(), then it’s their own stupid fault, since they had plenty of information beforehand (even without reading the documentation) to know better.
Okay, I get it now. I have to put parentheses around the combined flags and cast the [i:1gpd1ims]combination[/i:1gpd1ims]. My fault.
Though, this is bad coding practice for a library, methinks. I should not have to cast flags into the proper type to pass to a function that is designed to take those flags. I’ll accept it, though, because it’s more of a language issue than anything–C++ by nature apparantly makes no provisions for combining enum values (it coerces the combination to an integral type). At the very least, this should be documented. I was very surprised when I ran into this issue.
[quote="brett":1qp4yyk9]Yes, well we get more people messing up types and putting the wrong flags in wrong functions (ie fmod 3 had people putting FSOUND_FREE as a mode bit in FSOUND_Sample_SetMode for example because they didnt read the documentation and the types were plain integers).[/quote:1qp4yyk9]
The problem is, the enum approach doesn’t even begin to solve this. Think about it. If a user has to perform an explicit cast in order to pass multiple flags, then it won’t stop users from passing an incorrect flag to a function any more effectively than plain integer flags will. To prove my point, the following code is perfectly valid to the compiler:
[code:1qp4yyk9]Result = FMOD_System_CreateStream(FMODInstance,
I suspect that the new flags are named clearly enough in FMOD Ex that users won’t make such stupid mistakes. The only reason it happened in FMOD 3 is because a lot of things weren’t clearly named; constants like [b:1qp4yyk9]FSOUND_FREE[/b:1qp4yyk9] are quite abstract in their naming and could be interpreted a number of ways, depending on context.
To summarize, you’re implementing a type checking system and simultaneously forcing users to defeat it. That’s like saying to someone “advance (1 + -1) steps”. The person gets nowhere.
Please login first to submit.