On Mon, Mar 6, 2017 at 10:21 AM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > Option 1 isn't practically possible, and the intention had been not to > do option 2. <cstdlib> adding things to the global namespace is icky, > but I suppose the C library already does that, and arguably > consistently icky would be better than inconsistently icky. Yes, I guess that's my point. > But I don't see why this should be restricted to abs. If you include > <cmath> and then call ::sin with a long double you get the > ::sin(double) overload, which loses precision. Unless we say that > *every* overloaded function in <cstdlib> and <cmath> always gets > dumped into the global namespace this problem still exists. Including > the right headers for what you use really is the best solution. If you > always use the <cxxx> header and qualify names with std:: then the > problem doesn't exist. Yes, the same logic would apply to all of them. I agree that the best solution is to include what you use - but in the wild, on large projects that use various libraries, it seems easy to overlook this unless you have tools enforcing it. (I am of course saying that partly to make myself feel better after I overlooked it...) I don't think it's such a bad idea to put all the overloads into the global namespace personally - given that *most* of them are there it is unfortunately a common assumption that *all* of them are there. Alternatively, I wonder if gcc could warn for this? Presumably the compiler will be aware that I am calling a function that was "indirectly" declared in a C-library header, and therefore outside the realm of standard-controlled behaviour? I don't know how hard that would be to achieve, just wonder if it's a possibility. Dave