Есть 2 32-битных счётчика. Как кросс-платформенно их запихать в 64-битное число?

Это кросс-эндианно?

Что значит кросс-эндианно? Endianess применимо к бинарному представлению данных - в коде ты его никак не касаешься, никакого endianess у тебя там нет, код будет работать везде одинаково (только a нужно кастовать к uint64_t перед сдвигом). А вот если ты собрался свой uint64_t передавать по сети или хранить на диске, разумеется никакой переносимости у тебя не будет.

Что именно у тебя не должно зависеть от endianness? Ты это число собираешься передавать на другую архитектуру и там с ним работать? Тогда беспокойся об endianness uint32_t в первую очередь. http://www.boost.org/doc/libs/1_62_0/libs/endian/doc/index.html тебе в помощь.

если передавать по сети, то всегда желательно использовать htons и наоборот. если ты просто про компиляцию для разных платформ, то только дефайнами и/или анализом платформы (#ifdef X86 ... #else ...)

http://stackoverflow.com/questions/9858610/endianness-and-socket-programming-...
храни в network order, короче

Это кросс-эндианно?

Да.

Если сохраню её невыровненно, то после a компилер добавит padding?

А если ты сохранишь int64_t невыровнено, а потом компилер добавит padding?

std::pair<uint32_t, uint32_t>, байтоложество не нужно. /thread

В принципе могу заюзать структуру

Можно еще заюзать массив из двух uint32_t

Какой смысл вкладывается в понятие «кросс-эндианно»? Зачем это вообще надо? Ты это собираешься передавать по сети? Тебе важно, какой конкретно uint32_t займет старшую половину uint64_t, а какой младшую?

Распаковывать-упаковывать можно тупо через memcpy, и это может оказаться быстрее, чем эти маски-сдвиги.

Четыре байта через memcpy? Месье шутник.

memcpy отлично инлайнится на константных размерах копирования

Кстати, да, ты прав, это я маху дал.

Внутри программы: struct

Для взаимодействия с внешней средой: http://leopard.in.ua/2013/10/13/binary-serialization-formats

заведи сразу 64битную переменную и инлайнфункции для доступа к 32битным её частям

Низнаю как в плюсах, а на Си можно так, нопремер:

typedef union {
    struct {
        #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
            uint32_t l,h;
        #else
            uint32_t h,l;
        #endif
    };
    uint64_t x;
} myunion;

void main() {
    myunion u;
    u.l = 0x11;
    u.h = 0xff;
    printf("%016lx\n", u.x);
}

Какой же я тупой дебил,забыл про union и трахаю себе моск со сдвигами.

заведи сразу 64битную переменную и инлайнфункции для доступа к 32битным её частям

Так и сделал. Но какой же я тупой, если можно было заюзать union!

Да, я уже понял что я тупой школоло. Эндианность - это про layout в памяти, а не про представление длинных чисел в проце.

Спасибо, да. Оно ни при чём.

забыл про union
c++

ты только не забывай, что в Си это работает, а в с++, хоть g++ и гарантирует работу, это UB по стандарту.

Да ничем оно не отличается.

а union не спасает от bigendian. хотя ход конем: можно менять порядок следования счетчиков в union через ifdef

Дело не в спасении от bigendian, а в повышенном удобстве манипуляции 64-битным полем через 2 отдельных именованных поля.

1) Это кросс-эндианно?

Да.

2) В принципе могу заюзать структуру

Не надо.

Если хочется, то можно сделать ее packed, и даже поставить где-то условие, что ее размер должен быть ровно 8 байт.

UPD. Хотя так, наверно, быстрее будет работать, чем со сдвигами.

До тех пор, пока оптимизатор не выкинет UB.

Базу Данных уже предлагали? :)

Предлагаю лисп.

Какой же я тупой дебил,забыл про union и трахаю себе моск со сдвигами.

Нет. Трахать себе моск - это:

#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__

Сдвиг - это значительно более простой и вменяемый способ сделать то, что тебе надо.