Boost C++ Libraries: Ticket #9234: noexcept creation of a number from string https://svn.boost.org/trac10/ticket/9234 <p> One of the benefits of using fixed-sized numbers is to avoid EH in ones code. It is then a bit 'sad' that one has to pay for EH codegen in the "from char const *" constructor which checks if the passed string is valid...please provide a way to specify to the library that construction will/must succeed (and should be check with an assert, not a throw)... </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/9234 Trac 1.4.3 John Maddock Fri, 11 Oct 2013 17:36:16 GMT status changed; resolution set https://svn.boost.org/trac10/ticket/9234#comment:1 https://svn.boost.org/trac10/ticket/9234#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> </ul> <p> Define BOOST_NO_EXCEPTIONS when building? </p> <p> In any case, a runtime check is appropriate here, and the cost (yes even of a try/catch block) is likely to be trivially small compared to construction from string in general. </p> Ticket Domagoj Šarić Sat, 12 Oct 2013 11:21:40 GMT <link>https://svn.boost.org/trac10/ticket/9234#comment:2 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/9234#comment:2</guid> <description> <ul><li>BOOST_NO_EXCEPTIONS disables exceptions for all Boost, that's not what I want...Exception semantics and overhead maybe appropriate in someplaces while not in others, IMNHO a subset of fixed-sized mathematical operations where I know in advance nothing should fail is one such place </li></ul><p> <br /> </p> <ul><li>the problem with (needless) EH is not (just) speed but bloat, you certainly know that any non-noexcept function makes all of its callers also non-noexcept and inserts EH code in all of them if they have objects with non trivial desctructors (which with MSVC is sadly even an empty but explicitly defined destructor) as well as it hinders things like inlining </li></ul><p> <br /> </p> <ul><li>in my use case for example I might know that I am passing a valid (possibly hardcoded) string and the only way your constructor can fail is if some hacker has fiddled with the binary in which case I don't want any expected error handling route to be taken (a call to throw is certainly one of them)...I really do want the process to visit a random star in the access vioalation galaxy using the undefined behaviour spaceship and then crash and burn there! </li></ul><p> <br /> </p> <ul><li>you might consider using boost::string_ref now to simplify your code </li></ul><p> I won't reopen this ticket, I'll rather create a new one for noexcept fixedsized unchecked unsigned cpp_ints... </p> </description> <category>Ticket</category> </item> </channel> </rss>