
Little-Endian проти Big-Endian
Один час доводилося постійно працювати з мережевими даними і особливо з заголовками мережевого і транспортного рівнів моделі OSI. Постійно напружував той факт, що багато полів були в Big-Endian, а код виконувався на архітектурі Little-Endian. Ну неможливо було постійно викликати ntohl (), htonl (), ntohs (), htons ()...
Автор фото: Ciroduran, джерело фото: flickr.
Прийшла ідея реалізації наступної пари шаблонів: LittleEndian<T> и BigEndian<T>.
Шаблон для порядку байтів LittleEndian:
Шаблон для порядку байтів BigEndian:
Використовуйте шаблони так:
Залишилося дати типам більш симпатичні імена, наприклад так:
Тепер можна використовувати типи через більш короткі імена u16be, u32be...
Єдине, в цих шаблонах не вистачає різних операторів + =, - =, * =, + + та інших. Оператори є в повній версії коду, у статті їх наводити було недоцільно. Ось посилання на повні вихідні коди LittleBigEndian.h (див. нове посилання нижче в UPDATE1) і LittleBigEnd^ Names.h.
UPDATE1:
Як було вірно помічено користувачем qehgt в коментарі до посту, код не цілком коректний для 64-бітних чисел. Прошу вибачення за цю помилку. Ось LittleBigEndian.h (див. нове посилання нижче в UPDATE3), в якому ця помилка виправлена.
UPDATE2:
Товариш sic провів тести швидкості роботи наведених шаблонів порівняно з функціями htohl (), htonl (), ntohs (), htons (). Тести показали відносне підвищення швидкодії при використанні наведених шаблонів замість виклику бібліотечних функцій. Спасибі, за виконану роботу.
UPDATE3:
Товариш rekub побачив можливість підвищення швидкодії конструктора копіювання об'єкта. Він запропонував використовувати union для представлення даних і як масиву і як змінної типу T. Запропоновані модифікації були реалізовані в наступному вихіднику LittleBigEndian.h (див. нове посилання нижче в UPDATE4). Дякую!
UPDATE4:
Товариш vadelve вказав на помилку в реалізації операторів постфіксного і префіксного інкремента і декремента. Виправлена версія: LittleBigEndian.h.