Some library in C++ doesn't use namespace like stl does. Like ncurses, functions available there can be called without namespace. It has move () function that can be accessed globally. And now, I'm taking ncurses library in my class file which will have move function as it's member function. If i write my class like this:
#include <ncurses.h>
class MyClass {
public:
void move (int x, int y) {
// moving
}
void do_something (int x, int y) {
move (x, y);
// do something
}
}
I don't know which move () function will be called by MyClass. I think the problem will gone if can give ncurses library a namespace, so can use (for example) ncurses::move () not just move (). Is it possible to give it namespace? If not, what will you do if you find to something like this (not changing function name of course)?
In this case, you can fully qualify the call, rather than relying on name lookup which basically finds the "nearest" match, like this:
::move(x, y);
This will look for move at the top level, finding the ncurses, no-namespace, version.
For adding an ncurses namespace, not really. You could try:
namespace ncurses {
#include <ncurses.h>
}
but it's really nasty and almost certainly won't work properly. Another way would be to create a wrapper header that manually adds all the functions you are interested in into a namespace, like:
// wrapped_ncurses.h
#ifndef WRAPPED_NCURSES_H
#define WRAPPED_NCURSES_H
#include <ncurses.h>
namespace ncurses {
using ::move;
}
#endif
And then of course you can take this as far as you like towards creating a C++ wrapper for the entire library (or try to find an existing one).
I don't know which move () function will be called by MyClass.
The member function, since that's in the narrower scope. Unqualified name lookup starts in the local scope and works outwards until it finds a match. So here it will look in the function's block scope; then move out to the class; then find MyClass::move and stop there. It won't consider the global namespace outside the class.
Is it possible to give it namespace?
You can qualify the name as ::move to specify the global namespace.
Related
is there any way to put all to functions that are in a header file in a namespace, without change the header itself?
for example, if I have a header file called "funcs.h" which has some functions inside, is there any way to put all the functions inside in a namespace without changing "funcs.h"?
Thank you!
My first idea was some dirty hacks, but there is no reason to use a hack.
Suppose you have a function defined in global scope (actually I use an overload set for the example, and whether this is inside a header or not is not relevant):
void foo() {}
void foo(int) {}
You can make it accessible from within a namespace via using:
namespace ns {
using ::foo;
}
int main() {
ns::foo();
ns::foo(1);
}
Just be aware that you now have ns::foo and ::foo both refering to the same function (set of overloads, resp.).
when I was studying a book on C++, I came across this.
if we declare a class,
class student {public:
void func(int v1,int v2)
{
//some code
}
//some members.
};
and use a function with same name out of the class (non-member function) like,
void func(int x,inty)
and If I wish to call this non-member function in the member function of the above declared class, the syntax would be,
//inside the member function...
::func(x,y);
}
correct me if I am wrong.otherwise,
assuming I wrote
using namespace std;
in the beginning of the program, Is the below code equivalent to previous one?
//inside the member function
std::func(x,y);
}
and, does the answer change if I use a different namespace other than std?? ie,
provided I use,
using namespace abc
are the following declarations
abc::func(x,y)
and,
::func(x,y)
absolutely equivalent under any conditions or do they change under specific conditions??
Thank you.
in the beginning of the program, Is the below code equivalent to previous one?
//inside the member function
std::func(x,y);
No it isn't. Because you preform a qualified name lookup. It means you specify exactly in what namespace func is to be defined. std::func, if it exists, still belongs the the std namespace, not the global one.
A using namespace directive only makes identifiers available to unqualified name lookup, where it's up to the compiler to figure it out. This point is quite intricate, I know, but it's the reason namespaces can be considered useful.
The problem kicks in when you collide the names.
Do not do using namespace std;, since it can cause collision problem.
These code are identical:
using namespace std;
sort(params...); // Omitted, this will call std::sort
std::sort(params...);
And even if you are using namespace std, std::sort calls the same functions as long as std::std doesn't exist (and defining it from user side is illegal code).
However, abc::func() is not identical to ::func(). :: in the beginning means root namespace, which is the most outside namespace. There's no ambiguity or implicit filling in this case.
The using namespace directive allows your code to use stuff that is in the specified namespace. You can even have several of them:
using namespace x;
using namespace y;
This means that a function call like func() will call the function whose code resides either in x or in y namespace (or, in fact, in the global namespace).
If your code looks like this
using namespace x;
using namespace y;
void func(int, int) {... code ...}
then the func function goes in the global namespace, not in the x or y namespace. That is, ::func refers to this function, while x::func and y::func don't.
To put your code (class, function, etc) in a namespace, use this code:
namespace x
{
void func(int, int) {... code ...}
class student
{
void func(int, int) {... code ...}
};
}
Then, if you want to call the func that is outside your class, you can use x::func() or ::x::func(), but cannot use ::func().
I have a question regarding function declaration scopes in C++. Suppose using #include <cmath> introduces a function symbol into the global namespace. According to my understanding, in principle, it should only introduce symbols into the std namespace, but in practice, from my own experience, some symbols appear in the global namespace. This answer seems to confirm this: cmath header confusion.
Now, what happens when I declare a function (with the same prototype as the function from the global namespace) inside a namespace foo { }? Suppose for example, that sqrt() from <cmath> ends up in the global namespace, and I have:
#include <cmath>
namespace foo {
template <class T>
T sqrt( T x ) {
// do something extra...
return std::sqrt( x );
}
}
// ...
void foo::bar() {
double a = 4.0;
double b = sqrt( a );
}
The template is resolved to the symbol double sqrt( double x ), which seems like it should clash with the one in the global namespace. It seems to work, but is this generally a bad practice?
More generally, does a function declared inside a namespace take precedence over a global function, when used from inside the same namespace? Does this violate the C++ standard in any way?
There are two separate issues here.
Firstly, it is true that pulling in certain headers injects symbols both in the global namespace, and in the std namespace. This sausage-making has to do with C++'s legacy, and roots, in C; and to try to have a good chance of getting legacy C code compilable in C++ with as little pain as possible.
Secondly, is is true that...
a function declared inside a namespace take precedence over a global
function, when used from inside the same namespace?
That is correct. And, no, this does not
violate the C++ standard in any way?
In fact, the C++ standard explicitly specifies that this is how things should work. Resolving a reference from a namespace first searches the same namespace, as the first order of business. Then the parent namespace, in case of a nested namespace. Then, eventually, the global namespace.
Then, using namespace makes things complicated. Which is why you should not do that.
And then finally, to make things interesting, there's also argument dependent lookup that turns all these rules on their heads by searching for a function not in the current namespace, the parent namespace, or a global namespace, but in the same namespace as the functions' arguments.
Nobody has ever accused C++ of being simple.
Basically the above question. Like are classes like i_stream and everything else included inside the std namespace? Are the istream objects located INSIDE the class istream? Also why is there a namespace if there arent any naming collisions bound to happen?
Regarding the question in the title,
“ Is every class, object, and function in c++ standard library declared under namespace std?
no.
For example, the global operator new allocation function is in the global namespace only.
Almost.
Here's what my draft of the C++11 standard has to say about it [17.6.1.1, contents]:
All library entities except macros, operator new and operator delete
are defined within the namespace std or namespaces nested within
namespace std.
So operator new and operator delete are excluded, even though they are functions.
And there's a footnote there, saying:
The C standard library headers [...] also define names within
the global namespace, while the C++ headers for C library facilities
[...] may also define names within the global namespace.
This means that you still have all the old (now deprecated) C headers like <string.h> and <stddef.h>. Those headers place functions at the global namespace, e.g. printf, strcpy or strlen, just to name a few.
If you use the C++ equivalents of those headers, i.e. <cstring>, <cstddef> and so on, then you get those functions in the std namespace, so they become std::printf, std::strcpy, std::strlen and so on. But you may also get them in the global namespace.
The following is therefore allowed to compile, and probably will when you try it with your favourite compiler:
#include <cstdio>
int main()
{
printf("Test\n");
std::printf("Test\n");
}
Whereas the following won't:
#include <stdio.h>
int main()
{
printf("Test\n");
std::printf("Test\n"); // error
}
Regarding your related question:
Also why is there a namespace if there arent any naming collisions bound to happen?
Use your imagination:
Date CreateFromString(std::string const &string);
class OptionsFile
{
std::map<std::string, std::string> list;
// ...
};
class Buffer
{
int count;
// ...
};
Texture::Texture(char const *array);
enum Actions { find, sort };
struct Entity
{
std::string copy;
};
A coworker routinely writes something like this:
::someObject->someMethod(anAttribute, anotherAttribute);
someObject is a global variable.
Those two colons seem strange to me. The code compiles and runs just fine without them.
The coworker claims that those colons make someObject explicitly global and thus prevent confusion with a possible local someObject. I would think that you would not be able to define someObject locally if it was already defined globally?
Could you shed some light on what those colons mean and whether they are necessary?
Your coworker is right. You can indeed define a local someObject which would hide the global someObject within that scope:
SomeClass* someObject = ...;
// here the global object is visible
someObject->someMethod(anAttribute, anotherAttribute); // calls the global object
void someMethod() {
SomeClass* someObject = ...;
// here the local object hides the global
::someObject->someMethod(anAttribute, anotherAttribute); // calls the global object
someObject->someMethod(anAttribute, anotherAttribute); // calls the local object
}
// here again only the global object is visible
someObject->someMethod(anAttribute, anotherAttribute); // calls the global object
Scopes can be embedded within other scopes recursively, thus you may have a namespace within global scope, a class within a namespace, an inner class within the class, a method within an inner class, a block within the method... etc. And you may have variables/classes/methods/... of identical names in any of these scopes. So identifying what entity a specific name is referring to is not a trivial task in C++. It is known as name lookup.
In brief, whenever the compiler finds a name, it looks up that name starting from the innermost scope. I.e. inside someMethod, the name someObject is matched by the object defined locally. ::someObject overrides this default behaviour and makes the compiler search only within the outermost (global) scope, thus it finds the global object instead ofthe local.
You can indeed define a someObject locally even though there is a global one. The two variables have different scope, so the compiler knows there's a difference between the two, and the double colons let you refer to the global one.
This also applies to classes outside of a namespace; i.e., to refer to a class Foo from the class Bar::Foo, you use ::Foo to tell the compiler you are talking about the one that isn't in a namespace.
Here's an example that shows it working:
#include<stdio.h>
int someInt = 4;
int main() {
int someInt = 5;
printf("%d", someInt+::someInt);
return 0;
}
If you compile and run that piece of code, it will output 9.
The coworker claims that those colons
make someObject explicitly global and
thus prevent confusion with a possible
local someObject.
Yes - it means the function can be, and must only be, matched in the global namespace. It makes it obvious you're dealing with a global, and would prevent accidental matching against something more local (beit function local, an object member, namespace member, in a namespace you're using, a Koenig lookup match etc.).
I would think that you would not be
able to define someObject locally if
it was already defined globally?
It would be a very bad idea to make it an error. Say a team of programmers decides they want to add a variable called "last_error" to their namespace: they shouldn't have to worry if existing functions in the namespace use the same name for a local variable. If you copy a function from one namespace or class to another, you shouldn't have to make error-prone identifier substitutions in the implementation.
Regarding the benefits of ::, consider:
namespace X
{
void fn() {
rip(data, bytes); // MP3 rip this data
}
}
...then fn() needs to be moved quickly into namespace Y...
namespace Y
{
void rip(const char* message, int exit_code); /* for fatal errors */
...
}
...a casual copy-paste into the guts of Y could easily overlook that log won't match the same global function it used to when fn was in namespace X, but - as illustrated - the functionality may differ markedly :-).
You can think of each namespace, class/struct and functions forming a tree, where each level must be uniquely keyed (i.e. no same-named classes in the same namespace), but decendents are always independent of each other and their ancestors. Increasing freedom to vary independently is essential for letting many people work simultaneously on a big problem.
Could you shed some light on what
those colons mean and whether they are
necessary?
In this specific usage, the :: probably isn't strictly necessary. It adds a little protection, but makes it harder to move the variable to a more local scope later - though that's not so important because the compiler will tell you about the places that continue to refer to ::x after x is moved.
Just a minor add on to all other nice points which have come in the response.
Basically :: invokes qualified name lookup in the global namespace. However it is not guaranteed to be problem free especially in the face of indiscriminate using directives.
The code shown illustrates an important property of qualified name lookup. The point here is that namespaces nominated by using directives in the global namspace are searched. However using directives in namespaces that have the name being searched are skipped.
namespace Z{
void f(){cout << 1;}
}
namespace Y{
void f(){cout << 2;}
using namespace Y; // This namespace is not searched since 'f' is found in 'Y'
}
#if 0
namespace Z{
void f(){cout << 3;}
using namespace Y; // This namespace is not searched since 'f' is found in 'Y'
}
using namespace Z;
#endif
using namespace Y;
int main(){
::f(); // Prints 2. There is no ambiguity
}
In the code shown, if lines with the #if directive are enabled, there is an ambiguity in resolving the name 'f'.