Согласись, что мемантически использовать функцие для этого более правильно. Легче читать.
+ ты не завязан на архитектуру.
А смысл статьи про перенос: делайте абстракции и используйте функции. И по возможности используйте готовые функции. И не используйте знания, какие-то. Они могут измениться.
при sizeof(char) == 1 мы получаем аж целых 24 байта. В случае powerpc мы сможем обратиться только к адрессам выравненым по смещению кратному dword. И данный код работать не будет, увы.
Зато с ним, возникает вопрос про утилизацию соеденений. Т.е. либо надо иметь pool соеденений, который будет использоваться, либо открывать на каждого пользователя новое keep-alive соеденение и закрывать как уйдет пользователь, либо придумывать асинхронный HTTP.
Т.е. с ходу, я не уверен что keep-alive до backend будет сильным плюсом. Особенно в контексте сложности реализации этого в nginx
+ ты не завязан на архитектуру.
А смысл статьи про перенос: делайте абстракции и используйте функции. И по возможности используйте готовые функции. И не используйте знания, какие-то. Они могут измениться.
Если надо циклам, то я бы переводил строку к long и делал бы логические операции с несколькими шаблонами ;)
при sizeof(char) == 1 мы получаем аж целых 24 байта. В случае powerpc мы сможем обратиться только к адрессам выравненым по смещению кратному dword. И данный код работать не будет, увы.
Далее. если человек путает sizeof(int) и sizeof(int*) то это уже повод задуматься.
Далее, не говорится что для размеров стоит использовать size_t;
Далее, не говориться что на нормальных архитектурах
приведет к сегфолу, ибо верить что ты имеешь доступ к любой памяти, это крайне наивно!
Т.е. с ходу, я не уверен что keep-alive до backend будет сильным плюсом. Особенно в контексте сложности реализации этого в nginx