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?
CodePudding user response：
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
namespaceorclass(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 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.