{"action":"created","issue":{"url":"https://api.github.com/repos/boostorg/math/issues/38","repository_url":"https://api.github.com/repos/boostorg/math","labels_url":"https://api.github.com/repos/boostorg/math/issues/38/labels{/name}","comments_url":"https://api.github.com/repos/boostorg/math/issues/38/comments","events_url":"https://api.github.com/repos/boostorg/math/issues/38/events","html_url":"https://github.com/boostorg/math/pull/38","id":153343338,"number":38,"title":"Fix corner cases for raise_error","user":{"login":"kundor","id":75901,"avatar_url":"https://avatars.githubusercontent.com/u/75901?v=3","gravatar_id":"","url":"https://api.github.com/users/kundor","html_url":"https://github.com/kundor","followers_url":"https://api.github.com/users/kundor/followers","following_url":"https://api.github.com/users/kundor/following{/other_user}","gists_url":"https://api.github.com/users/kundor/gists{/gist_id}","starred_url":"https://api.github.com/users/kundor/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kundor/subscriptions","organizations_url":"https://api.github.com/users/kundor/orgs","repos_url":"https://api.github.com/users/kundor/repos","events_url":"https://api.github.com/users/kundor/events{/privacy}","received_events_url":"https://api.github.com/users/kundor/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2016-05-05T22:46:29Z","updated_at":"2016-05-08T17:28:53Z","closed_at":"2016-05-08T15:54:43Z","pull_request":{"url":"https://api.github.com/repos/boostorg/math/pulls/38","html_url":"https://github.com/boostorg/math/pull/38","diff_url":"https://github.com/boostorg/math/pull/38.diff","patch_url":"https://github.com/boostorg/math/pull/38.patch"},"body":"This addresses three issues in `raise_error(const char* function, const char* message, const T& val)`.\r\n\r\nFirst, when BOOST_NO_RTTI is defined, the code was replacing the `%1%` in both the `function` string and the `message` string with the value of `val`, with nonsensical results. Now it formats `message` separately before appending it to the string.\r\n\r\nSecond, when either `function` or `message` did not contain `%1%`, `boost::format` was throwing a `boost::too_many_args` exception (instead of the exception we are trying to throw!)\r\nThe [documentation](http://www.boost.org/doc/libs/1_60_0/libs/math/doc/html/math_toolkit/pol_ref/error_handling_policies.html#math_toolkit.pol_ref.error_handling_policies.h4) suggests this should work:\r\n\r\n> Note that the strings _function_ and _message_ may contain \"%1%\" format\r\n> specifiers designed to be used in conjunction with Boost.Format. If\r\n> these strings are to be presented to the program's end-user then the\r\n> \"%1%\" format specifier should be replaced with the name of type T in\r\n> the _function_ string, and if there is a %1% specifier in the _message_\r\n> string then it should be replaced with the value of _val_.\r\n\r\nThird, whenever the type `T` did not have a `std::numeric_limits` specialization, there was a compile-time failure because of a static assertion of `::std::numeric_limits<T>::is_specialized` in `tools::digits` (in tools/precision.hpp.)\r\n\r\nNote that in `policies::digits()` (in policies/policy.hpp) there seems to be an attempt to avoid this, by delegating to one function when `std::numeric_limits<T>::is_specialized` is `true` and calling `tools::digits` when it is `false`, but then `tools::digits` asserts the opposite.\r\n\r\nInstead, this proposal just avoids setting the precision at all when `T` has no `std::numeric_limits` specialization.\r\n\r\nThis allows, e.g., to call `raise_domain_error` for a function dealing with `tools::polynomial<T>`."},"comment":{"url":"https://api.github.com/repos/boostorg/math/issues/comments/217735022","html_url":"https://github.com/boostorg/math/pull/38#issuecomment-217735022","issue_url":"https://api.github.com/repos/boostorg/math/issues/38","id":217735022,"user":{"login":"jzmaddock","id":5011768,"avatar_url":"https://avatars.githubusercontent.com/u/5011768?v=3","gravatar_id":"","url":"https://api.github.com/users/jzmaddock","html_url":"https://github.com/jzmaddock","followers_url":"https://api.github.com/users/jzmaddock/followers","following_url":"https://api.github.com/users/jzmaddock/following{/other_user}","gists_url":"https://api.github.com/users/jzmaddock/gists{/gist_id}","starred_url":"https://api.github.com/users/jzmaddock/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jzmaddock/subscriptions","organizations_url":"https://api.github.com/users/jzmaddock/orgs","repos_url":"https://api.github.com/users/jzmaddock/repos","events_url":"https://api.github.com/users/jzmaddock/events{/privacy}","received_events_url":"https://api.github.com/users/jzmaddock/received_events","type":"User","site_admin":false},"created_at":"2016-05-08T17:28:53Z","updated_at":"2016-05-08T17:28:53Z","body":"Looking at this again, it's not quite the whole answer (or right answer), the intention was that whenever the library is used with a type with no numeric_limits support, was that it would specialize a small number of functions, tools::digits being one of them.  Unfortunately, because you can't partially specialize a function, we can't do that for a generic polynomial<T>  :("}}