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
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 text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: