<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 14 Jan 2019 at 20:51, John Spicer &lt;<a href="mailto:jhs@edg.com">jhs@edg.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I agree with your conclusion.<br>
<br>
A question came up recently about whether nested inline namespaces (P1094R2) needed a feature test macro.   In the CWG discussion Alisdair said there was intentionally no feature test macro.<br>
<br>
It might be helpful for proposals to that do not have a feature test macro to say so explicitly so that we know whether it was by design or an oversight.<br>
<br></blockquote><div><br></div><div>It might also be useful to write up the &quot;if you have to write the alternative code anyway, you might as well just do that&quot; principle in SD-6, so we can point people to it.</div><div><br></div><div>Assign that task to me if you like, although I might not be able to get around to it for a while.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
John.<br>
<br>
&gt; On Jan 11, 2019, at 10:31 AM, Jonathan Wakely &lt;<a href="mailto:cxx@kayari.org" target="_blank">cxx@kayari.org</a>&gt; wrote:<br>
&gt; <br>
&gt; A colleague queried the absence of a feature-test macro for<br>
&gt; <a href="https://wg21.link/p0458" rel="noreferrer" target="_blank">https://wg21.link/p0458</a> &quot;Checking for Existence of an Element in<br>
&gt; Associative Containers&quot;.<br>
&gt; <br>
&gt; I couldn&#39;t find any record of discussion in LWG review or on this<br>
&gt; mailing list to indicate whether the omission was intentional or an<br>
&gt; oversight.<br>
&gt; <br>
&gt; IMHO there&#39;s not much need for a macro, based on the &quot;if you have to<br>
&gt; write the alternative code anyway, you might as well just do that&quot;<br>
&gt; principle. i.e. the macro allows you to write:<br>
&gt; <br>
&gt; #if __cpp_lib_assoc_contains<br>
&gt;  if (cont.contains(key))<br>
&gt; #else<br>
&gt;  if (cont.find(key) != cont.end())<br>
&gt; #endif<br>
&gt;  {<br>
&gt;    // ...<br>
&gt;  }<br>
&gt; <br>
&gt; But the performance characteristics of the two forms are identical, so<br>
&gt; checking the macro just obfuscates the code. If you need to support<br>
&gt; old compilers, just write the code the old way.<br>
&gt; <br>
&gt; The new contains member is more efficient than a badly-written check<br>
&gt; for multimaps and multisets that uses &quot;count&quot;:<br>
&gt; <br>
&gt; #if __cpp_lib_assoc_contains<br>
&gt;  if (cont.contains(key))<br>
&gt; #else<br>
&gt;  if (cont.count(key) != 0)<br>
&gt; #endif<br>
&gt;  {<br>
&gt;    // ...<br>
&gt;  }<br>
&gt; <br>
&gt; But this code should be fixed anyway.<br>
&gt; <br>
&gt; Does SG10 agree that we don&#39;t need a macro for p0458?<br>
&gt; _______________________________________________<br>
&gt; Features mailing list<br>
&gt; <a href="mailto:Features@isocpp.open-std.org" target="_blank">Features@isocpp.open-std.org</a><br>
&gt; <a href="http://www.open-std.org/mailman/listinfo/features" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/features</a><br>
<br>
</blockquote></div></div></div>