The addition of NoTable is great; it's helpful for reclaiming a kilobyte or two on very constrained embedded systems. But, it only works if the user is vigilant about always doing Crc::<_, NoTable>::new() to specify the implementation they want. (Even if they use a OnceCell as suggested, nothing prevents someone elsewhere in the app or in a library from directly doing Crc::new() to get a default implementation.)
It would be nice if there were feature flags to enable implementations, so that a user could make NoTable the only available implementation, thereby preventing the larger Table<1> from creeping back into their binary by mistake.
Conversely, other users might want to make Table<16> the only available implementation, so that it's impossible to accidentally create a Crc using a slower Table<1> implementation.
The addition of
NoTable
is great; it's helpful for reclaiming a kilobyte or two on very constrained embedded systems. But, it only works if the user is vigilant about always doingCrc::<_, NoTable>::new()
to specify the implementation they want. (Even if they use aOnceCell
as suggested, nothing prevents someone elsewhere in the app or in a library from directly doingCrc::new()
to get a default implementation.)It would be nice if there were feature flags to enable implementations, so that a user could make
NoTable
the only available implementation, thereby preventing the largerTable<1>
from creeping back into their binary by mistake.Conversely, other users might want to make
Table<16>
the only available implementation, so that it's impossible to accidentally create aCrc
using a slowerTable<1>
implementation.