numeric_limits<> specialization

[Dave]

Hello all,

Is is allowable for me to specialize numeric_limits<> for my own numeric
type? Does this violate any sort of rule against mucking with std?

Thanks,
Dave

 

[Alf P. Steinbach]

Is is allowable for me to specialize numeric_limits<> for my own numeric
type? Does this violate any sort of rule against mucking with std?

Technically yes, I think it does violate that rule.

Practically, no, I don't know any compiler that enforces that rule.

But you don't have to, just make your own class that forwards to
std::numeric_limits. A bit tedious, perhaps, but then you can fix some
things at the same time.

 

[Dave]

Technically yes, I think it does violate that rule.

Practically, no, I don't know any compiler that enforces that rule.

But you don't have to, just make your own class that forwards to
std::numeric_limits. A bit tedious, perhaps, but then you can fix some
things at the same time.

Yeah, even Comeau doesn't reject it, but performing this specialization sure
seems suspect to me! Comeau and VC++ 7.1 accept what's shown below without
so much as a warning.

Hmmm.... A class that forwards to std::numeric_limits<>... Interesting! I
assume that involves a class template named numeric_limits<> in my own
namespace (call it dave) and some sort of scheme to check if
std::numeric_limits<T>::is_specialized is true. If it is, that value is
used, otherwise I will expect that client code has specialized my
dave::numeric_limits with their numeric type. At least I think that would
be the gist of it...


#include <limits>

using namespace std;

struct foo_t
{
};

namespace std
{
template<>
class numeric_limits<foo_t>
{
public:
static const bool has_infinity = false;
};
}

int main()
{
(void) numeric_limits<foo_t>::has_infinity;
}

 

[Victor Bazarov]

Technically yes, I think it does violate that rule.

What rule is that? I've not seen the work "mucking" in the Standard.
And, as a matter of fact, you _are_ allowed to place any specialisation
of a standard template in the std namespace. See 17.4.3.1/1.

Practically, no, I don't know any compiler that enforces that rule.

And they are not supposed to.

But you don't have to, just make your own class that forwards to
std::numeric_limits. A bit tedious, perhaps, but then you can fix some
things at the same time.

....

 

[Alf P. Steinbach]

What rule is that?

§17.4.3.1/1 first sentence: you're not allowed to add to namespace std,
"unless otherwise specified".

And, as a matter of fact, you _are_ allowed to place any specialisation
of a standard template in the std namespace. See 17.4.3.1/1.

I don't see the word "any" in the standard.

As a matter of fact, §17.4.3.1/1 requires that such a specialization
depends on a user-defined name of external linkage, and also has some other
requirements on the specialization, so what you write is incorrect.

But nitpicking aside, yup, your intuition is correct that the OP can probably
safely place his specialization in namespace std; my intutition about that
was incorrect.

And they are not supposed to.

Yes they are, but that is quality-of-implementation issue.

 

[Rob Williscroft]

Dave wrote in

Hello all,

Is is allowable for me to specialize numeric_limits<> for my own
numeric type? Does this violate any sort of rule against mucking with
std?

Yes you can, you must however do a complete specialization, i.e.
provide all the members and types that the genuine article provides.

The easiest way to do that (in this case) is to derive from the
nearest pre-existing specialization, so for an unsigned like type:

struct an_unsigned
{
// whatever ...
};

#include <limits>

namespace std
{
template <>
class numeric_limits< an_unsigned>
:
public numeric_limits< unsigned >
{
public:

static const bool is_specialized = true;

static const int digits = /* whatever */;
static const int digits10 = (digits * 77) / 256;
};
}

Rob.

 

[Ron Natalie]

Hello all,

Is is allowable for me to specialize numeric_limits<> for my own numeric
type? Does this violate any sort of rule against mucking with std?

No...specializing templates from std is one of the few things you are allowed to do:
17.4.3.1 of the standard.

 

[Ron Natalie]

Technically yes, I think it does violate that rule.

No it doesn't.

Practically, no, I don't know any compiler that enforces that rule.

It's not requred to. Adding things (other than template specializations)
is undefined behavior.

 

[Alf P. Steinbach]

No it doesn't.

Victor and I have already discussed this, in this thread.

Some time ago.

The more complete answer is: it might, but probably doesn't. The specialization
must fulfill all requirements that the standard places on the original template,
and it must depend on a user-defined name with external linkage. Otherwise it's
undefined behavior.

It's not requred to.

That's a quality-of-implementation issue.