Boost C++ Libraries: Ticket #7028: NDEBUG should disable asserts even if BOOST_ENABLE_ASSERT_HANDLER is defined https://svn.boost.org/trac10/ticket/7028 <p> I have some components that require the use of a specific assert handler. </p> <p> Compiling those components in debug or release is something that should be fairly independent from the flags required to use my components. </p> <p> Therefore it would be more practical for me if when both BOOST_ENABLE_ASSERT_HANDLER and NDEBUG are defined the assert handler is not called. </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/7028 Trac 1.4.3 Mathias Gaunard Tue, 26 Jun 2012 11:31:15 GMT <link>https://svn.boost.org/trac10/ticket/7028#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:1</guid> <description> <p> Defining BOOST_DISABLE_ASSERTS instead of NDEBUG works. It would be good if both worked the same. </p> <p> It also appears that BOOST_ASSERT has the problem but not BOOST_ASSERT_MSG. </p> </description> <category>Ticket</category> </item> <item> <author>Kazutoshi Satoda <k_satoda@…></author> <pubDate>Sun, 02 Dec 2012 11:43:46 GMT</pubDate> <title>cc set https://svn.boost.org/trac10/ticket/7028#comment:2 https://svn.boost.org/trac10/ticket/7028#comment:2 <ul> <li><strong>cc</strong> <span class="trac-author">k_satoda@…</span> added </li> </ul> <p> +1 for "when both BOOST_ENABLE_ASSERT_HANDLER and NDEBUG are defined the assert handler is not called". </p> <p> Otherwise, a build configuration with BOOST_ENABLE_ASSERT_HANDLER needs additional control for BOOST_DISABLE_ASSERTS (unset for debug and set for release), which seems unreasonable because NDEBUG is already set (or unset) to take the same effect. </p> Ticket viboes Mon, 04 Feb 2013 21:57:56 GMT attachment set https://svn.boost.org/trac10/ticket/7028 https://svn.boost.org/trac10/ticket/7028 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">7028.patch</span> </li> </ul> <p> Is this patch enough? </p> Ticket viboes Mon, 04 Feb 2013 21:58:19 GMT owner, status changed https://svn.boost.org/trac10/ticket/7028#comment:3 https://svn.boost.org/trac10/ticket/7028#comment:3 <ul> <li><strong>owner</strong> changed from <span class="trac-author">No-Maintainer</span> to <span class="trac-author">viboes</span> </li> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">assigned</span> </li> </ul> Ticket Eric Niebler Thu, 14 Mar 2013 20:26:30 GMT <link>https://svn.boost.org/trac10/ticket/7028#comment:4 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:4</guid> <description> <p> I'm opposed to the suggested resolution, until I hear a better reason. If you don't want your assert handler invoked in release builds, then don't define <code>BOOST_ENABLE_ASSERT_HANDLER</code>. Simple. </p> <p> As the code is now, it is possible to turn <code>BOOST_ASSERT</code> into something like an <code>ENSURE</code> macro that leaves the checks in, even for release builds. This is important in safety-critical applications -- exactly the same applications where a custom assert handler makes the most sense. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>viboes</dc:creator> <pubDate>Thu, 14 Mar 2013 21:35:17 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/7028#comment:5 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:5</guid> <description> <p> Replying to <a class="ticket" href="https://svn.boost.org/trac10/ticket/7028#comment:4" title="Comment 4">eric_niebler</a>: </p> <blockquote class="citation"> <p> I'm opposed to the suggested resolution, until I hear a better reason. If you don't want your assert handler invoked in release builds, then don't define <code>BOOST_ENABLE_ASSERT_HANDLER</code>. Simple. </p> <p> As the code is now, it is possible to turn <code>BOOST_ASSERT</code> into something like an <code>ENSURE</code> macro that leaves the checks in, even for release builds. This is important in safety-critical applications -- exactly the same applications where a custom assert handler makes the most sense. </p> </blockquote> <p> What prevents the users to use the test directly in their code. What am I missing? </p> </description> <category>Ticket</category> </item> <item> <dc:creator>viboes</dc:creator> <pubDate>Thu, 14 Mar 2013 21:50:51 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/7028#comment:6 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:6</guid> <description> <p> Sorry, I have missed the history of this library. IUUC now the introduction of BOOST_ASSERT_MSG in <a class="changeset" href="https://svn.boost.org/trac10/changeset/68414" title="Add BOOST_ASSERT_MSG. Add macros to configure output stream.">[68414]</a> introduce the <code>defined(NDEBUG)</code> </p> <pre class="wiki">#if defined(BOOST_DISABLE_ASSERTS) || defined(NDEBUG) #define BOOST_ASSERT_MSG(expr, msg) ((void)0) </pre><p> which made BOOST_ASSERT_MSG to behave differently than BOOST_ASSERT. </p> <p> The introduction of BOOST_VERIFY using </p> <pre class="wiki">#if defined(BOOST_DISABLE_ASSERTS) || ( !defined(BOOST_ENABLE_ASSERT_HANDLER) &amp;&amp; defined(NDEBUG) ) </pre><p> made also a difference. </p> <p> So should we remove the use of defined(NDEBUG) and update the documentation of BOOST_ASSERT_MSG? </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Mathias Gaunard</dc:creator> <pubDate>Thu, 14 Mar 2013 21:55:42 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/7028#comment:7 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:7</guid> <description> <p> I'd rather BOOST_ASSERT be modified to behave like BOOST_ASSERT_MSG does. I see to no reason to have to depend on a BOOST_DISABLE_ASSERTS macro when NDEBUG exists precisely for that purpose. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Eric Niebler</dc:creator> <pubDate>Thu, 14 Mar 2013 22:04:33 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/7028#comment:8 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:8</guid> <description> <p> <code>NDEBUG</code> does what it is supposed to, except when <code>BOOST_ENABLE_ASSERT_HANDLER</code> is defined. That's how it's supposed to work. If you are building with <code>NDEBUG</code> defined and you want assertions removed, then don't define <code>BOOST_ENABLE_ASSERT_HANDLER</code>. Why would you, anyway? </p> </description> <category>Ticket</category> </item> <item> <dc:creator>viboes</dc:creator> <pubDate>Thu, 14 Mar 2013 22:19:48 GMT</pubDate> <title>type changed https://svn.boost.org/trac10/ticket/7028#comment:9 https://svn.boost.org/trac10/ticket/7028#comment:9 <ul> <li><strong>type</strong> <span class="trac-field-old">Bugs</span> → <span class="trac-field-new">Feature Requests</span> </li> </ul> <p> Replying to <a class="ticket" href="https://svn.boost.org/trac10/ticket/7028#comment:7" title="Comment 7">mgaunard</a>: </p> <blockquote class="citation"> <p> I'd rather BOOST_ASSERT be modified to behave like BOOST_ASSERT_MSG does. I see to no reason to have to depend on a BOOST_DISABLE_ASSERTS macro when NDEBUG exists precisely for that purpose. </p> </blockquote> <p> I don't know what will be the outcome of this issue, but BOOST_ASSERT implementation corresponds to the documentation, so I think that this must be handled as a feature request. </p> Ticket viboes Thu, 14 Mar 2013 22:28:09 GMT owner, status changed https://svn.boost.org/trac10/ticket/7028#comment:10 https://svn.boost.org/trac10/ticket/7028#comment:10 <ul> <li><strong>owner</strong> changed from <span class="trac-author">viboes</span> to <span class="trac-author">Peter Dimov</span> </li> <li><strong>status</strong> <span class="trac-field-old">assigned</span> → <span class="trac-field-new">new</span> </li> </ul> Ticket Mathias Gaunard Thu, 14 Mar 2013 22:32:32 GMT <link>https://svn.boost.org/trac10/ticket/7028#comment:11 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:11</guid> <description> <p> BOOST_ENABLE_ASSERT_HANDLER is a global flag (if asserts occur, I need to handle them in a specific way), while disabling assertions is a flag dependent on the build type. Both are orthogonal things. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Eric Niebler</dc:creator> <pubDate>Thu, 14 Mar 2013 22:35:07 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/7028#comment:12 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:12</guid> <description> <p> Mathias, can you explain why you would define <code>BOOST_ENABLE_ASSERT_HANDLER</code> when you don't want assertions? </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Mathias Gaunard</dc:creator> <pubDate>Thu, 14 Mar 2013 22:52:55 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/7028#comment:13 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:13</guid> <description> <p> If assertions occur, I need to print them or log them in a specific way. There is independent from whether assertions are enabled or not and is handled by different parts of my build system </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Eric Niebler</dc:creator> <pubDate>Thu, 14 Mar 2013 23:02:55 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/7028#comment:14 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:14</guid> <description> <p> IMO, "Because it makes my particular build setup simpler," isn't reason to change a long-standing and well-documented behavior. But I'll leave that for Peter to decide and quit this discussion. </p> <p> Regardless, <code>BOOST_ASSERT</code> and <code>BOOST_ASSERT_MSG</code> <em>must</em> be made consistent. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Steven Watanabe</dc:creator> <pubDate>Fri, 15 Mar 2013 02:44:57 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/7028#comment:15 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:15</guid> <description> <p> Replying to <a class="ticket" href="https://svn.boost.org/trac10/ticket/7028#comment:14" title="Comment 14">eric_niebler</a>: </p> <blockquote class="citation"> <p> Regardless, <code>BOOST_ASSERT</code> and <code>BOOST_ASSERT_MSG</code> <em>must</em> be made consistent. </p> </blockquote> <p> I agree, but... </p> <p> The only way to make it completely consistent is for BOOST_ASSERT_MSG to be implemented in terms of assert. </p> <pre class="wiki">#define NDEBUG #include &lt;boost/assert.hpp&gt; #undef NDEBUG #include &lt;cassert&gt; </pre><p> (I actually favor implementing BOOST_ASSERT_MSG using assert anyway, as I rather dislike the fact that boost/assert.hpp #includes &lt;iostream&gt;) </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Peter Dimov</dc:creator> <pubDate>Fri, 15 Mar 2013 18:29:30 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/7028#comment:16 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:16</guid> <description> <p> Interesting point Steven. What do you have in mind? The classic assert( expr &amp;&amp; "message" )? </p> <p> Regarding the main point: the original purpose of BOOST_ASSERT was to be exactly equivalent to assert unless overridden by one of the other macros. So, when nothing is defined, it maps to assert, and hence honors NDEBUG. When BOOST_DISABLE_ASSERTS is defined, this is taken as a request to disable BOOST_ASSERT, even when the ordinary asserts are active; and when BOOST_ENABLE_ASSERT_HANDLER is defined, for consistency, this is taken as a request "route all BOOST_ASSERT macros to this handler, even when the ordinary asserts are inactive". </p> <p> I can certainly see that in some use cases it is more convenient to make it do nothing in NDEBUG configurations even when BOOST_ENABLE_ASSERT_HANDLER is defined. Specifically, when BOOST_ASSERT is used as a library on its own. Its original purpose, however, was to provide a way for Boost libraries to use assertions in a way that can be controlled and overridden by the end user. Hence the current behavior. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Peter Dimov</dc:creator> <pubDate>Wed, 11 Dec 2013 17:39:38 GMT</pubDate> <title>status changed; resolution set https://svn.boost.org/trac10/ticket/7028#comment:17 https://svn.boost.org/trac10/ticket/7028#comment:17 <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> Ticket Peter Dimov Sat, 04 Jan 2014 17:06:52 GMT status changed; resolution deleted https://svn.boost.org/trac10/ticket/7028#comment:18 https://svn.boost.org/trac10/ticket/7028#comment:18 <ul> <li><strong>status</strong> <span class="trac-field-old">closed</span> → <span class="trac-field-new">reopened</span> </li> <li><strong>resolution</strong> <span class="trac-field-deleted">wontfix</span> </li> </ul> Ticket Peter Dimov Wed, 12 Feb 2014 00:31:02 GMT <link>https://svn.boost.org/trac10/ticket/7028#comment:19 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:19</guid> <description> <p> I've added support for the new macro BOOST_ENABLE_ASSERT_DEBUG_HANDLER, which works as requested. It disables assertions when NDEBUG is defined, and is equivalent to BOOST_ENABLE_ASSERT_HANDLER otherwise. </p> <p> <a class="ext-link" href="https://github.com/boostorg/assert/commit/f0e5bd15fb70c07ec943d01dc99aa4e507ceffe5"><span class="icon">​</span>https://github.com/boostorg/assert/commit/f0e5bd15fb70c07ec943d01dc99aa4e507ceffe5</a> </p> <p> This commit also redefines BOOST_ASSERT_MSG(expr,msg) as assert((expr)&amp;&amp;(msg)) by default, for consistency with BOOST_ASSERT. I'm open to suggestions as to how to optionally provide the old behavior of BOOST_ASSERT_MSG, suitably extended to BOOST_ASSERT as well. </p> </description> <category>Ticket</category> </item> <item> <author>chris.cooper@…</author> <pubDate>Mon, 14 Apr 2014 22:30:22 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/7028#comment:20 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:20</guid> <description> <p> I think assert_test.cpp needs changed too? </p> </description> <category>Ticket</category> </item> <item> <author>chris.cooper@…</author> <pubDate>Mon, 14 Apr 2014 23:03:25 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/7028#comment:21 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:21</guid> <description> <p> Replying to <a class="ticket" href="https://svn.boost.org/trac10/ticket/7028#comment:20" title="Comment 20">chris.cooper@…</a>: </p> <blockquote class="citation"> <p> I think assert_test.cpp needs changed too? </p> </blockquote> <p> Sorry, assert_test.cpp compiles just fine. I'm just confused on your intended usage ... in the patched version, line 59 looks like this: </p> <table class="wiki"> <tr>#if defined(BOOST_DISABLE_ASSERTS) <td> ( defined(BOOST_ENABLE_ASSERT_DEBUG_HANDLER) &amp;&amp; defined(NDEBUG) ) </td></tr></table> <p> so if I'm creating a release build (NDEBUG is defined) and I haven't defined BOOST_DISABLE_ASSERTS, then by defining BOOST_ENABLE_ASSERT_DEBUG_HANDLER, it disables BOOST_ASSERT_MSG (by #defining it to (void)0). So by defining a macro whose name contains ENABLE, I am disabling the ASSERT functionality? </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Peter Dimov</dc:creator> <pubDate>Tue, 15 Apr 2014 08:39:36 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/7028#comment:22 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7028#comment:22</guid> <description> <p> In NDEBUG builds, when nothing else is defined, BOOST_ASSERT_MSG(expr, msg) is defined as assert((expr)&amp;&amp;(msg)), which is also the equivalent of ((void)0). So defining BOOST_ENABLE_ASSERT_DEBUG_HANDLER doesn't disable it any further. </p> </description> <category>Ticket</category> </item> </channel> </rss>