2 байта в буфер отправки сокета

в смысле стоит ли обрабатывать результат вызова send ?

Может.

результат вызова стоит обрабатывать однозначно. а вот если в буфер не лезет все разом, то придется писать экстракод для досылки

плиз, обрисуйте причины или ткните в спецификацию

экстра кода так много ? может возьмите уже что готовое тот же asio/libevent/libev если на обычной std::string досылку сделать не хотите

вы пишите школьную поделку ? ставите ассерт 2 байта и не паритесь

Досылка есть, искала возможность упростить код.
Поделка не школьная. К сожалению очень мало опыта работы с С++ и с сокетами и жалею о том что не начала с asio/libevent/libev

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

Причины могут быть любыми, вплоть до атомного холокоста.

Примерно так же и сделала буфер и указатель.
Все работает, но я смотрю на код и понимаю что это так выглядеть не должно. Может перфекционизм какой-то, но прошлое С-шника не отпускает. Досылка и вся эта муть должны скрываться в ООП... Однозначно, нужно изучать asio/libevent/libev

атомный ЛОКАЛхост

не видя кода сказать нельзя, буфер досылки с двумя указателями это и есть ООП, byteStream поток, читаем и пишем

Примерно так же и сделала буфер и указатель.

как проверялся код, когда send вернул меньшее чем было запрошено ?

Конкретно в случае с 2-мя байтами никак не проверялся. Рассматриваю как вариант с досылкой где колво данных неважно

Если send() заLD_PRELOAD'ить на свою кастомную функцию, то может, если это настоящий send(), то не может.