Is it OK to put a standard, pure C header #include directive inside a namespace?

Question

Possible Duplicate:
Is it a good idea to wrap an #include in a namespace block?

I've got a project with a class log in the global namespace (::log).

So, naturally, after #include <cmath>, the compiler gives an error message each time I try to instantiate an object of my log class, because <cmath> pollutes the global namespace with lots of three-letter methods, one of them being the logarithm function log().

So there are three possible solutions, each having their unique ugly side-effects.

• Move the log class to it's own namespace and always access it with it's fully qualified name. I really want to avoid this because the logger should be as convenient as possible to use.
• Write a mathwrapper.cpp file which is the only file in the project that includes <cmath>, and makes all the required <cmath> functions available through wrappers in a namespace math. I don't want to use this approach because I have to write a wrapper for every single required math function, and it would add additional call penalty (cancelled out partially by the -flto compiler flag)
• The solution I'm currently considering:

Replace

#include <cmath>

by

namespace math {
#include "math.h"
}

and then calculating the logarithm function via math::log().

I have tried it out and it does, indeed, compile, link and run as expected. It does, however, have multiple downsides:

• It's (obviously) impossible to use <cmath>, because the <cmath> code accesses the functions by their fully qualified names, and it's deprecated to use in C++.
• I've got a really, really bad feeling about it, like I'm gonna get attacked and eaten alive by raptors.

So my question is:

• Is there any recommendation/convention/etc that forbid putting include directives in namespaces?

• Could anything go wrong with

  • diferent C standard library implementations (I use glibc),
  • different compilers (I use g++ 4.7, -std=c++11),
  • linking?
• Have you ever tried doing this?
• Are there any alternate ways to banish the math functions from the global namespace?

I've found several similar questions on stackoverflow, but most were about including other C++ headers, which obviously is a bad idea, and those that weren't made contradictory statements about linking behaviour for C libraries. Also, would it be beneficial to additionally put the #include <math.h> inside extern "C" {}?

edit

So I decided to do what probably everyone else is doing, and put all of my code in a project namespace, and to access the logger with it's fully qualified name when including <cmath>.

Answer 1

No, the solution that you are considering is not allowed. In practice what it means is that you are changing the meaning of the header file. You are changing all of its declarations to declare differently named functions.

These altered declarations won't match the actual names of the standard library functions so, at link time, none of the standard library functions will resolve calls to the functions declared by the altered declarations unless they happen to have been declared extern "C" which is allowed - but not recommended - for names which come from the C standard library.

ISO/IEC 14882:2011 17.6.2.2/3 [using.headers] applies to the C standard library headers as they are part of the C++ standard library:

A translation unit shall include a header only outside of any external declaration or definition[*], and shall include the header lexically before the first reference in that translation unit to any of the entities declared in that header.

[*] which would include a namespace definition.

Answer 2

Why not putting a log class in it's own namespace and using typedef namespace::log logger; to avoid name clashes in a more convenient way?

Answer 3

Change your class's name. Not that big of a deal. ;-)

Seriously though, it's not a great idea to put names in the global namespace that collide with names from any standard header. C++03 didn't explicitly permit <cmath> to define ::log. But implementations were chronically non-conforming about that due to the practicalities of defining <cmath> on top of an existing <math.h> (and perhaps also an existing static-link library for some headers, including math). So C++11 ratifies existing practice, and allows <cmath> to dump everything into the global namespace. C++11 also reserves all those names for use with extern "C" linkage, and all function signatures for use with C++ linkage, even if you don't include the header. But more on that later.

Because in C++ any standard header is allowed to define the names from any other standard header (i.e, they're allowed to include each other), this means that any standard header at all can define ::log. So don't use it.

The answer to your question about different implementations is that even if your scheme works to begin with (which isn't guaranteed), in some other implementation there might be a header that you use (or want to use in future in the same TU as your log class), that includes <cmath>, and that you didn't give the namespace math treatment to. Off the top of my head, <random> seems to me a candidate. It provides a whole bunch of continuous random number distributions that plausibly could be implemented inline with math functions.

I suggest Log, but then I like capitalized class names. Partly because they're always distinct from standard types and functions.

Another possibility is to define your class as before and use struct log in place of log. This doesn't clash with the function, for reasons that only become clear if you spend way too much time with the C and C++ standards (you only use log as a class name, not as a function and not as a name with "C" linkage, so you don't infringe on the reserved name. Despite all appearances to the contrary, class names in C++ still inhabit a parallel universe from other names, rather like struct tags do in C).

Unfortunately struct log isn't a simple-type-identifier, so for example you can't create a temporary with struct log(VERY_VERBOSE, TO_FILE). To define a simple-type-identifier:

typedef struct log Log;
Log(VERY_VERBOSE, TO_FILE); // unused temporary object

An example of what I say in a comment below, based on a stated example usage. I think this is valid, but I'm not certain:

#include <iostream>
#include <cmath>
using std::log; // to enforce roughly what the compiler does anyway

enum Foo {
    foo, bar
};

std::ostream &log(Foo f) { return std::cout; }

int main() {
    log(foo) << log(10) << "\n";
}

Answer 4

It is ugly hack too, but I believe will not cause any linker problems. Just redefine log name from <math.h>

 #define log math_log
 #include <math.h>
 #undef log

It could cause problems with inline functions from math using this log, but maybe you'd be lucky...

Math log() is still accessible but it's not easy. Within functions where you want to use it, just repeat its real declaration:

    int somefunc() {
        double log(double); // not sure if correct
        return log(1.1);
    }