https://svn.boost.org/trac10/ticket/12117 <p> I would expect that the constructors taking a ordered_unique_range_t would assert that the passed range indeed is sorted and unique according to the sorting criteria of the flat_set. </p> <p> e.g. I'd expect the following code to assert, but instead it prints 0 </p> <pre class="wiki">#include &lt;boost/container/flat_set.hpp&gt; #include &lt;iostream&gt; using namespace std; using namespace boost::container; int main() { auto l = {3, 2, 1}; flat_set&lt;int&gt; s (ordered_unique_range, l); cout &lt;&lt; s.count(1) &lt;&lt; endl; } </pre><p> I think the constructor should use std::is_sorted (or the Boost equivalent) to assert that the passed range indeed meets the specified ordered_unique_range. </p> <p> std::is_sorted has complexity Linear in N, so with this change these constructors would keep their current complexity (which is also Linear in N) even when NDEBUG is not #defined. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/12117 Trac 1.4.3 Ion Gaztañaga Mon, 15 Aug 2016 21:25:12 GMT https://svn.boost.org/trac10/ticket/12117#comment:1 https://svn.boost.org/trac10/ticket/12117#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> Thanks for the proposal. The check was easy to implement in constructors. In insert() it's really tricky as the input iterator's value_type needs to only be <a class="missing wiki">EmplaceConstructible</a> and values are inserted quite differently, so insert() functions are left intact. Checks for constructors added in commit: </p> <p> <a class="ext-link" href="https://github.com/boostorg/container/commit/fb1be6fa75c965c24a03a658c4990137e547d492"><span class="icon">​</span>https://github.com/boostorg/container/commit/fb1be6fa75c965c24a03a658c4990137e547d492</a> </p> Ticket