The new C4Value constructors look wrong: Set already calls AddDataRef(), calling it again will probably cause memory leaks. And DelDataRef is not designed to be called on undefined data. The constructor really has to do to the work itself.
Also, having C4Value::Set default to C4V_Nil doesn't seem save, there might be code which relies on CnvGuess. Better to remove the default entirely than this.
And I don't think we need a new type for this. As far as I can see, the only benefit is that false and zero the integer are distinct from zero the nullpointer. Zero the nullpointer can continue to use the type any. We should rather remove any uses of CnvGuess now that we don't need to load old savegames anymore.
Also, having C4Value::Set default to C4V_Nil doesn't seem save, there might be code which relies on CnvGuess. Better to remove the default entirely than this.
And I don't think we need a new type for this. As far as I can see, the only benefit is that false and zero the integer are distinct from zero the nullpointer. Zero the nullpointer can continue to use the type any. We should rather remove any uses of CnvGuess now that we don't need to load old savegames anymore.
>the only benefit is that false and zero the integer are distinct from zero the nullpointer.
And a lot about parameters would change. Currently we have the problem that, for example, you cannot play a sound (via Sound()) only for the player with the number 0. Why? Because 0 means "for all" there. nil would make stuff like that a lot easier, because it would remove such ambiguities
First: You can. You specify PlayerNumber+1 for per-player sounds. Which is, of course, error-prone. But this is something we should fix by changing player numbers to start counting from 1. It's a change I wanted do do for a long time, but couldn't because of backwards compatibility.
Imo, adding another element of confusion is *not* helpful in this case. Because it would mean we'd have to change certain parameters to accept two possible types (in this case, integer and nil) and "nil" would have different meanings for different functions. It is much more straightforward to define constants of the correct type. In this case, it would be Sound(..., NO_OWNER); or you could make it something like Sound(..., SND_AllPlayers) if you wanted to. Other examples of this method include NoContainer/AnyContainer - something you can't do with nil, since there's only one nil.
Imo, adding another element of confusion is *not* helpful in this case. Because it would mean we'd have to change certain parameters to accept two possible types (in this case, integer and nil) and "nil" would have different meanings for different functions. It is much more straightforward to define constants of the correct type. In this case, it would be Sound(..., NO_OWNER); or you could make it something like Sound(..., SND_AllPlayers) if you wanted to. Other examples of this method include NoContainer/AnyContainer - something you can't do with nil, since there's only one nil.
Er, that's exactly what I said. And you don't need a new type for that, just not forcing all zeros to be of type any will get you that.
Another benefit is that you can distinguish between a function with no return value (returning nil then) and a function returning 0.
No, that's also the same as "false and zero the integer are distinct from zero the nullpointer". Or at least a direct consequence. And it's not very useful, there are lots of values a function could have returned to indicate that it has a result that is not an integer.
Isilkor already addressed my concerns, nil now has type C4V_Any and the other problems are resolved.
Isilkor already addressed my concerns, nil now has type C4V_Any and the other problems are resolved.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill