Factor out the common fields in the UMP processor types. #11
Conversation
Created a umpCommon struct which contains the fields that are common to umpCMD, umpGeneric, and umpData. There was a suggestion that inheritance could be used in this situation, but I've gone with the "prefer aggregation to inheritance" and added a "common" field instead!
|
@paulhuggett I can see what you are trying to do with this PR, however I have some concerns with changing the way users have to interact with the library. For example this changes from: To: This library is now being packed up in Microsoft VC PKG and is (potentially) being used in the new MIDI Service Engine and I'd prefer not to break what they are doing. If you think this is an important change I can hit up the MS guys to see what they think? |
I didn't realise that the library API is at least to some extent frozen. From my POV, the change would be a small improvement, but certainly not a hill to die on. I think the simplified initialization is worth keeping, so I'll create a separate PR for that. |
Following the suggestion by @dhjdhj in #3, I thought I'd have a stab at the change!
Created a umpCommon struct which contains the fields that are common to umpCVM, umpGeneric, and umpData. There was a suggestion that inheritance could be used in this situation, but I've gone with the "prefer aggregation to inheritance" maxim and added a "common" field instead!
I replaced the default ctors of these types with direct member initialization. This should be a no-op from the POV of the generated code with the exception that I've initialized the
umpDatadataanddataLengthfields to nullptr and 0 respectively for safety.