История изменений

Порядок байт. Ну начнём с того что например для обработки utf-8 по всем фронтам побитовые сдвиги и чтение отдельных битов, ну вроде ладно чё, в чём проблема, а проблема например в том что порядок байт разный и что мне определять сначала что у меня sparc64 или i386 а потом уже с учётом этого читать байты с конца или с начала?

Определяешь эндиантность в рантайме, преобразоввываешь в целевую перед отдачей клиентам. Собственно, с ней не вижу больших проблем.

Атомарность. Ну хорошо 32bit умирает, но мне пофигу если я пишу библиотеку то я хочу что бы она работала везде, ладно у меня может не быть uint64_t и знание того что где то long 64bit, а где то 32bit и я могу смело (да?) писать unsigned long long и быть уверенным что в 64 битной системе это 64 а в 32 битной это тоже 64 но эмулируется через два 32битных инта и вот тут как бы уже нет гарантий что операции записи переменной или чтения отработают.

#include <stdint.h> и типы uint64_t и т.п. тебя спасут. Для атомарных операций либо защищать мутексами, либо использовать интринсики типа __sync_fetch_and_add()

я правильно понимаю что нет никакой разницы пишу ли я uint64_t или unsigned long long int ?

Для компилятора - никакой. Но если нужна гарантия размера типа везде - только (u)intxx_t.

И да в случае если на какой либо системе нет <stdint.h>

Он есть везде, даже на вантузе, sdcc, newlib'е и стремных DSP'шниках ;) Новинки завезут, ясен пень не сразу. Для тредов я бы все рекомендовал бы pthread's, а для венды pthread обертку над виндовыми вызовами. Это уже покрывает 99% сценариев, за исключением изысков.

msvc поддерживать смысла большого нет - на С конпелятор они забили болт, оно много чего не умеет, да и смысл юзать это убожество, когда есть gcc?

Дайте советы если есть желание или почитать что что-бы просвятиться. У меня есть желание писать железный код, но чем больше я закапываюсь во всём этом тем меньше понимания как собственно его писать железно.

По началу не слишком загоняйся переносимостью на изыски, ибо premature optimization. Закопаешься. Если все же решил выбери 2-3 платформы, подними CI для автосборок на них на все, и попробуй хотя бы переносимость win/lin/mac обеспечить. Ну и не забудь про тесты и кавередж. Многие моменты, где будут проблемы переносимости тебе может подсказать coverity (см. scan.coverity.com)

У меня стандарт золотой: cmake + ctest для сборки и тестов, jenkins для CI, gcov->cobertura для сбора покрытия (можешь и хипстерский coveralls), проверка кода - clang-analyze, coverity, cppcheck.

Порядок байт. Ну начнём с того что например для обработки utf-8 по всем фронтам побитовые сдвиги и чтение отдельных битов, ну вроде ладно чё, в чём проблема, а проблема например в том что порядок байт разный и что мне определять сначала что у меня sparc64 или i386 а потом уже с учётом этого читать байты с конца или с начала?

Определяешь эндиантность в рантайме, преобразоввываешь в целевую перед отдачей клиентам. Собственно, с ней не вижу больших проблем.

Атомарность. Ну хорошо 32bit умирает, но мне пофигу если я пишу библиотеку то я хочу что бы она работала везде, ладно у меня может не быть uint64_t и знание того что где то long 64bit, а где то 32bit и я могу смело (да?) писать unsigned long long и быть уверенным что в 64 битной системе это 64 а в 32 битной это тоже 64 но эмулируется через два 32битных инта и вот тут как бы уже нет гарантий что операции записи переменной или чтения отработают.

#include <stdint.h> и типы uint64_t и т.п. тебя спасут. Для атомарных операций либо защищать мутексами, либо использовать интринсики типа __sync_fetch_and_add()

я правильно понимаю что нет никакой разницы пишу ли я uint64_t или unsigned long long int ?

Для компилятора - никакой. Но если нужна гарантия размера типа везде - только (u)intxx_t.

И да в случае если на какой либо системе нет <stdint.h>

Он есть везде, даже на вантузе, sdcc, newlib'е и стремных DSP'шниках ;) Новинки завезут, ясен пень не сразу. Для тредов я бы все рекомендовал бы pthread's, а для венды pthread обертку над виндовыми вызовами. Это уже покрывает 99% сценариев, за исключением изысков.

msvc поддерживать смысла большого нет - на С конпелятор они забили болт, оно много чего не умеет, да и смысл юзать это убожество, когда есть gcc?

Дайте советы если есть желание или почитать что что-бы просвятиться. У меня есть желание писать железный код, но чем больше я закапываюсь во всём этом тем меньше понимания как собственно его писать железно.

По началу не слишком загоняйся переносимостью на изыски, ибо premature optimization. Закопаешься. Если все же решил выбери 2-3 платформы, подними CI для автосборок на них на все, и попробуй хотя бы переносимость win/lin/mac обеспечить. Ну и не забудь про тесты и кавередж. Многие моменты, где будут проблемы переносимости тебе может подсказать coverity (см. scan.coverity.com)