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.