I declare a multmethod with defmulti but then I have defmethods scattered all around my code base and it seems to "just work" without having to declare any explicit namespace in front of the multimethod declaration! Is this because all multimethods use some form of global namespace?
You don't need to repeat the multimethod's namespace in front of the multimethod's name because you have already referred the multimethod's name in your namespace, probably via the use of :use in the namespace decl.
Related
I learned that in namespace "name decoration(mangling)" takes place so that it can be differentiated from other same identifiers which is in different namespace.
Wiki: Name mangling
If then, Why "namespace scope" exists? I thought just 'name decoration' can solve all problem about name conflicting.
Because in C, the reason for name conflicting is eventually that "different entities have same identifier".
Name decoration can make names(identifiers) different from each other internally, so I think name decoration is what all we need.
Then, why C++ use 'namespace scope' concept? Just for to use unqualified name in namespace scope? I want to know if there is any reason.
Namespaces scope is very useful in programming for the following reasons:
Avoids name collisions between functions/classes, eg., Suppose you have two functions of same name but in different namespace scope (foo::func() and bar::func())
Can be used for managing similar functions inside it, eg., sin(), cos() and sqrt() function could be under namespace Math.
Avoids confusion between classes for an example suppose there's two classes named lexer, but in different namespace scope like json::lexer and xml::lexer. Now, it gives clear understanding to the programmer to choose between them according to their language i.e, xml or json.
An everyday example of namespace could be std, stands for standard, it contains every single functions and classes defined in the standard library, it also includes STL classes like std::vector, std::map and std::string.
NOTE: There's no concept of namespace scope in C.
Namespace scope is a concept in the programming language that the developer sees, allowing them to organise their code effectively and understand it better. Name mangling is something the compiler does under the hood in order to implement namespaces (including namespace scope) in a way the linker can understand. In normal circumstances the developer doesn't need to think about name mangling, although its useful to know how it works.
This question already has answers here:
Namespace + functions versus static methods on a class
(9 answers)
Closed 3 years ago.
I've got a bunch of functions(func1(),func2(),...) in a header file to which I want to give some scope. I know of 2 implementations:
class bunchOfFunctions
{
public:
static void func1();
static void func2();
...
};
namespace bunchOfFunctions
{
void func1();
void func2();
...
};
In both the options, I can access the functions in the same way i.e. by bunchOfFunctions::func(). I prefer the namespace method(lesser typing), but I've seen the 1st method of implementation also at my workplace.
Which option is better? Is there any other option?
Apart from StroryTeller highlighted points,
Spread: A namespace can be spread into multiple files where as Class must be defined in a single place.
Readability and Understandability: Generally developers inherent understanding of what a Class is and what a namespace is.
"Better" depends on your definition for better. What qualities are you looking for in the scoping? There is no one size fits all answer here. But here are some properties of both approaches:
Necessity to qualify the function name.
With a class you must write bunchOfFunctions::func1() when
utilizing those functions. Meanwhile a namespace allows you to pull
a function in with a using declaration
using bunchOfFunctions::func1;
and use it unqualified in most scopes. If you wished you could even make all the members of the namespace available to unqualified name lookup with a using directive. Classes don't have an equivalent mechanic.
Aliasing.
There is no difference. To alias the class one writes
using BOF = bunchOfFunctions;
while aliasing the namespace is done with
namespace BOF = bunchOfFunctions;
Privacy.
A class can have private members. So you could put function declarations in there under a private access specifier and use them in public inline members. Namespaces have no such mechanism. Instead we rely on convention and put declarations under a "do not touch this" internal namespace, often called bunchOfFunctions::detail.
Argument dependent lookup.
C++ has a mechanism that allows it to find function declarations from an unqualified call, by examining the namespaces that contain the arguments to the call. For that to work, the function must be in an actual namespace. Static members of classes are not subject to such a lookup. So for any member types you may have, only a namespace will allow calls via ADL.
These four are off the top of my head. Judge your needs for yourself. As for "Is there any other option?", those are the only two ways you have to group such functions in C++ today. In C++20, we'll have modules! That will offer another level of grouping for code.
In addition the information given above I would add that going back to the standard definition of what a class and what a namespace is can help with decisions like this.
A namespace is a declarative region that provides a scope to the identifiers (the names of types, functions, variables, etc) inside it. Namespaces are used to organize code into logical groups and to prevent name collisions that can occur especially when your code base includes multiple libraries.
In object-oriented programming, a class is an extensible program-code-template for creating objects, providing initial values for state (member variables) and implementations of behavior (member functions or methods).
While these may sound similar they are rather specific. So if your functions are related, but not necessarily to the same object I would think hard about whether to put them in a class; particularly if grouping these functions together in a class may violate the Single Responsibility Principle: https://en.wikipedia.org/wiki/Single_responsibility_principle
I am learning C++, and want to confirm few thins. I have seen that std::cin has :: operator which means that iostream.h file must have cin related code inside namespace std. Whereas if you include myclass.h and have class NOT inside namespace like this
//myclass.h
class x { void func(){}};
Then you don't need to do this myclass:x.func(); Instead i can do just this x.func();. Correct Becuase it's not inside namespace.
Secondly, :: can be used to define class functions outside of the class like in their cpp file. Correct?
Now my additional question is that are these two functions separate or one? do they just look different to me?
:: (scope resolution operator) is used for multiple purposes in C++?
It's only really serving one purpose - to help find the namespace and/or class/struct/union scope that an identifier's in.
The compiler knows to look first in the tightest scope then work its way back to the global scope, but it also considers any namespaces and identifiers you're "using" (e.g. using namespace xxx; or using ns1::identifier;).
Then you don't need to do this myclass:x.func(); Instead i can do just this x.func();
It has nothing to do with files on disk.
Secondly, :: can be used to define class functions outside of the class like in their cpp file. Correct?
Yes. When you define a member function outside its class, you use the class name so it's not deemed a distinct non-member function in the current scope.
Now my additional question is that are these two functions separate or one? do they just look different to me?
Just the one in the defining-member-function scenario above.
I have seen that std::cin has :: operator which means that iostream.h file must have cin related code inside namespace std.
I realize this isn't a question, but you said iostream.h and I wanted to point out that you should not use iostream.h because it is deprecated, use iostream instead.
Then you don't need to do this myclass:x.func(); Instead i can do just this x.func();. Correct Becuase it's not inside namespace.
This is correct. You could do the same thing if all of your code was inside a namespace rather than a class.
Secondly, :: can be used to define class functions outside of the class like in their cpp file. Correct?
Correct, so long as they have been declared, but not defined, in the class scope this is allowed and usually considered preferable for readability.
Now my additional question is that are these two functions separate or one? do they just look different to me?
If both are in the class scope already, void x::func(){} and void func(){} result in the same thing (one would call both by using x a; a.func(), for example).
EDIT: In response to the comment, you can define a namespace basically the same way you define a class, as:
namespace funcs
{
void innerfunc(){}
void outerfunc();
void funcs::scopedfunc(){}
}
funcs::outerfunc();
As you can infer from std, these are called as free functions, rather than being called from an object like a non-static class function.
int main()
{
funcs::innerfunc();
using namespace funcs;
outerfunc();
}
Then you don't need to do this myclass:x.func(); Instead i can do just this x.func();.
Note that neither of these will compile. You cannot use the dot operator with a class; you can only use it with an object. Specifically, myObject.func(); serves an entirely different purpose than MyClass::func() { }. The first calls the member function func() on the object named myObject. The later is used to define the function func() which belongs to the scope of MyClass.
I can do in WSDL definitions that is not in any namespace?
I want do half objects have namespace and other don't have.
Why do you want your elements to be without any namespace?
If you mean not prefixing any elements with any namespace, that is using the default namespace. You can read more about it here which also has a pretty illustrative example.
In C++, should we be prepending stuff in the global namespace with ::?
For example, when using WinAPI, which is in C, should I do ::HANDLE instead of HANDLE, and ::LoadLibrary instead of LoadLibrary? What does C++ say about this? Is it generally a good idea, factoring in issues like readability and maintainability?
Names in C++ can be qualified and unqualified. There are different rules for qualified and unqualified name lookup. ::HANDLE is a qualified name, whereas HANDLE is an unqualified name. Consider the following example:
#include <windows.h>
int main()
{
int HANDLE;
HANDLE x; //ERROR HANDLE IS NOT A TYPE
::HANDLE y; //OK, qualified name lookup finds the global HANDLE
}
I think that the desicion of choosing HANDLE vs. ::HANDLE is a matter of coding style. Of course, as my example suggests, there might be situations where qualifying is mandatory. So, you might as well use :: just in case, unless the syntax is somewhat disgusting for you.
As namespaces don't exists in C, don't use ::HANDLE to access HANDLE type.
Using the prepending :: for global namespace is a good idea for readability, you know the type you want to access is from global namespace.
Moreover, if you are in a nested namespace and declare your own HANDLE type (for example), then the compiler will use this one instead of windows.h one!
Thus, always prefer using :: before names when working in nested namespace.
The main point of interest is what the differences are from the point of view of the compiler, as it has already been said, if you include the :: then you are using qualified lookup, rather than unqualified lookup.
The advantage of using qualified lookup is that it will be able to pinpoint a particular symbol always. The disadvantage is that it will always pinpoint that particular symbol --i.e. it will disable Argument Dependent Lookup. ADL is a big and useful part of the language, and by qualifying you effectively disable it, and that is bad.
Consider that you had a function f in the global namespace, and that you added a type T inside namespace N. Not consider that you wanted to add an overload of f that would take a T as argument. Following the interface principle, you can add f to the N namespace, as f is actually an operation performed on T, and it so belongs with the type. In this case, if you had code that called (consider generic code) ::f(obj) on an object of unknown type U the compiler will not be able to pick up ::N::f(obj) as a potential overload as the code is explicitly asking for an overload in the global namespace.
Using unqualified lookup gives you the freedom of defining the functions where they belong, together with the types that are used as arguments. While it is not exactly the same, consider the use of swap, if you qualify std::swap then it will not pick up your hand rolled void swap( T&, T& ) inside your N namespace...
I would only fully qualify identifiers when the compiler would otherwise not pick up the element I want.
It's largely a matter of style; there are no performance or efficiency concerns to speak of. It can be a good practice on large projects and projects intended to be compiled on many different platforms, as under these circumstances collisions between global names and names in a namespace are more likely to occur.
Normally, you do not have to prepend :: for the global namespace. (Only in some really rare circumstances). IMHO it harms readability, but, on the other hand it probably won't break your code
I put all of my code into a namespace, and I tend to prefer the C++ headers over the C headers, so the only symbols left in the global namespace tend to be from the Windows API. I avoid pulling symbols from other namespaces into the current namespace (e.g., I never have using namespace std;), preferring instead to qualify things explicitly. This is in line with Google's C++ style guide.
I've therefore gotten into the habit of qualifying WinAPI function calls with :: for a few reasons:
Consistency. For everything outside the current namespace, I refer to it explicitly (e.g., std::string), so why not refer to the Windows APIs explicitly (e.g., ::LoadLibraryW)? The Windows APIs namespace is the global namespace.
A lot of the WinAPI functions are named generically (e.g., DeleteObject). Unless you're very familiar with the code you're reading, you may not know whether DeleteObject is a call to something in the current namespace or to the Windows API. Thus, I find the :: clarifies.
A lot of Windows frameworks have methods with the same names as the raw calls. For example, ATL::CWindow has a GetClientRect method with a slightly different signature than WinAPI's GetClientRect. In this framework, it's common for your class to be derived from ATL::CWindow, so, in your class's implementation, it's normal to say GetClientRect to invoke the inherited ATL method and ::GetClientRect if you need to call the WinAPI function. It's not strictly necessary, since the compiler will find the right one based on the signature. Nevertheless, I find that the distinction clarifies for the reader.
(I know the question wasn't really about WinAPI, but the example was in terms of WinAPI.)
No, if you do not have a LoadLibrary method in your class you do not need to use the global scope. In fact, you should not use global scope because if you later on add a LoadLibrary to your class your intentions is probably to override the global function...