jeremy-rifkin / libassert

The most over-engineered C++ assertion library
MIT License
547 stars 37 forks source link

Stringification customization #84

Closed huangqinjin closed 8 months ago

huangqinjin commented 8 months ago

There are several problems in current implementation, e.g., not allow to override default stringification, customization on enum and pointer does not work.

#if 1
template<> struct libassert::stringifier<int> {
    std::string stringify(int x) {
        return "this is a int " + std::to_string(x);
    }
};

template<> struct libassert::stringifier<int*> {
    std::string stringify(int*) {
        return "this is a int* ";
    }
};

template<> struct libassert::stringifier<std::errc> {
    std::string stringify(std::errc ec) {
        return libassert::detail::stringification::stringify(std::error_condition(ec));
    }
};
#endif

int main() {
    int x = 0;
    ASSERT(x, &x, std::errc{});
}
#endif

The above code outputs

    Where:
        x => 0
    Extra diagnostics:
        &x          => <instance of int*>
        std::errc{} => <instance of std::errc>

Current stringification relies on complicated and verbose and error-prone SFINAE. Since we are using C++17 now, if constexpr can reduce the use of SFINAE.

jeremy-rifkin commented 8 months ago

Thanks for opening this. The current system is definitely in need of work. It used to be implemented with a long if-constexpr chain and I think you’re right that it may be time to move back to that.

jeremy-rifkin commented 8 months ago

I'm going to close this, happy to discuss improvements further. I think there is likely still room for improvement.