Кроссплатформенные интегральные типы C++

А чем cstdint не угодил?

Интересное решение. А чем Вас не устраивают целочисленные типы из стандарта C++11?

На самом деле, кто хотел на VS иметь stdint.h, тот имел благодаря проекту msinttypes.

А насчёт "десятки стандартных типов" — это такая шутка? Вообще-то стандартных типов не 10, а 11. Про "signed char" вы забыли. Тот факт что по-умолчанию char может быть не только теоретически, но и практически любым выпило много крови тем, кто переносит код с x86 (где на большинстве компиляторов он знаковый) на ARM (где по умолчанию он беззнаковый).

Только сейчас прочитав статью заметил "небесспорный приём". Во-первый — он таки "бесспорный" (см. SFINAE). Во-вторых — ненужный.
В большинстве случаев будет достаточным сделать так:

template <int x> struct unsupported_capacity;
template <> struct unsupported_capacity<1> {};
template <> struct unsupported_capacity<2> {};
template <> struct unsupported_capacity<4> {};
template <> struct unsupported_capacity<8> {};

Это, правда, даст возможность описывать указатели на, скажем, "struct unsupported_capacity<3>" — но практически этого достаточно: где-то же в программе вы этот указатель захотите-таки разименовать? Вот там и получите ошибку...

Интегральными бывают суммы, схемы и теоремы Коши. А типы — целочисленные.

Хочу немного позанудствовать. Вам никто не обещал что char будет иметь размер в один октет. Иными словами, тот факт что sizeof(char) == 1 не значит что char занимает ровно 8 бит. Он может быть размером 32 бита.
Вряд ли ваш код попадет на платформу где такое имеет бысто быть. Но если вдруг попадет — он там попросту сломается.
Поэтому, он не совсем кроссплатформенный.
Стандарт, кстати, гарантирует только сущесвование типов а-ля int_leastХХ_t и говорит что могут существовать системы где intXX_t просто не определен.

Потерян ещё один тип: «signed char».
Действительно «signed int» идентичен типу «int».
А вот: «unsigned char», «signed char» и «char», это три разных типа.

Ну и кроме того не «интегральные», а «целочисленные». Интегральный это от слова integral, и связано это понятие с такой математической закорючкой. А целочисленный — это integer.

Даже на одной аппаратной платформе, например x86_64 (ia32e), разные ОС по разному интерпретируют резиновые целочисленные типы, введенные в С/C++ в качестве базовых. Резиновые они потому, что стандарт не определяет их длины, он только вводит отношения
sizeof(short int) \le sizeof(int) \le sizeof(long int) \le sizeof(long long int)
Это значит, что не исключается случай, когда все эти типы будут иметь одинаковую длину.
Разумеется, использовать эти типы можно лишь в том случае, если программа ничего не выводит и не выводит, потому что даже одна и та же программа, скомпилированная на разных платформах и/или разными компиляторами не сможет ввести данных, которые она вывела. Чтобы преодолеть это были введены жесткие типы, которые определены в stdint.h (). Эти типы локально настраиваются на соответсвующие резиновые в каждом конкретном случае установки компилятора на конкретную платформу, если таковые там присутствуют.
Как только возникает необходимость в бинарном выводе/вводе, эти типы должны использоваться безусловно. Они обладают абсолютной переносимостью, поскольку описываются в обязательной части стандарта.
Кстати, аналогичная ситуация может случиться при выводе/вводе символов — байт, вопреки расхожему мнению, это не 8 бит, а минимальная порция данных в адресуемой оперативной памяти. Так что запросто может случиться, что char может занимать, например, 12 бит.
В этой связи гораздо более полезно читать стандарт, чем толстые книги, переиздаваемые чуть ли не каждый год. Кстати, стандарт нужно читать не весь, а только до приложений, поскольку в приложения попадают ангажированные тексты спонсоров, пытающиеся возглавить то, что не удается разрушить.

С этим не поспоришь, стандарт приоритетнее

Если не дают использовать новый стандарт, всегда можно взять <boost/cstdint.hpp>.

Вы большой молодец и у вас много времени. Но зачем это нужно было-то? На дворе 2016 год.