Is it possible to redefine operator < for strings without modifying std namespace, to make this operator use in standard algorithms?
For example, I can write:
namespace std
{
bool operator <(const std::string & rhs, const std::string & lhs)
{
std::cout << "lol";
return false;
}
}
int main()
{
std::vector<std::string> lol = { "a", "b", "ba", "aa" };
std::sort(lol.begin(), lol.end());
}
and "lol" will be printed several times. But if I move operator < outside from std namespace, default operator < will be used and nothing will be printed. Is it possible to make std::sort using custom operator < without including it to std namespace?
Yes I know, I can pass another comparator to std::sort but it's interesting for me if I could do what I asked and how?
Also am I correct, that it's correct to add such template specialization to std namespace?
Update: This is not practical question, I just want to know how can I do that if it's possible.
No, it is not. Adding a function to the standard namespace is undefined behavior. [namespace.std]/1 states:
The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified. A program may add a template specialization for any standard library template to namespace std only if the declaration depends on a user-defined type and the specialization meets the standard library requirements for the original template and is not explicitly prohibited.
If you want to change how std::sort sorts then you can provide a lambda and define what you want
std::sort(std::begin(foo), std::end(foo), [](const auto& lhs, const auto& rhs) { /* your code here */ });
Is it possible to redefine operator < for strings without modifiying std namespace
You can define the overload in another namespace, sure. But as you have found out, it will not be found by overload resolution unless explicitly qualified.
Is it possible to make std::sort using custom operator < without including it to std namespace?
Yes, and you already seem to know how:
Yes I know, I can pass another comparator to std::sort
This is exactly what the comparator argument is for.
Also am I correct, that it's corect to add such template specialization to std namespace?
That is not a template specialization; It is a function definition and you may not add function definitions to std namespace - or else the behaviour is undefined. You would be allowed to add template specializations, but only if at least one type argument is a user defined type.
Related
According to cppreference.com, std::rel_ops::operator!=,>,<=,>= will be deprecated in C++20.
What's the rationale behind?
In C++20, you get three-way comparison (operator <=>), which automatically "generates" default comparisons if provided:
struct A {
// You only need to implement a single operator.
std::strong_ordering operator<=>(const A&) const;
};
// Compiler generates 4 relational operators (you need to default the
// three-way comparison operator to get == and !=).
A to1, to2;
if (to1 > to2) { /* ... */ } // ok
if (to1 <= to2) { /* ... */ } // ok, single call to <=>
There are multiple advantages of the three-way comparison over std::rel_ops, which is probably why std::rel_ops operators are deprecated. On top of my head:
It is more versatile, since, depending on the return type of operator<=> (std::strong_ordering, std::weak_ordering, ...), only relevant operators are generated. See the <compare> header for more information.
You do not bring a bunch of templated operator overloads by doing using namespace std::rel_ops.
You can ask the compiler to generate the three-way operator for you by defaulting it (auto operator<=>(A const&) = default) — This will basically generate a lexicographic comparison of base classes and non-static data members, plus it will deduce the right type of ordering if the return type is auto.
What's the rationale behind?
rel_ops was deprecated by Library Support for the Spaceship (Comparison) Operator. The paper doesn't list any motivation, but it does appear in the spaceship paper:
This subsumes namespace std::rel_ops, so we propose also removing (or deprecating) std::rel_ops.
There are four reasons mentioned in the paper (including correctness and performance). But one big one not mentioned in either paper is that std::rel_ops just... doesn't work. Rule of thumb is that operators are found using ADL. rel_ops doesn't give you ADL-findable operators, it just declares unconstrained function templates like:
namespace std {
namespace rel_ops {
template< class T >
bool operator!=( const T& lhs, const T& rhs )
{
return !(lhs == rhs);
}
}
}
So using algorithms like:
struct X { ... };
bool operator<(X const&, X const&) { ... };
std::sort(values.begin(), values.end(), std::greater<>{});
Just doesn't work, unless you make sure to:
#include <utility>
using namespace std::rel_ops;
Fairly consistently everywhere as your first include to ensure that these operators are visible at the point of definition of every function template you could possibly call.
So operator<=> is just strictly superior:
It actually works.
You only have to write one function (<=>) instead of two (== and <)
Typically, you actually have to write zero functions (= default)
Did I mention it actually works?
C++20 provides Three way comparison thus the unique ones will become deprecated.
Consider this question, which is about the following code not compiling:
std::vector<int> a, b;
std::cout << (std::ref(a) < std::ref(b));
It doesn't compile because the vector comparison operators for vector are non-member function templates, and implicit conversions aren't allowed to be considered. However, if the operators were instead written as non-member non-template, friend functions:
template <class T, class Allocator = std::allocator<T>>
class vector {
// ...
friend bool operator<(const vector& lhs, const vector& rhs) {
// impl details
}
};
Then this version of operator< would have been found by ADL and been chosen as the best viable overload, and the original example would have compiled. Given that, is there a reason to prefer the non-member function template that we currently have, or should this be considered a defect in the standard?
Given that, is there a reason to prefer the non-member function
template that we currently have, or should this be considered a defect
in the standard?
The reason is if ADL could find out proper function or not. When such a search requires to extract the substituted template parameters from the type of given object and then substitute them many times into a templated parameter of the function template, ADL can't do this because of there are no reasons in the general case to prefer one way of template parameters binding to other. The non-member function template defined after but still in the namespace scope of that template (due to friend) excludes such an indeterminacy.
The STL functors are implemented like this:
template<class T>
struct less{
bool operator()(T const& lhs, T const& rhs){
return lhs < rhs;
}
};
This makes us mention the (possibly long) type everytime we create such a functor. Why are they not implemented like shown below? Any reasons?
struct less{
template<class T>
bool operator()(T const& lhs, T const& rhs){
return lhs < rhs;
}
};
That would make them usable without any mentioning of (possibly long) types.
It would also make it impossible to specialize them for user defined types.
They are supposed to be a customization point.
To summarize the discussions in the comments:
Although it is technically possible to do like Xeo suggests, the language standard doesn't allow it.
It is very hard to write a working class template if users are allowed to specialize individual functions of the template. In some cases it might however be a good idea to specialize the whole class for a user defined type.
Therefore the C++98 standard writes (17.4.3.1):
It is undefined for a C++ program to add declarations or definitions to namespace std or namespaces within namespace std unless otherwise specified. A program may add template specializations for any standard library template to namespace std.
As it isn't "otherwise specified" that Xeo's code is allowed, we are to understand that it is not. Perhaps not totally obvious! Or that "template specializations" only apply to classes.
The new C++11 standard has had this part expanded, and spells it out in more detail (17.6.4.2):
The behavior of a C++ program is undefined if it adds declarations or definitions to namespace std or to a namespace within namespace std unless otherwise specified. A program may add a template specialization for any standard library template to namespace std only if the declaration depends on a user-defined type and the specialization meets the standard library requirements for the original template and is not explicitly
prohibited.
The behavior of a C++ program is undefined if it declares
— an explicit specialization of any member function of a standard library class template, or
— an explicit specialization of any member function template of a standard library class or class template, or
— an explicit or partial specialization of any member class template of a standard library class or class template.
A program may explicitly instantiate a template defined in the standard library only if the declaration depends on the name of a user-defined type and the instantiation meets the standard library requirements for the original template.
Maybe:
std::multiset<long, std::less<int> > moduloset;
Odd thing to do, but the point is that std::less<int>, std::less<long>, std::less<unsigned int> implement different mathematical functions which produce different results when passed (the result of converting) certain argument expressions. Various algorithms and other standard library components work by specifying a functor, so it makes sense to me that there are different functors to represent those different mathematical functions, not just different overloads of operator() on one functor.
Furthermore, a functor with a template operator() can't be an Adaptable Binary Predicate, since it doesn't have argument types (an argument can have any type). So if std::less were defined as you suggest then it couldn't participate in the stuff in <functional>.
Also on a highly speculative note -- std::less was probably designed before support for template member functions was at all widespread, since there are various notes in the SGI STL documentation that say, "if your implementation doesn't support member templates then this isn't available". For such a simple component there would, I guess, be an incentive to do something that works today. Once it exists, the standardization could then have removed it in favour of something else, but was it worth disrupting existing code? If it was that big a deal, then either you or the standard could introduce a flexible_less functor as you describe.
Finally, why
template<class T>
bool operator()(T const& lhs, T const& rhs){
return lhs < rhs;
}
rather than
template<class T, class U>
bool operator()(T const& lhs, U const& rhs){
return lhs < rhs;
}
For user-defined types, the two might not be the same. Yes, this is an unfair question, since I don't know why there's no two-template-argument version of std::less ;-)
Inspired by contains(), I want do declare contains(), fitting misc containers.
// for std::vector, std::list, .. (1)
template<typename C, typename T>
bool contains(const C& container, const T& val)
{
return ::std::find(container.begin(), container.end(), val) != container.end();
}
// partial specialization for std::map (2)
template<typename K, typename V>
bool contains(const ::std::map<K, V>& container, const K& key)
{
// std::map.find() is better than std::find used in (1)
return container.find(key) != container.end();
}
Following question, I want to add the functions to namespace the arguments belongs too.
Questions:
Types of val from (1) and key from (2) are unknown. Does it mean I don't need to put the functions to any namespace or do I need to put them in std namespace, the containers belong to?
Is it possible to improve (2) it will preferred by compiler than (1) for std::map, std::set, boost::unordered_map, boost::unordered_set?
boost::algorithm::contains(). Do I need choose another name for my wrapper?
(1) Don't add anything to the std namespace
(2) As Space_C0wb0y points out, (2) is not a partial specialization, but an overload. I'm not sure if this is standard behaviour, but on VS2008 this is resolved correctly (the overloaded version is used for map). In either case, I think a slighly better version would be:
template<typename C>
bool contains(const C & mapContainer, const typename C::key_type & key)
{
// std::map.find() is better than std::find used in (1)
return mapContainer.find(key) != mapContainer.end();
}
This is a partial specialization (T is specialized to C::key_type) and would work for all types that has the key_type typedef (e.g. std::map, boost::unordered_map etc.)
(3) Put in separate namespace (see #Tony's answer)
Sidenote: I'm not sure I think these functions should have the same name. If I saw a function contains() accepting a map + another argument I could think that (1) the function checks if the map contains an entry for the given value (e.g. some key has the value provided) or (2) the function checks if there is such an entry in the map (e.g. the provided value is a pair). Instead I would call the function contains_key() for maps.
Edit:
After a bit of checking I suspect that the code above isn't compliant as it uses "template typedefs". This is not a standard C++ feature, but it seems that Visual Studio supports it in some cases. There's probably a workaround for this, but not one I'm clever enough to come up with now.
On number 3. you should place your version of contains in it's own namespace to avoid naming clashes. That's the purpose of namespaces.
Yes, keep them in a separate namespace.
The only thing to place in the same namespace as the argument type is operator overloads, to allow for Koenig (argument-dependent) lookup. These are not overloaded operators. End of story.
Note how this also answer question 2.: how you make the compiler prefer your implementations:
using myownversions::contains;
(assuming you named your namespace myownversions for now)
You must not put them into the std namespace. This is forbidden. You can put them into any namespace you like.
There is probably some SFINAE-magic you can do there, but I cannot come up with it in my own.
See #Tony's answer.
Since I need to add an operator& for the std::tr1::array<bool, N> I wrote the following lines
template<std::size_t N>
std::tr1::array<bool, N>
operator& (const std::tr1::array<bool, N>& a,
const std::tr1::array<bool, N>& b)
{
std::tr1::array<bool, N> result;
std::transform(a.begin(), a.end(), b.begin(), result.begin(),
std::logical_and<bool>());
return result;
}
Now I don't know in which namespace I've to put this function. I considered the std namespace as a restricted area. Only total specialization and overloaded function templates are allowed to be added by the user. Putting it into the global namespace isn't "allowed" either in order to prevent pollution of the global namespace and clashes with other declarations. And finally putting this function into the namespace of the project doesn't work since the compiler won't find it there.
What had I best do? I don't want to write a new array class putted into the project namespace. Because in this case the compiler would find the right namespace via argument dependent name lookup. Or is this the only possible way because writing a new operator for existing classes means extending their interfaces and this isn't allowed either for standard classes?
I fully support GMan and sbk who told you to use a named function instead of an operator. Contrary to popular believe, overloading operators is always almost wrong, because it almost never adds clarity to the code. There are surprisingly few exceptions. Among them are the stream input and output operators as well as the arithmetical operators should you implement a number-like type. (And just how likely is that outside of a book teaching you operator overloading?) Note that some people frown upon the std lib overloading + (and +=, of course) for std::string for the same reason (and others, like that a+b==b+a holds for numbers, but not for strings) - and IMO they do have a point.
Anyway if one wanted to do this despite all advice:
When you try to invoke the operator, the compiler tries to find it in the namespace it was invoked in, all enclosing namespaces, and the namespaces of all the arguments. (The latter is called argument-dependent lookup or Koenig lookup.) The namespace of the argument is std, which you must not add an overload to. So that leaves the namespace the operator is invoked in and its enclosing namespaces - including the global namespace, which encloses all others - to put the operator in.
So if you want to implement it despite all warnings, put it in the namespace where it is used in. If it is used in several namespaces, put it into the one that encloses all these. If that's the global namespace, so be it.
Oh, and did I mention you should not implement this as an overloaded operator?
AFAIK, you can add the overload to any namespace (except std, because you are not allowed to add new functions to it), and you'd make it visible with a using declaration. This is how, for example, boost's assign library works (pay attention to the introductory snippets; for a precedent in the standard library, check out rel_ops). Also note that you can restrict the scope of using declarations, so as to avoid global pollution.
Example, using boost::array because of an old compiler:
#include <boost/array.hpp>
#include <functional>
#include <algorithm>
using boost::array;
namespace bitarray_operators
{
template <size_t N>
array<bool, N> operator& (const array<bool, N>& a, const array<bool, N>& b)
{
array<bool, N> result;
std::transform(a.begin(), a.end(), b.begin(), result.begin(), std::logical_and<bool>());
return result;
}
}
int main()
{
using namespace bitarray_operators; //<-- this makes it possible to find the & operator
array<bool, 100> a, b, c;
c = a & b;
}
I concur that overloading this operator might be somewhat questionable. It's also unclear to me why you don't use std::bitset which overloads this operator with potentially better performance possible because of a more compact internal representation (each bool taking one bit, instead of at least the size of a char).