Abstraction is only a tool, a means to an end; not the end in itself.
> Which is extremely fast, simple, side-effect-free, and likely optimized away by RVO.
Copying is one of the fastest things a processor can do, but that's not a reason to do it unnecessarily, even if the compiler optimiser could simplify it.
> That's also not an issue of "simplification"; it's just premature optimization.
Really? I suppose that if you consider abstraction the ultimate goal, you might think that shorter, simpler code would be "premature optimization"...
> Part of the design is that each individual board is responsible for translating button presses to USB keycode deltas.
That functionality remains the same; the receiving board just collects each bit of the scancode and passes it through directly to the USB. The sending board is still the one doing the matrix scan and position-to-keycode translation. The receiving board is just a passthrough.
> What's the downside to this? The bursts occur way faster than human perception could hope to notice.
It adds complexity to the software, because it has to deal with start/stop conditions, etc.
> Besides, if you want to be pedantic, any serial protocol communicates in "bursts".
Not if the clock is continuous; once the receiver and sender are synchronised, the sender can e.g. keep transmitting 0 bytes when there is nothing to send, and keycodes (which are all nonzero) otherwise.
Abstraction is only a tool, a means to an end; not the end in itself.
> Which is extremely fast, simple, side-effect-free, and likely optimized away by RVO.
Copying is one of the fastest things a processor can do, but that's not a reason to do it unnecessarily, even if the compiler optimiser could simplify it.
> That's also not an issue of "simplification"; it's just premature optimization.
Really? I suppose that if you consider abstraction the ultimate goal, you might think that shorter, simpler code would be "premature optimization"...
> Part of the design is that each individual board is responsible for translating button presses to USB keycode deltas.
That functionality remains the same; the receiving board just collects each bit of the scancode and passes it through directly to the USB. The sending board is still the one doing the matrix scan and position-to-keycode translation. The receiving board is just a passthrough.
> What's the downside to this? The bursts occur way faster than human perception could hope to notice.
It adds complexity to the software, because it has to deal with start/stop conditions, etc.
> Besides, if you want to be pedantic, any serial protocol communicates in "bursts".
Not if the clock is continuous; once the receiver and sender are synchronised, the sender can e.g. keep transmitting 0 bytes when there is nothing to send, and keycodes (which are all nonzero) otherwise.