1

Since at least C++11 we got lovely fixed width integers for example in C++'s <cstdint> or in C's <stdint.h> out of the box, (for example std::uint32_t, std::int8_t), so with or without the std:: in front of them and even as macros for minimum widths (INT16_C, UINT32_C and so on).

Yet we have do deal with libraries every day, that define their own fixed width integers and you might have seen for example sf::Int32, quint32, boost::uint32_t, Ogre::uint32, ImS32, ... I can go on and on if you want me to. You too know a couple more probably.

Sometimes these typedefs (also often macro definitions) may lead to conflicts for example when you want to pass a std fixed width integer to a function from a library expecting a fixed width integer with exactly the same width, but defined differently.

The point of fixed width integers is them having a fixed size, which is what we need in many situations as you know. So why would all these libraries go about and typedef exactly the same integers we already have in the C++ standard? Those extra defines are sometimes confusing, redundant and may invade your codebase, which are very bad things. And if they don't have the width and signedness they promise to have, they at least sin against the principle of least astonishment, so what's their point I hereby ask you?

nada
  • 2,109
  • 2
  • 16
  • 23

1 Answers1

9

Why do so many libraries define their own fixed width integers?

Probably for some of the reasons below:

  • they started before C++11 or C11 (examples: GTK, Qt, libraries internal to GCC, Boost, FLTK, GTKmm, Jsoncpp, Eigen, Dlib, OpenCV, Wt)

  • they want to have readable code, within their own namespace or class (having their own namespace, like Qt does, may improve readability of well written code).

  • they are build-time configurable (e.g. with GNU autoconf).

  • they want to be compilable with old C++ compilers (e.g. some C++03 one)

  • they want to be cross-compilable to cheap embedded microcontrollers whose compiler is not a full C++11 compiler.

  • they may have generic code (or template-s, e.g. in Eigen or Dlib) to perhaps support arbitrary-precision arithmetic (or bignums) perhaps using GMPlib.

  • they want to be somehow provable with Frama-C or DO-178C certified (for embedded critical software systems)

  • they are processor specific (e.g. asmjit which generates machine code at runtime on a few architectures)

  • they might interface to specific hardware or programming languages (Tensorflow, OpenCL, Cuda).

  • they want to be usable from Python or GNU guile.

  • they could be operating-system specific.

  • they add some additional runtime checks, e.g. against division by 0 (or other undefined behavior) or overflow (that the C++ standard cannot require, for performance or historical reasons)

  • they are intended to be easily usable from machine-generated C++ code (e.g. RefPerSys, ANTLR, ...)

  • they are designed to be callable from C code (e.g. libgccjit).

  • etc... Finding other good reasons is left as an exercise to the reader.

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • 3
    Okay, you win. I'll stop rolling my eyes every time I see one. – nada Nov 23 '21 at 15:13
  • 2
    I have so much code matching the first bullet point it's not funny. – user4581301 Nov 23 '21 at 17:52
  • 2
    I would just add that asmjit moved to C++11 and uses . I think the biggest reason why so many libraries define their own standard types is because MSVC didn't provide in the past. It was really pain to do anything cross-platform without so defining types that didn't conflict with it was almost always the easiest way of writing portable code. The situation now got better, but... you cannot simply remove types that are part of the API of some library. – Petr Feb 19 '22 at 19:52