6

Background:
I tried to answer the question Why isn't my overloading < operator not working for STL sort. One of my suggestion (apart from using predicate) was to move the custom operator < for std::string in namespace std so that it can be preferred by the compiler over templated version.

At lightening speed the answer was down-voted with following comment from a highly reputed user:

This is undefined behaviour, you are not allowed to add declarations to namespace std because it can change the behaviour of the standard library componens

My Question:
Is it okay to add template specialization for stl types even if the declaration of this specialization doesn't contain user defined data type?

p.s. I have deleted my answer as I am afraid it may be possibly wrong

Community
  • 1
  • 1
Mohit Jain
  • 30,259
  • 8
  • 73
  • 100

4 Answers4

15

C++11, [namespace.std]§1:

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 above paragraph explcitily prohibits specialisations which do not depend on a user-defined type.

As to the motivation: you wouldn't be adding a template specialisation, but a separate declaration, which is also prohibited.

Angew is no longer proud of SO
  • 167,307
  • 17
  • 350
  • 455
  • Would it remain wrong even if I specialize `std::basic_string::operator <` for `charT = char`? – Mohit Jain Sep 23 '14 at 10:44
  • 4
    @MohitJain: Yes, it would remain wrong: you can only specialize it for user-defined types, not library-defined or built-in types. – Mike Seymour Sep 23 '14 at 10:44
  • The grey area is when you specialize it for someone else's user-defined type. E.g. trying to specialize `std::swap` for a `boost::` type is not Undefined Behavior by the Standard because they don't give `boost::` a special status. Specializing for `char` is outright wrong. – MSalters Sep 23 '14 at 10:56
  • @MSalters I wouldn't really call it a grey area - everything except built-in and `std` is user-defined, so it's simply OK. Even if a type comes from a 3rd party library, it forms part of *your* program, so *you* should be able to handle it as necessary. – Angew is no longer proud of SO Sep 24 '14 at 06:20
  • @Angew Well, it may be okay by the C++ standard; it may not be okay by the library you are using. – T.C. Sep 24 '14 at 07:41
5

Angew got the relevant quote, but the interpretation is flawed.

You propose to add a template specialization in namespace std. This is permitted only if it depends on a user-defined type. You specifically mention that it does not. Therefore, the preconditions for the exception are not met, and the basic rule (no additions) applies. Not OK.

MSalters
  • 173,980
  • 10
  • 155
  • 350
1

Standard Library is flexible enough, having many extra params for allocators, predicates etc. So that, if you're about to add something to std namespace, it seems you pursuit your goals via the wrong way.

Take a rest to switch your mind, then read STL sources and play conform with it.

Yury Schkatula
  • 5,291
  • 2
  • 18
  • 42
  • True. In particular, the STL generally accepts function objects as an alternative to the default of `std::less` (which is the function object wrapping `operator<`) – MSalters Sep 23 '14 at 10:58
0

STL classes are meant to be used in well-defined ways, i.e. either instantiate them with a POD type, or a STL class that conforms to the class's requirements, or a user-defined type that implements the class's requirements.

You're not supposed to inherit from STL types either; it's better to create a new class with the STL object as a member; then you can implement public methods matching the STL object's method signature.

Without going into all the rationale for this rules, this is the most portable and likely long-lived way to use STL classes. It keeps a bright line between application-specific classes and STL classes.

kent williams
  • 1