Unknown error perhaps caused by naming conflict? - c++

Question

I wrote a very simple c++ code, where I defined a function called sqrt which just calls
std::sqrt. Unexpectedly, I got a segmentation fault. The problem doesn't exist if I rename
the function sqrt as something else. However, I can not see any naming conflict since
the sqrt function I defined is not in the namespace std so the two should be perfectly
separated. So what is the real cause of the problem? Thanks!
#include<iostream>
#include<cmath>
double sqrt(double d);
double sqrt(double d) {
return std::sqrt(d);
}
int main() {
double x = 3.0;
std::cout << "The square root of " << x << " is " << sqrt(x) << '\n';
return 0;
}

Answer 1

<cmath> is a funny header. It is allowed to (but not required to) make ::sqrt and
std::sqrt synonyms. If you include it, it's best to assume
that both are present (or just include <math.h>, in which
case, ::sqrt is all that you should get). What's probably
happening in your case is that 1) std::sqrt is in fact a
synonym (via using) for ::sqrt, and 2) the linker is picking
up your ::sqrt first, so you end up with endless recursion.
The only solution, short of changing the name, is to put your
sqrt in a namespace.
EDIT:
Just to be clear: the above is C++11. Earlier versions of C++ did not allow <cmath> to introduce anything into global namespace. All implementations did, however, so the standard was changed to bless the practice. (I guess that's one way of getting compilers to be standard compliant.)
EDIT:
Some additional information as to how a library "picks up"
symbols, in response to the question in comments. Formally,
according to the C++ standard, you may not have two definitions
of the same function (same name, namespace and argument types)
in a program. If the two definitions are in separate
translation units, the behavior is undefine. With this in mind,
there are several practical considerations.
The first can be considered the definition of a library (or at
least the traditional definition). A library is a set of
modules—translation units, in terms of the standard.
(Generally, but not always, the modules consist of compiled
object files.) Linking in a library, however, does not bring
in all of the modules in it; a module from a library is
incorporated into your program only if it resolves an unresolved
external. Thus, if ::sqrt is already defined (resolved)
before the linker looks at the library, the module containing
::sqrt in the library will not become part of your program.
In practice, the term library has been abused in recent years,
to the point where one might say that its meaning has changed.
In particular, what Microsoft calls "dynamically loaded
libraries" (and what were called "shared objects" in Unix, long
before), are not libraries in the traditional sense, and the
above doesn't apply to them. Other issues do, however,
depending on how the dynamic loader works. In the case of Unix,
if several shared objects have the same symbol, all will resolve
to the first one loaded (by default—this can be controlled
by options passed to dlopen). In the case of Windows, by
default, a symbol will be resolved within the DLL if possible;
in your case, if std::sqrt is an inline function, or is
specified as using ::sqrt, this will be the DLL which calls
std::sqrt; if in the header, it is __declspec(dllexport),
this will be the DLL that contains the implementation of
std::sqrt.
Finally, almost all linkers today support some form of weak
references. This is usually used for template instantiations:
something like std::vector<int>::vector( size_t, int ) will be
instantiated in every translation unit which uses it, but as
a "weak" symbol. The linker then chooses one (probably the
first it encounters, but it's not specified), and throws out all
of the others. While this technique is mainly used for template
instantiations, a compiler can define any function using weak
references (and will do so if the function is inline). In this
case, if the definitions are different (as in your case of
::sqrt), then we can truly say that the program is illegal,
since it violates the one definition rule. But the results are
undefined behavior, and don't require a diagnostic. It you
define an inline function or a function template differently in
two different translation units, for example, you will almost
never get an error; if the compiler doesn't actually inline
them, the linker will choose one, and use it in both translation
units. In your case (::sqrt), I doubt that this applies;
I would expect this to be a real library function, and not
inlined. (If it were inlined, the definition would be in the
header <cmath>, and you'd get a duplicate definition error,
since both definitions would be in the same translation unit.)

Answer 2

The problem seems to be that <cmath> is bringing in the sqrt name (without the std:: namespace), as well as std::sqrt. I am afraid you need to use another name.
See this example, using a snapshot of GCC 4.8:
#include<iostream>
#include<cmath>
int main() {
double x = 9.0;
std::cout << sqrt(x) << '\n'; // look, no std::sqrt
}

Answer 3

Per Paragraph 17.6.1.2/4:
Except as noted in Clauses 18 through 30 and Annex D, the contents of each header cname shall be the same
as that of the corresponding header name.h, as specified in the C standard library (1.2) or the C Unicode
TR, as appropriate, as if by inclusion. In the C++ standard library, however, the declarations (except for
names which are defined as macros in C) are within namespace scope (3.3.6) of the namespace std. It is
unspecified whether these names are first declared within the global namespace scope and are then injected
into namespace std by explicit using-declarations (7.3.3).
Also, per Annex D.5/2:
Every C header, each of which has a name of the form name.h, behaves as if each name placed in the standard
library namespace by the corresponding cname header is placed within the global namespace scope. It is
unspecified whether these names are first declared or defined within namespace scope (3.3.6) of the namespace
std and are then injected into the global namespace scope by explicit using-declarations (7.3.3).
Since the exact technique to be used for making global functions available is left up to implementations, your implementation is probably having a using directive such as the one below inside the std namespace:
namespace std
{
using ::sqrt;
// ...
}
Which means that std::sqrt actually becomes an alias for ::sqrt, and you are providing a definition of ::sqrt which effectively ends up calling itself recursively.
The only solution is then to pick a different name.