ShouldWrite is a new thing in 2.0. It's set to a default value in each call so older code don't need to care about it if they don't want too. But it's still missing in many places.
For example in EbmlMaster::PushElement() it should not add elements that would otherwise not be written. This is also called internally in ProcessMandatory(). There's also AddNewElt() calling PushElement() so would require the same ShouldWrite usage.
Adding ShouldWrite to each call that can potentially end up with a write element is not only tedious, but it's inconsistent. If one part of the code uses one particular ShouldWrite and another uses a different one (like the default by not explicitly setting one), they might end up adding/writing elements that are not allowed by one or the other.
Using a state (SetWriteFilter, GetWriteFilter) allows consistency between the calls. The setter may refuse to set the new policy if it doesn't match the current state, or it could have a flag to force the new policy.
ShouldWrite is a new thing in 2.0. It's set to a default value in each call so older code don't need to care about it if they don't want too. But it's still missing in many places.
For example in
EbmlMaster::PushElement()it should not add elements that would otherwise not be written. This is also called internally inProcessMandatory(). There's alsoAddNewElt()callingPushElement()so would require the sameShouldWriteusage.Adding ShouldWrite to each call that can potentially end up with a write element is not only tedious, but it's inconsistent. If one part of the code uses one particular ShouldWrite and another uses a different one (like the default by not explicitly setting one), they might end up adding/writing elements that are not allowed by one or the other.
Using a state (SetWriteFilter, GetWriteFilter) allows consistency between the calls. The setter may refuse to set the new policy if it doesn't match the current state, or it could have a flag to force the new policy.