Why did the implementation of alure::AttributePair changed from std::pair to struct? about alure

[Cazadorro]

I'm unsure of the exact reasoning, but I can tell you for me, std::pair is kind of annoying to deal with, .first and .second don't really specify what the members mean, plus AttributePair is self documenting in a way.

&std::get<0>(attrs.front()) is way less readable than &attrs.front().mAttribute in my opinion. I don't really have an easy place to figure out what conceptual member I'm std::geting. mAttribute makes this easy, I'm getting a reference to the attribute part of the attribute pair array. It also has the added bonus of auto-completing in the IDE so I technically have less to type (not that this is a reason to change it).

This is a common pattern outside of this repo as well, and even in other languages.

[kcat]

The AttributePair struct, besides giving more descriptive names to the members, helps guarantee the attribute and value are stored in a trivially copyable type, essentially meaning the raw data can be accessed (std::pair is rather complicated when it comes to being trivial). The reason for this is the same reason the attributes need null termination, because it's passed directly to OpenAL without further interpretation. OpenAL itself requires either a null attribute list, or a contiguous sequence of integers representing a series of {attribute, value} pairs that ends with a 0 attribute. If the array given to Alure doesn't have the null termination, it needs to be copied to ensure there is one.

The reason std::unordered_map can't be used is because of that contiguous layout requirement. Also, despite its name, an unordered_map does have ordering, just that the app can't rely on any particular order (it uses hashed keys, where the hashing algorithm is implementation-defined).

[McSinyx]

Thank you both for the prompt explanation! My mind now settled so I can continue on wrapping this in Cython. I guess I can close the issue at this moment.