Vector vs HashMap; Attribute Values

[Vergil]

Hi, just curious as to your reasoning for choosing vectors over hash-maps for the organization of the members of the DBC struct.

I was also curious if you planned on associating attribute_values that pertain directly to signals/messages in the signals/messages themselves rather than a completely seperate vector in the DBC struct. I've found myself wanting to have those available with the messages themselves rather than looking up the message THEN looking up the attribute_values.

Just curious as to your thoughts.

Thanks for the work done on this, it has greatly assisted me to do some rapid development with CAN.

[Marcel]

Thanks for bearing with me.

The reason why attribute value is not part of the Message struct is mostly due the DBC struct basically just following the layout of a DBC file format. Since attribute values are not directly associated with the message in the format they are also not part of the Message in the library. I can imagine that the use cases for iterating over the attribute_values without looking at the message are rare though.

So mostly I used vectors since picking the key for the HashMaps i assume is often application specific. Although e.g. for dbc.messages I assume it could e.g. be MessageId.

I'd like to keep the DBC struct the way it is just so it's consistent with the DBC format. But maybe an option is adding a second struct as an attempt of a more useful structure.

[Vergil]

Ah, that makes a lot more sense when thinking about it from the perspective of the file format.
I agree then. Keeping it consistent within that format is more important than trying to change one portion of it for the sake of usefulness.

I like the idea of a second struct, though that could probably almost end up turning into another library itself, and I imagine it would require some heavily modified parsing to accomplish.