29

I am developing a project which works with multiple arithmetic types. So I made a header, where the minimal requirements for a user defined arithmetic type are defined:

user_defined_arithmetic.h :

typedef double ArithmeticF;   // The user chooses what type he 
                              // wants to use to represent a real number

namespace arithmetic          // and defines the functions related to that type
{

const ArithmeticF sin(const ArithmeticF& x);
const ArithmeticF cos(const ArithmeticF& x);
const ArithmeticF tan(const ArithmeticF& x);
...
}

What is troubling me is that when I use code like this:

#include "user_defined_arithmetic.h"

void some_function()
{
    using namespace arithmetic;
    ArithmeticF lala(3);
    sin(lala);
}

I get a compiler error:

error: call of overloaded 'sin(ArithmeticF&)' is ambiguous
candidates are:
double sin(double)
const ArithmeticF arithmetic::sin(const ArithmeticF&)

I have never used the <math.h> header, only the <cmath>. I have never used the using namespace std in a header file.

I am using gcc 4.6.*. I checked what is the header containing the ambiguous declaration and it turns out to be:

mathcalls.h :

Prototype declarations for math functions; helper file for <math.h>.
...

I know, that <cmath> includes <math.h>, but it should shield the declarations by the std namespace. I dig into the <cmath> header and find:

cmath.h :

...

#include <math.h>

...

// Get rid of those macros defined in <math.h> in lieu of real functions.
#undef abs
#undef div
#undef acos
...

namespace std _GLIBCXX_VISIBILITY(default)
{
...

So the namespace std begins after the #include <math.h>. Is there something wrong here, or did I misunderstand something?

Martin Drozdik
  • 12,742
  • 22
  • 81
  • 146
  • 4
    Some things you might want to reconsider: when using arithmetic types (integral types + double + float) it is usually more efficient (and common) to pass by value than by reference. When calling a function for which you want an specific version, qualify the call, rather than adding a `using namespace X`. Alternatively you can use a *using directive* (`using arithmetic::sin`). Finally the whole approach of changing types by editing a `typedef` is a really bad idea. – David Rodríguez - dribeas Jun 18 '12 at 15:56
  • @DavidRodriguez-dribeas: Thank you! Please, could you hint me an alternative solution? I am using pass by reference, because the number can be a custom type. That means it can get even few kilobytes large. I was hoping that when I inline the functions and use the std elementary functions inside the inline, no harm will be done. Or will be? Could you give me some suggestion please? – Martin Drozdik Jun 18 '12 at 16:07
  • @DavidRodriguez-dribeas: I know that the C++ approach would be to declare an abstract class, but a library that I use for matrix computations uses significant optimizations when you use a built in type. I just did not want to lose this advantage – Martin Drozdik Jun 18 '12 at 16:16
  • 5
    Your implementation can be a template that just uses the features (whether a class or not is a different issue, free functions are fine if you ask me). Your *algorithm* will work with any *arithmetic* type, and user code can decide what type to use *locally* without having to modify a `typedef`. That is users, can know the type they are using without having to search in a header for the `typedef`. Additionally, you will be able to use multiple types in a single application. – David Rodríguez - dribeas Jun 18 '12 at 16:54
  • Thank you! I value your advice very much! – Martin Drozdik Jun 18 '12 at 17:12
  • 1
    Also see Jonathan Wakely's [Why < cstdlib > is more complicated than you might think](https://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think/) from the Red Hat blogs. Wakely is one of the GCC devs who maintains GNU's C++ standard library. He specifically discusses the math functions and the troubles they can cause. The short of it is, C++ has overloading, so there are three `abs`, three `log`, etc. The overloads are `int`, `double` and `long double` to suit your needs. But C only has one of each function. – jww Mar 08 '17 at 13:20

3 Answers3

26

Implementations of the C++ standard library are permitted to declare C library functions in the global namespace as well as in std. Some would call this a mistake, since (as you've found) the namespace pollution can cause conflicts with your own names. However, that's the way it is, so we must live with it. You'll just have to qualify your name as arithmetic::sin.

In the words of the standard (C++11 17.6.1.2/4):

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).

Mike Seymour
  • 249,747
  • 28
  • 448
  • 644
  • What's worse is that `std::exp` has overloads for float, double and integrals, while `exp` is only for doubles. Hence a `using namespace std;` declaration can change results! – dhardy May 01 '19 at 09:33
3

If you really wanted to, you could always write a little wrapper around cmath, along the lines of:

//stdmath.cpp
#include <cmath>
namespace stdmath
{
    double sin(double x)
    {
        return std::sin(x);
    }
}

//stdmath.hpp
#ifndef STDMATH_HPP
#define STDMATH_HPP
namespace stdmath {
    double sin(double);
}
#endif

//uses_stdmath.cpp
#include <iostream>
#include "stdmath.hpp"

double sin(double x)
{
    return 1.0;
}

int main()
{
    std::cout << stdmath::sin(1) << std::endl;
    std::cout << sin(1) << std::endl;
}

I suppose there could be some overhead from the additional function call, depending on how clever the compiler is.

James
  • 3,191
  • 1
  • 23
  • 39
  • This doesn't completely solve the problem, consider `namespace mylib{ double sin(double x) { return 1.0; } } int main() { using namespace mylib; std::cout << stdmath::sin(1) << std::endl; std::cout << sin(1) << std::endl; }` you still get an "ambiguous call error". – alfC Aug 13 '14 at 03:34
  • @alfC no you don't. The whole point of this answer is in inclusion of `` in the `cpp` file of `stdmath` instead of `hpp` header. – Ruslan Jul 15 '15 at 05:44
1

This is just a humble attempt to start solving this problem. (Suggestions are welcomed.)

I have been dealing with this problem a long time. A case were the problem is very obvious is this case:

#include<cmath>
#include<iostream>

namespace mylib{
    std::string exp(double x){return "mylib::exp";}
}

int main(){
    std::cout << std::exp(1.) << std::endl; // works
    std::cout << mylib::exp(1.) << std::endl; // works

    using namespace mylib;
    std::cout << exp(1.) << std::endl; //doesn't works!, "ambiguous" call
    return 0;
}

This is in my opinion is an annoying bug or at the least an very unfortunate situation. (At least in GCC, and clang --using GCC library-- in Linux.)

Lately I gave it another shot to the problem. By looking at the cmath (of GCC) it seems that the header is there simply to overload the C-functions and screws up the namespace in the process.

namespace std{
   #include<math.h>
}
//instead of #include<cmath>

With it this works

using namespace mylib;
std::cout << exp(1.) << std::endl; //now works.

I am almost sure that this is not exactly equivalent to #include<cmath> but most functions seem to work.

Worst of all is that eventually some dependence library will eventually will #inclulde<cmath>. For that I couldn't find a solution yet.

NOTE: Needless to say this doesn't work at all

namespace std{
   #include<cmath> // compile errors
}
alfC
  • 14,261
  • 4
  • 67
  • 118