You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Inside can_message.hpp, there are three constructors for modm::can::Message: The first one leaves the message data initialized with all zeros and keep the default flags; this results in extended being true by default. The remaining two constructors allow for initializing with data and have an extended parameter which is false by default.
I realize this is a relatively small and breaking change, but I think it would be ideal if extended was always false by default, and if the first constructor had an extended parameter, to avoid having to declare an extra array like this:
I'm also tending more towards having all bits zero initialized (thus extended=0) in the default constructor. However, if we're going to break the behavior (silent failure), then we should also break the interface entirely (compilation failure). I personally don't like the CAN Message class very much, perhaps there is a better way to model this.
Inside
can_message.hpp
, there are three constructors formodm::can::Message
: The first one leaves the message data initialized with all zeros and keep the default flags; this results inextended
being true by default. The remaining two constructors allow for initializing with data and have anextended
parameter which is false by default.I realize this is a relatively small and breaking change, but I think it would be ideal if
extended
was always false by default, and if the first constructor had anextended
parameter, to avoid having to declare an extra array like this:The text was updated successfully, but these errors were encountered: