I agree with your conclusion. 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.
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. John. > On Jan 11, 2019, at 10:31 AM, Jonathan Wakely <[email protected]> wrote: > > A colleague queried the absence of a feature-test macro for > https://wg21.link/p0458 "Checking for Existence of an Element in > Associative Containers". > > I couldn't find any record of discussion in LWG review or on this > mailing list to indicate whether the omission was intentional or an > oversight. > > IMHO there's not much need for a macro, based on the "if you have to > write the alternative code anyway, you might as well just do that" > principle. i.e. the macro allows you to write: > > #if __cpp_lib_assoc_contains > if (cont.contains(key)) > #else > if (cont.find(key) != cont.end()) > #endif > { > // ... > } > > But the performance characteristics of the two forms are identical, so > checking the macro just obfuscates the code. If you need to support > old compilers, just write the code the old way. > > The new contains member is more efficient than a badly-written check > for multimaps and multisets that uses "count": > > #if __cpp_lib_assoc_contains > if (cont.contains(key)) > #else > if (cont.count(key) != 0) > #endif > { > // ... > } > > But this code should be fixed anyway. > > Does SG10 agree that we don't need a macro for p0458? > _______________________________________________ > Features mailing list > [email protected] > http://www.open-std.org/mailman/listinfo/features _______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
