There's recommendation in C++ community to not to use using namespace std;. But suppose you want to use string literals e.g. auto s = "dummy"s;.
Not using using namespace std; cause to failed compile. What is the solution?
operator""s is in 2 inlined namespaces in namespace std. It basically looks like this:
namespace std
{
inline namespace literals
{
inline namespace string_literals
{
//operator""s implementation
//...
}
}
}
So, to only get the string literals, use using namespace std::string_literals;.
Alternatevely, if you want to include every literal - including the string literals (like s for seconds if you include chrono, ...): using namespace std::literals;.
Depending on the situation, you might also consider using:
using std::string_literals::operator""s;
instead of importing every name from that namespace.
Note that you should still not include it in a header, at global level
(but you can do it inside inline or member functions or namespaces you control)
For string literals you can use:
using namespace std::string_literals;
That will pull about 4 names into the namespace which is fine. But when you do:
using namespace std;
Then you pull in thousands of names, many of which are commonly used in programs like count and time. This can create hard to find bugs from accidentally referring to the wrong thing.
That's not an issue with the string literals.
Also none of the names that using namespace std::string_literals; brings in should interfere with user defined names because user defined string literals must begin with _ (according to the standard) which avoids conflicts.
However you should still avoid using namespace std::string_literals; in the global namespace of a header file because you should not impose any feature on a user that they don't request.
Above operators are declared in the namespace std::literals::string_literals, where both literals and string_literals are inline namespaces. Access to these operators can be gained with using namespace std::literals, using namespace std::string_literals, and using namespace std::literals::string_literals
Source : std::literals::string_literals::operator""s
I would add the "using namespace" thing inside my block of code:
auto get_greetings()
{
using namespace std::string_literals;
return "Hello world"s;
}
So, the probability of having operator""s overloaded in some library should be ZERO, because the standard suggests we ordinary people should add a suffix with an underscore.
And, since I am adding this using namespace inside my function, no probability of name clashes will occur outside it.
Related
Consider this
#include<headerfile1>
#include<headerfile2>
.
.
#include<headerfilen>
using namespace std;
when I write this(header files are all in standard library of C++),does std namespace of all header files come into picture?
Also, if there are two libraries h1 and h2 and both have same namespace x and in those namespaces have same function func(). How do I resolve this?
From cppreference:
A using-directive that names the inline namespace is implicitly
inserted in the enclosing namespace (similar to the implicit
using-directive for the unnamed namespace).
For instance, in the following example, using namespace std::string_literals makes the operator visible inside the scope:
{ // in C++14, std::literals and its member namespaces are inline
using namespace std::string_literals; // makes visible operator""s
// from std::literals::string_literals
auto str = "abc"s;
}
If you use the using directive outside a scope (for instance as in your example), pain will follow, as the commenters stated, especially if this file is a header file: this namespace will be implicitly imported to any file that includes this one. This is why the proper way of managing a big project is to create your own namespace and put all your custom objects in that new namespace. If you really must use a using directive, do so in the implementation file, never in the header, and ideally within scopes.
This will help you avoid most conflicts, unless your namespace uses a common name:
namespace Matrix{ <--- Bad practice, Matrix will probably conflict with something
myStuff ...
}
namespace JohnsAwesomeMatrix236790{ <--- Namespace name is unique,unlikely to get conflicts.
myStuff ...
}
Also, it is much safer to import the few functions that you use instead of the entire namespace:
using namespace std; // Imports the entire namespace!
using std::cout; // Much better, we only import
using std::endl; // the names of the two functions we use a lot
Any decently written library you include will make very careful use of the using directive (if at all), so you normally don't have to worry about this. However, if you use code written with less stringent standards (e.g., scientific code) this is something to look out for.
There's recommendation in C++ community to not to use using namespace std;. But suppose you want to use string literals e.g. auto s = "dummy"s;.
Not using using namespace std; cause to failed compile. What is the solution?
operator""s is in 2 inlined namespaces in namespace std. It basically looks like this:
namespace std
{
inline namespace literals
{
inline namespace string_literals
{
//operator""s implementation
//...
}
}
}
So, to only get the string literals, use using namespace std::string_literals;.
Alternatevely, if you want to include every literal - including the string literals (like s for seconds if you include chrono, ...): using namespace std::literals;.
Depending on the situation, you might also consider using:
using std::string_literals::operator""s;
instead of importing every name from that namespace.
Note that you should still not include it in a header, at global level
(but you can do it inside inline or member functions or namespaces you control)
For string literals you can use:
using namespace std::string_literals;
That will pull about 4 names into the namespace which is fine. But when you do:
using namespace std;
Then you pull in thousands of names, many of which are commonly used in programs like count and time. This can create hard to find bugs from accidentally referring to the wrong thing.
That's not an issue with the string literals.
Also none of the names that using namespace std::string_literals; brings in should interfere with user defined names because user defined string literals must begin with _ (according to the standard) which avoids conflicts.
However you should still avoid using namespace std::string_literals; in the global namespace of a header file because you should not impose any feature on a user that they don't request.
Above operators are declared in the namespace std::literals::string_literals, where both literals and string_literals are inline namespaces. Access to these operators can be gained with using namespace std::literals, using namespace std::string_literals, and using namespace std::literals::string_literals
Source : std::literals::string_literals::operator""s
I would add the "using namespace" thing inside my block of code:
auto get_greetings()
{
using namespace std::string_literals;
return "Hello world"s;
}
So, the probability of having operator""s overloaded in some library should be ZERO, because the standard suggests we ordinary people should add a suffix with an underscore.
And, since I am adding this using namespace inside my function, no probability of name clashes will occur outside it.
In order to use operator""s for std::string you have to do using namespace std::string_literals. But user-defined literals that don't begin with _ are reserved, so possible conflict can't be an excuse. The other operator""s is from std::chrono but that's for int literals, so there's no conflict there either.
What's the reason for this?
There are actually two reasons why literals are put into namespaces:
It is considered undesirable that users would use using namespace std; just to get hold of the corresponding literals. Having the literals declared in namespaces specific to these doesn't cause the problem.
Depending on the domain it may be desirable to use s as the suffix for something else. There is already another suffix s to mean seconds but they don't really conflict.
In the video of STL's CppCon 2014 talk (posted by remyable in a comment) Stephan T. Lavavej explains the overall design of the literals in C++14 and its pretty clear that they are not supposed to be in the global namespace! Instead, the literal suffixes in the standard library live in a hierarchy of inline namespaces giving users fine-grained control over the literals being made available. For example, the literal suffix for strings is declared like this (21.3 [string.classes] paragraph 1):
namespace std {
inline namespace literals {
inline namespace string_literals {
string operator"" s(char const* str, size_t len);
}
}
}
This hierarchy of inline namespaces makes it possible for users to get the appropriate choice of literal suffixes:
using namespace std; - you get everything in the standard C++ library, including the literal suffixes, without any qualification.
using namespace std::literals; - you get all literal suffixes defined in the standard C++ library.
using namespace std::string_literals; - you get all literal suffixes applicable to strings.
using namespace std::literals::string_literals; - yes, you can do that but you really shouldn't: that's equivalent to using namespace std::string_literals;.
Clearly, the committee wouldn't have gone to that much effort if it had considered the idea viable to just pollute the global namespace with literal suffixes, although they can't even conflict with any user literal suffixes.
In order to use operator""s for std::string you have to do using namespace std::string_literals. But user-defined literals that don't begin with _ are reserved, so possible conflict can't be an excuse. The other operator""s is from std::chrono but that's for int literals, so there's no conflict there either.
What's the reason for this?
There are actually two reasons why literals are put into namespaces:
It is considered undesirable that users would use using namespace std; just to get hold of the corresponding literals. Having the literals declared in namespaces specific to these doesn't cause the problem.
Depending on the domain it may be desirable to use s as the suffix for something else. There is already another suffix s to mean seconds but they don't really conflict.
In the video of STL's CppCon 2014 talk (posted by remyable in a comment) Stephan T. Lavavej explains the overall design of the literals in C++14 and its pretty clear that they are not supposed to be in the global namespace! Instead, the literal suffixes in the standard library live in a hierarchy of inline namespaces giving users fine-grained control over the literals being made available. For example, the literal suffix for strings is declared like this (21.3 [string.classes] paragraph 1):
namespace std {
inline namespace literals {
inline namespace string_literals {
string operator"" s(char const* str, size_t len);
}
}
}
This hierarchy of inline namespaces makes it possible for users to get the appropriate choice of literal suffixes:
using namespace std; - you get everything in the standard C++ library, including the literal suffixes, without any qualification.
using namespace std::literals; - you get all literal suffixes defined in the standard C++ library.
using namespace std::string_literals; - you get all literal suffixes applicable to strings.
using namespace std::literals::string_literals; - yes, you can do that but you really shouldn't: that's equivalent to using namespace std::string_literals;.
Clearly, the committee wouldn't have gone to that much effort if it had considered the idea viable to just pollute the global namespace with literal suffixes, although they can't even conflict with any user literal suffixes.
I'm using in my code many namespaces including the std one , so when I want to declare a string variable in my code should I precise std::string or I can just put string :
#include <string.h>
using namespace std;
using namespace boost;
using namespace xerces;
int main()
{
/*! should I declare my str like this */
std::string str;
/*! or I can declare it like this */
string str1;
cout << str << str1 <<endl;
return 0;
}
Since you have using namespace std;, the name string means the same as std::string[*]. It's therefore a question of style which you prefer (and if you prefer std::string then you can leave out using namespace std;).
There are some name clashes between std:: and boost::, in particular for things that were trialled in Boost prior to standardization. So for example if you include the appropriate headers then both std::shared_ptr and boost::shared_ptr exist. They may or may not refer to the same type, I haven't checked whether Boost tries to detect the standard type before defining its own.
So it's not necessarily a good idea to use both std and boost namespaces at the same time. You can use individual names with using std::string;, instead of the whole namespace.
[*] if std::string is defined, which it isn't, since you didn't include <string>.
You can just write string. But what if boost or xerces also have a symbol string? I would advise against using these using directives. It is not only string that could clash. You are essentially pulling a whole lot of symbols into the global namespace. If you really want to avoid typing std:: then you can use a typedef:
typedef std::string MyStr;
You can put just string if you use using namespace std;.
Adding using namespace std; may not be the best idea in all cases, because it can lead to conflicts between namespaces in some cases (though unlikey for string).
Usually it is not needed to specify std::string if you have declared using namespace std; BUT as a general case, if there are multiple namespaces which contain different classes with the same name, then you will have to specify the namespace next to the type (namespace::type) regardless of the existence of the using statement.
You are using the namespace std so you do not NEED to prepend string with std:: but you CAN if you want.
A good way to code is not to use any relevant namespace in headers, in order to prevent exposing the namespaces outer when #include. But in compiled source, you can do whatever you want, even using the std namespace and call std::string. Sometimes it's even needed (if you include two namespaces that define the same string class).