Why is there no unsized Integer type? [closed]

Question

Why does the STL not contain an unbounded integer data type?

I feel like it's a data type whose purpose is similar to that of a string.
Programmers would not have to worry about overflowing values and could work with much larger numbers.

So I'm curious if there is a specific reason for it's absence.

This isn't an issue on how to implement or use one from a 3rd party library, but just a question as to why the language doesn't already come with one. Any links on the matter are appreciated.

Answer 1

You probably mean arbitrary precision arithmetic or big numbers.

Perhaps it is not in C++ because it is not relevant to a wide audience. Very probably, almost any non-trivial C++ code would use some part of the STL (std::ostream or collections like std::vector or types like std::string).

But a lot of code don't need big numbers.

Likewise, graphical interfaces (like Qt) are not a part of STL, for the same reasons. A lot of people don't care about these issues (e.g. in server code, or numerical applications).

And defining a standard library is a big effort. In my opinion, C++ STL is perhaps too big already; no need to add a lot more inside.

You might want to use GMP if you need it.

Answer 2

Because even way back when the STL was designed:

There were already significantly better arbitrary precision integer libraries in C. Sure they weren't officially classes, but the structures they used still did the job. An STL implementation wouldn't really get a great deal of uptake from those who need arbitrary precision integers, which leads me to my second reason:

Not that many people actually need arbitrary precision integers. Those who do, pull in a third party library. For most people 32bit longs did the job in those days. For many people they still do. And the performance is significantly better. Even on a system with no native 64bit operations you could simulate them with a few instructions and still be significantly faster than an arbitrary integer implementation (no matter how thin you make it, the arbitrary part and the likely heap allocations are going to make it more expensive than two lesser integer operations and a manual carry).

Beyond all that it simply comes down to Stroustrup didn't feel it had broad enough appeal to fit into his vision of the STL.

I think a better question would be why no currency or arbitrary precision decimal class in the STL, since I think they are far more commonly an issue, but the answers are the same.