Is there a way to include global functions (say from a library where I'm not allowed to modify the code) in to a namespace's scope and still be able to use it?
I have two functions:
base64_decode()
base64_encode()
in two files: Base64.cpp Base64.h.
(Obviously) when including Base64.h in to my Extensions namespace, the function declarations are available, but the linker can't find the definitions (in Base64.cpp) because they're now included in my namespace. Example:
namespace Extensions {
#include "Base64.h"
}
Is there a way to have both the implementation and the declaration of the two functions inside the namespace without modifying the original code and without #includeing Base64.cpp?
One common way:
#include "Base64.h"
namespace Extensions {
using ::base64_decode;
using ::base64_encode;
}
static_assert(sizeof(&Extensions::base64_decode) > 0, "");
static_assert(sizeof(&Extensions::base64_encode) > 0, "");
If you just want to get the functions into the namespace, then Maxim Egorushkin's excellent answer is the way to go.
Sometimes however, you need to get the function out of the global namespace (because it conflicts with another function of the same name). In that case you are going to have to use
namespace Extensions {
#include "Base64.h"
}
and then use platform specific hacks to rename the symbols in the library so that the linker can find them. See this answer for Linux.
It looks like all the options to rename symbols on Windows apply to DLLs. You will have to work out what the name-mangling is.
Related
The Linux <ncurses.h> header defines the function meta, and the C++ metaprogramming library meta puts all its code in the global namespace meta.
How can I use both in the same C++ program (not necessarily the same TU but that would be nice)? Is there a way to work around the name collision?
I can think of two brittle workarounds, but they are easy to break:
Workaround A:
namespace linux {
#include <ncurses.h>
} // namespace linux
using linux::max_align_t; // ncurses assumes it is in the global namespace
#include <meta/meta.hpp>
compiles but will probably fail to link since the ncurses symbols are expected in the global namespace.
Workaround B:
#include <ncurses.h>
namespace cpp {
#include <meta/meta.hpp>
} // namespace cpp
is very brittle since it will only work as long as the meta library doesn't assume that any of its symbols are in the global namespace. That is, if the library needs to disambiguate internally a symbol and uses ::meta::symbol_name for that, this approach will break.
I would suggest workaround C: Isolate your code such that the meta library use and the ncurses use are in separate translation units in your project. This way in any particular translation unit there isn't one symbol being used as both a namespace and a global function.
I'm reasonably certain that neither A nor B will actually work, at least as given. You've pointed toward one of them, but I think it's the less likely of the two. There are two problems that are basically mirror images of each other.
If the code in ncurses is declared as extern "C" (typical for many C libraries that have been made to work with C++), surrounding them with a namespace won't actually work--an extern "C" declaration basically ignores namespaces and declares a function in the global namespace. The namespace won't change much of anything, and you'll still have a collision.
If the content of <ncurses.h> is not declared extern "C", then you'll run into the problem you cited: the library is built with functions in the global namespace, but the client code is seeing definitions for code in the linux namespace. Since the namespace affects the mangled name (that's how it prevents a collision) your code won't be able to link. All the linux::* functions will show up as unresolved externals.
To make this work, you need to assure that none of the library code is declared extern "C", and specify the namespace inside the header (and the library source files), and re-compile the library with these declarations, so the library and its client code agree on the namespace where that code resides.
I am using only header files specific to C++ (e.g. <cstdlib>), however I still get globally-declared functions, and not just functions in the std namespace. Is there a way, perhaps a compiler switch, to prevent that?
For example, the following code:
#include <cstdlib>
float random() { return 0.0f; }
int main() { return 0; }
Fails to compile under linux, with the following error:
> g++ -c main.cpp main.o
main.cpp: In function ‘float random()’:
main.cpp:2:14: error: new declaration ‘float random()’
/usr/include/stdlib.h:327:17: error: ambiguates old declaration ‘long int random()’
or
> clang++ main.cpp -o main.o
main.cpp:2:7: error: functions that differ only in their return type cannot be overloaded
float random() { return 0.0f; }
/usr/include/stdlib.h:327:17: note: previous declaration is here
extern long int random (void) __THROW;
which is caused that stdlib.h "pollutes" the global namespace with its own random function.
Note, that I am not facing these problems when compiling on Windows, using Visual Studio.
<cstdlib> will always populate std namespace, and sometimes define global symbols, while <stdlib.h> will always define global symbols, and sometimes populate std namespace. This varies from implementation to implementation.
The standard writes:
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).
Which means, that the compiler is allowed to put those symbols into global scope and std namespace at the same time.
Therefore, we see no advantages to prefer one header file over the other. Because they are both very likely to pollute the global scope.
However, it is still necessary to use std namespace when #include <cstdlib>, and do not use std when #include <stdlib.h>, to make sure your code can compile for all compiler implementations.
Advice: Do not use names in standard libraries. First, they are not guaranteed to work. (Note: Few compiler implementations actually keep the global scope clean when you #include <csomething>, so never depend on this.) Second, it will confuse code readers and maintainers, because almost everyone will assume standard names are actually standard, no matter where they come from.
You can declare your functions in their own namespaces to prevent declaration collision.
namespace MyFunc
{
float random() { return 0.0f; }
};
In general you should try to avoid redeclaring in the first place.
You can do this by either using namespaces or by splitting up your source into files which can include cstdlib and others which can use a static version of your (name clashing) function.
If this is not an options then go on reading. But be aware that the following might be very platform specific.
By just having a look at my cstdlib and stdlib.h here at my place I noticed that there is a switch by which cstdlib decides if it includes stdlib.h or just declares abort, atext and exit in the std namespace.
Obviously you pull in the stdlib.h branch. Looking further into this file I noticed the macro __BEGIN_NAMESPACE_STD and later on __END_NAMESPACE_STD. Maybe you could use this, but it is (as the name suggests) some implementation internal macro and should not be set directly by you. However, it should be there for some reason so you might have luck with searching for it.
After some more search it turned out that random is one of several functions (and declarations) which are not wrapped into __BEGIN_NAMESPACE_STD. Therefore, this is not a solution to the problem. (I found another macro _GLIBCPP_USE_NAMESPACES which seems to be used internally as well to #define __BEGIN_NAMESPACE_STD namespace std {).
So to sum it up: This is no viable path and you should use one of the described workarounds.
The standard explicitly permits <c???> headers to bring names of C standard functions to the global namespace.
usually I would prefer to keep your function names different from what is defined as a standard .
For ex here one could use function name as myRandom instead of random so that I can inform the people , who would be maintaining my code later on , that the function being used is NOT the one defined as a standard.
BRIEF: is it ever safe to do
namespace Foo {
#include "bar"
}
Before you blithely say no, I think I have some rules that allow it fairly safely.
But I don't like them, since they require the includer to separately include all global scope headers needed. Although this mightr be tolerable, if we imagine including within a namespace to be just a special management feature.
And overall, externs and forward declarations just don't work well from within namespaces.
So I gues I am asking
a) What other gotchas
b) is there a better way
== A [[Header-only library]] ==
I like writing libraries. [[Header-only libraries and linker libraries]].
E.g.
#include "Valid.hpp"
defines a template Valid, for a simple wrapper type.
(Don't get bogged down in "You should use some standard library for this rather than your own. This is an exanple. I dunno if Boost or C++ have yet standardized this. I have been using wrappers since templates were added to C++.)
Also, let us say, it is a header only library, that defines, in Valid.hpp,
a print function
std::string to_string( const Valid& v ) {
std::ostringstream oss;
if( v.valid() ) { oss << v; }
else { "invalid"; }
return oss.str();
}
And because I think it is the right thing to do,
I have Valid.hpp include the headers it depends on:
Valid.hpp:
#include <iostream>
#include <sstream>
template<typename T>
class Valid {
private:
T value_;
bool valid_
...
};
...
std::string to_string( const Valid<T>& v ) { ...
So far, so good.
I can use Valid straightforwardly.
== Name collision - trying to use include within namespace to work around ==
But sometimes there is a collision.
Sometimes somebody else has their own Valid.
Namespaces to the rescue, right? But I don't want to change all of my existing code to use the namespace.
So, I am tempted, in a new project that has a collision, to do
namespace AG {
namespace Wrapper {
#include "lib/AG/Wrapper/Valid.hpp"
}
}
AG::Wrapper::Valid<T> foo_v;
...
PROBLEM: the headers included are no longer freestanding. Everything defined inside is no placed inside
namespace AG::Wrapper.
It's not hard to "fix".
Al we "must" do is include all the top level libraries that Valid.hpp depends on.
If they have include guards, they will not be re-included.
#include <iostream>
#include <sstream>
namespace AG {
namespace Wrapper {
#include "lib/AG/Wrapper/Valid.hpp"
}
}
AG::Wrapper::Valid<T> foo_v;
...
But it is no longer freestanding. :-(
Worse, sometimes the header-only library contains extern declarations and forward declarations of stuff outside itself.
These declarations get placed inside the namespace too.
In particular, if the extern declarayion is inside a function defined in the namespace.
I.e. sometimes we use extern and forward declarations, rather than included an entire header file.
These get included in the namespace.
Q: is there a better way?
== :: doesn't do it ==
Hint: :: doesn't do it. At least not all the time, not in gcc 4.7.2.
(Gcc's behavior in this has changed over time. Gcc 4.1.2 behaved differently.)
E.g.
Type var;
namespace Foo {
void bar() {
extern ::Type ::var;;
extern ::Type ::Foo::bar;
extern ::Type::foo ::bar; // see the ambiguity?
};
But it's not just the ambiguity.
int var;
namespace Foo {
void bar() {
extern int var;
};
works - Foo::bar'svar is equal to ::var.
But it only works because of the declaration outside the namespace.
The following doesn't work
header
int var;
cpp
namespace Foo {
void bar() {
extern int var;
}
}
although the following does:
header
int var;
cpp
void bar() {
extern int var;
}
}
Basically, what this amounts to saying is that
it is not a trivial refactoring to put functions inside a namespace.
Wrapping a namespace around a chunk of code,
whether or not it is #include'd,
is not a sufficient.
... at least not if there are extern or forward declarations.
And even if you
== Opinion against putting includes within namespaces ==
Stackoverflow folks seem to be against putting #includes inside namespaces:
E.g. How to use class defined in a separate header within a namespace:
... you should never write a #include inside a namespace. Where "never" means, "unless you're doing something really obscure that I haven't thought of and that justifies it". You want to be able to look at a file, and see what the fully-qualified names are of all the things in it. You can't do that if someone comes along later and sticks an extra namespace on the front by including from inside their namespace. – Steve Jessop Jan 6 '12 at 16:38
Overall question:
Is there any way, from deep within a namespace,
to say "and now here are some names that I am depending on from the outside world, not within the namespace."?
I.e. I would like to be able to say
namespace A {
void foo() {
// --- here is a reference to gloal scope extreren ...
I know this is an old question, but I want to give a more detailed answer anyway. Also, give a real answer to the underlying problem.
Here's just a few things that can go wrong if you include a header from within a namespace.
The header includes other headers, which are then also included from within the namespace. Then a different place also wants to include these headers, but from outside the namespace. Because the headers have include guards, only one of the includes actually goes in effect, and the actual namespace of the stuff defined in the headers suddenly subtly depends on the order you include other headers.
The header, or any of its included headers, expects to be in the global namespace. For example, standard library headers will very often (in order to avoid conflicts) refer to other standard stuff (or implementation details) as ::std::other_stuff, i.e. expect std to be directly in the global namespace. If you include the header from within a namespace, that's no longer the case. The name lookup for this stuff will fail and the header will no longer compile. And it's not just standard headers; I'm sure there are some instances of this e.g. in the Boost headers too.
If you take care of the first problem by ensuring that all other headers are included first, and the second problem by making sure no fully qualified names are used, things can still go wrong. Some libraries require that other libraries specialize their stuff. For example, a library might want to specialize std::swap, std::hash or std::less for its own type. (You can overload std::swap instead, but you can't do that for std::hash and std::less.) The way to do this is close your library-specific namespace, open namespace std, and put the specialization there. Except if the header of the library is included in arbitrarily deeply nested namespaces, it cannot close those namespaces. The namespace std it attempts to open won't be ::std, but ::YourStuff::std, which probably doesn't contain any primary template to specialize, and even if it did, that would still be the wrong thing to do.
Finally, things in a namespace simply have different names than things outside. If your library isn't header-only but has a compiled part, the compiled part probably didn't nest everything in the namespace, so the stuff in the library has different names than the stuff you just included. In other words, your program will fail to link.
So in theory, you can design headers that work when included within a namespace, but they're annoying to use (have to bubble up all dependencies to the includer) and very restricted (can't use fully qualified names or specialize stuff in another library's namespace, must be header-only). So don't do it.
But you have an old library that doesn't use namespaces, and you want to update it to use them without breaking all your old code. Here's what you should do:
First, you add a subdirectory to your library's include directory. Call it "namespaced" or something like that. Next, move all the headers into that directory and wrap their contents in a namespace.
Then you add forwarding headers to the base directory. For each file in the library, you add a forwarder that looks like this:
#ifndef YOURLIB_LEGACY_THE_HEADER_H
#define YOURLIB_LEGACY_THE_HEADER_H
#include "namespaced/the_header.h"
using namespace yourlib;
#endif
Now the old code should just work the way it always did.
For new code, the trick is not to include "namespaced/the_header.h", but instead change the project settings so that the include directory points at the namespaced subdirectory instead of the library root. Then you can simply include "the_header.h" and get the namespaced version.
I don't think it's safe. You put all your includes into the namespace Foo...
Imagine some of your includes include something from the std namespace... I cannot imagine the mess !
I wouldn't do that.
Header files are not black boxes. You can always look at a header you're including in your project and see if it is safe to include it inside a namespace block. Or better yet, you can modify the header itself to add the namespace block. Even if the header is from a third-party library and changes in a subsequent release, the header you have in your project won't change.
i would like to use only certain functions from math.h (WITHOUT including the entire library)
for example, i need to use "sqrt" and "exp", but i have variables named "y1" (and possibly others) which conflict with definitions in math.h
how can i use only certain functions from a library like that?
i tried
#define sqrt cmath::sqrt
but that did not work, i have seen something like that before with
#define cout std::cout
i think, so i thought it might work.
any ideas?
Put your code in your own namespace. By using namespace operator (::) you can distinguish variables with the same name (and which are in the same scope).
Just use them?
#include <cmath>
int main()
{
double d = 4.0;
sqrt(d);
exp(d);
}
You can also explicitly specify the namespace:
#include <cmath>
int main()
{
double d = 4.0;
std::sqrt(d);
std::exp(d);
}
You can, if you want, bring in specific names from namespaces without bringing in the whole namespace. This is done using the using keyword. Please don't create a #define for this:
#include <string>
using std::string;
int main()
{
string s = "foo";
}
Yes, you can just use the parts you want.
Simply create your own partial mini_cmath.h header for those functions / globals you need access to (assuming those don't conflict!).
As several have noted, there's no way to only #include a given chunk (unless the included header has preprocessor macros to enable such a thing, such as windows.h)
But if you simply declare those functions you wish to use (correctly), and then compile & link (as long as the necessary .lib is included in your link), then you're golden.
However, on a more general note - globals are a bad idea in general, but if you absolutely must use them for hopefully valid reasons, then you should be putting them in a namespace, and referencing them in your source by fully qualified name:
namespace AcmeCorp {
int g_fubar;
}
AcmeCorp::g_fubar = 9;
Just #include <cmath>. If your variable names are such an issue, then rename them. You can't include just a piece of a file.
EDIT: Why should a y1 conflict with anything in math.h? Use your own namespace. You'll still be able to use sqrt and you can access stuff from your namespace by resolving through mynamespace::y1.
Anyway,
cmath is an alias of the header file math.h.
std is a namespace, which contains the cout object in iostream.h.
So while you can use std::cout, you can't do the same scope resolution with a header file. You just have to include math.h, or cmath.
And you don't need to use a #define for cout like that. Just add a using namespace std and you won't have to resolve the scope.
And using an entire namespace does not cause any overhead, if that's what you're concerned about. Cheers!
y1() is one of a number of POSIX extensions to the C math library. You can remove these extensions by undefining the following macros before including <cmath>:
#undef _SVID_SOURCE
#undef _BSD_SOURCE
#undef _XOPEN_SOURCE
It's also a very good idea in general to avoid putting any of your own names in the global namespace, since there's a good chance of a collision if you use any C libraries. Avoid global variables whenever you can and, if you must use one, put it inside your own namespace.
The following code will cause compile errors in g++4.4:
// File test.cpp
namespace A
{
#include <iostream>
}
int main()
{
return 0;
}
I have this requirement because some third party library comes without namespace protected, and if I directly include these headers, my namespace is polluted.
As a result, I tried to create namespaces for those libraries, but if the library includes some "std headers" the above approach will fail.
Can anybody help?
Thank You!
I believe 17.4.2.1 [lib.using.headers] forbids including standard library headers in a namespace :
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 to any of the entities it declares or first defines in that
translation unit.
I don't think there is anything you can do besides filing a request to the library author.
This approach will most likely lead you to trouble. You could approach the problem by manually including each such standard header before entering the namespace, and the include guards would take care of not re-including the header inside the namespace.
That would take care of your current error, but it would on the other hand break too many other things --if the library is precompiled then the symbols used in your code and the symbols in the binary library would be different symbols (libname::foo() used in your code, ::foo() defined in the binary). Even if the library is header only, any fully qualified access to the library within the library itself would break (void foo() { ::bar(); } where foo and bar are inside the library).
A valid approach that you might want to try (even if cumbersome, and requiring real work) would be writting a wrapper that is within it's own namespace, and uses the library. Then include your wrapper instead of the actual library headers.
My advice, on the other hand, would be ignoring the problem altogether. Declare your own objects within your namespaces and that would take care of the possible name collisions. As long as you keep away from using namespace statements you will be fine.
Use fully qualified names when using calls to standard libraries like std::cout instead of writing using namespace std;. This way, both can coexist.