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
Right now, users cannot change how Catch2 stringifies types that it provides StringMaker specializations for, such as float or double. This is due
to the stringification priority being StringMaker<T> -> operator<< ->
fallbacks (enum handler, range handler, etc).
However, users often want to customize the output, e.g. the printed
precision for floating point types.
There are three ways to handle this, none of them particularly great.
Provide customization knobs that the users can use to do what they want.
This option means that there is approximately infinity work to do, and
the customization options and desires can be mutually exclusive as well.
Allow piecemeal disabling of each StringMaker specialization, e.g. CATCH_CONFIG_DISABLE_FLOAT_STRINGMAKER, or CATCH_CONFIG_DISABLE_DOUBLE_STRINGMAKER.
This option adds a ton of configuration macros, which the users
are already bad at using -> it is common for users to build the impl.
library and their own tests with different configuration options, thus
breaking ODR.
Hide Catch2-provided stringifiers behind another layer of indirection,
e.g. StringMakerInternal, used from the generic StringMaker template.
This allows the users to provide specialization of StringMaker and
have their specialization be used instead of ours. This is the best
technical approach, but has the disadvantage of causing potentially
significant compile time overhead.
Of these three options, only the last one is reasonable to implement, but we need to measure the compile time overhead first, and decide
based on the final values.
The text was updated successfully, but these errors were encountered:
Right now, users cannot change how Catch2 stringifies types that it provides
StringMaker
specializations for, such asfloat
ordouble
. This is dueto the stringification priority being
StringMaker<T>
->operator<<
->fallbacks (
enum
handler,range
handler, etc).However, users often want to customize the output, e.g. the printed
precision for floating point types.
There are three ways to handle this, none of them particularly great.
This option means that there is approximately infinity work to do, and
the customization options and desires can be mutually exclusive as well.
StringMaker
specialization, e.g.CATCH_CONFIG_DISABLE_FLOAT_STRINGMAKER
, orCATCH_CONFIG_DISABLE_DOUBLE_STRINGMAKER
.This option adds a ton of configuration macros, which the users
are already bad at using -> it is common for users to build the impl.
library and their own tests with different configuration options, thus
breaking ODR.
e.g.
StringMakerInternal
, used from the genericStringMaker
template.This allows the users to provide specialization of
StringMaker
andhave their specialization be used instead of ours. This is the best
technical approach, but has the disadvantage of causing potentially
significant compile time overhead.
Of these three options, only the last one is reasonable to implement,
but we need to measure the compile time overhead first, and decide
based on the final values.
The text was updated successfully, but these errors were encountered: