Boost C++ Libraries: Ticket #3338: proto: const-correctness issue on transforms (array types) https://svn.boost.org/trac10/ticket/3338 <p> This has been extracted from Spirit2 test failures on gcc in C++0x mode (e.g. <a class="ext-link" href="http://tinyurl.com/mmo2ym"><span class="icon">​</span>http://tinyurl.com/mmo2ym</a>). When adding this line to Proto's matches.cpp test: </p> <pre class="wiki">Index: matches.cpp =================================================================== --- matches.cpp (revision 55531) +++ matches.cpp (working copy) @@ -172,6 +172,8 @@ assert_matches&lt; terminal&lt;char [N]&gt; &gt;( as_child("hello") ); assert_matches&lt; terminal&lt;char [N]&gt; &gt;( as_expr("hello") ); + assert_not_matches&lt; if_&lt;is_same&lt;_value, int&gt;()&gt; &gt;( lit("hello") ); + assert_matches&lt; terminal&lt;std::string&gt; &gt;( lit(std::string("hello")) ); assert_matches&lt; terminal&lt;std::string&gt; &gt;( as_child(std::string("hello")) ); assert_matches&lt; terminal&lt;std::string&gt; &gt;( as_expr(std::string("hello")) ); </pre><p> the test no longer compiles on gcc-4.3 or later in C++0x mode, although it works fine in non-C++0x mode. </p> <p> The error is not the <code>is_same</code> check failing, but happens during instantiation of <code>proto::_value</code>: </p> <pre class="wiki">In file included from matches.cpp:16:0: boost/proto/transform/arg.hpp: In instantiation of '_value::impl&lt;exprns_::expr&lt;tag::terminal, argsns_::term&lt;const char (&amp;)[6]&gt;, 0l&gt;, int, int&gt;': ... boost/proto/transform/arg.hpp:203:13: error: function returning an array </pre><p> <br /> </p> <p> AFAICT the issue is always there, but becomes visible due to <code>BOOST_HAS_DECLTYPE</code> (which gets defined in C++0x mode, and modifies the result types of several transforms in <code>transform/arg.hpp</code>). Considering <code>_value::impl</code> here: </p> <ul><li>It is called with a terminal containing a <code>char const (&amp;)[6]</code>, </li><li><code>result_type</code> is always <code>result_of::value&lt;Expr&gt;::type</code> -- here <code>char*</code>, which seems incorrect (missing <code>const</code>), </li><li>When <code>BOOST_HAS_DECLTYPE</code> is defined, the return type of <code>operator()</code> is <code>result_type</code> so this generates a compilation error, </li><li>When it is not defined, the return type of <code>operator()</code> becomes <code>result_of::value&lt;typename impl::expr_param&gt;::type</code> -- here <code>char const (&amp;)[6]</code>, so the test compiles. </li></ul> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/3338 Trac 1.4.3 Eric Niebler Tue, 18 Aug 2009 20:04:58 GMT status changed; resolution set https://svn.boost.org/trac10/ticket/3338#comment:1 https://svn.boost.org/trac10/ticket/3338#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">fixed</span> </li> </ul> <p> (In <a class="changeset" href="https://svn.boost.org/trac10/changeset/55656" title="fix proto::_value array handling under C++0x mode, fixes #3338">[55656]</a>) fix proto::_value array handling under C++0x mode, fixes <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/3338" title="#3338: Bugs: proto: const-correctness issue on transforms (array types) (closed: invalid)">#3338</a> </p> Ticket François Barel <frabar666@…> Thu, 03 Sep 2009 21:16:22 GMT attachment set https://svn.boost.org/trac10/ticket/3338 https://svn.boost.org/trac10/ticket/3338 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">proto-3338.patch</span> </li> </ul> <p> Same fix for _child_c </p> Ticket François Barel <frabar666@…> Thu, 03 Sep 2009 21:18:31 GMT keywords, status, milestone changed; resolution deleted https://svn.boost.org/trac10/ticket/3338#comment:2 https://svn.boost.org/trac10/ticket/3338#comment:2 <ul> <li><strong>keywords</strong> _child_c added </li> <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">fixed</span> </li> <li><strong>milestone</strong> <span class="trac-field-old">Boost 1.40.0</span> → <span class="trac-field-new">Boost 1.41.0</span> </li> </ul> <p> Thanks Eric. You applied the fix on <code>_value</code>, but I think <code>_child_c</code> needs the same one, so that: </p> <pre class="wiki">assert_not_matches&lt; if_&lt;is_same&lt;_child_c&lt;0&gt;, int&gt;()&gt; &gt;( lit("hello") ); </pre><p> also passes. I attached a patch which does that. </p> Ticket Eric Niebler Thu, 03 Sep 2009 22:31:53 GMT status changed; resolution set https://svn.boost.org/trac10/ticket/3338#comment:3 https://svn.boost.org/trac10/ticket/3338#comment:3 <ul> <li><strong>status</strong> <span class="trac-field-old">reopened</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">invalid</span> </li> </ul> <p> No, <code>child_c</code> should not be used to extract a value from a terminal expression. Doing so violates <code>child_c</code>'s documented preconditions. Use <code>value</code> for that. </p> Ticket