Здравствуйте, Евгений Музыченко, Вы писали:

N>>Битовые поля, если ты не заметил, уже есть в стандарте и в любом компиляторе. Значит, оправдано.

ЕМ>Я-то заметил, но определены они там чисто формально, фактическое размещение зависит от реализации. Как при таком подходе определить в стандарте размещения для различных архитектур?

Если есть такой атрибут, порядок жёстко фиксируется. Если нет, компилятор имеет прежнюю свободу.

EM> Если просто стандартизировать атрибуты с благими пожеланиями по их реализации, то бОльшая часть компиляторов на это забьет.

Почему забьёт? Сколько лет уже в MSC есть `#pragma pack`?

ЕМ>А если это все-таки протащить в стандарт, то сразу же всплывут и предложения атрибутов для LE/BE.

Да, это естественно.

EM> Затем кто-то захочет (и наверняка уже захотел), чтобы на любой архитектуре он мог автоматом читать/писать float/double в формате любой другой архитектуры.

А вот "в формате любой другой" уже нет.
Более реально иметь интринсики типа put_ieee754_be32(char *target, float value), при наличии поддержки соотв. стандарта в платформе (будет в 99% таковых). И это уже есть, как минимум в виде предложений (см. комплект ISO/IEC TS18661) — значит, кому-то оно реально нужно.

EM> И где будет пора остановиться?

Как везде и всегда, это вопрос баланса интересов и цены. Тут — просто, дёшево и полезно всем.

Здравствуйте, netch80, Вы писали:

EM>>Если просто стандартизировать атрибуты с благими пожеланиями по их реализации, то бОльшая часть компиляторов на это забьет.

N>Почему забьёт? Сколько лет уже в MSC есть `#pragma pack`?

MS всю жизнь пилил MSVC прежде всего для своих продуктов, и pack там много где используется. А на то, что им лично не нужно, они забивают десятилетиями. Если таки реализовать описанные Вами атрибуты — в какой доле имеющегося программного кода они пригодятся? Сколько нулей будет перед точкой в процентном выражении? Да и сколько Вашего собственного кода это сэкономит? Хоть сотая процента наберется?

EM>> Затем кто-то захочет (и наверняка уже захотел), чтобы на любой архитектуре он мог автоматом читать/писать float/double в формате любой другой архитектуры.

N>А вот "в формате любой другой" уже нет.

Почему? Наверняка найдется немало желающих таскать между разными архитектурами не унифицированный текстовый формат, как это сейчас принято, а двоичный в формате "доминирующей" архитектуры, и чтобы работающий с этим код на каждой станции выглядел максимально красиво и элегантно.

N>это вопрос баланса интересов и цены. Тут — просто, дёшево и полезно всем.

Всем — это какой доле программистов в мире?

Здравствуйте, netch80, Вы писали:

N>Вот представим себе ситуацию: в байте 3 битовых поля, начиная со старшего: в 1, 4 и 3 бита. Думаю, в каком-нибудь аудио-видеокодеке найдёте что-то очень похожее.
N>Наверняка для чтения/записи подобной структуры двигаете значения операторами сдвига и читаете/пишете масками? А почему, если это заморочно? (ну да, я давно привык, и вы наверняка тоже. а другим?)
Иногда двигаю биты с масками, а иногда, не поверите, прям байтом пишу, сразу все значения. Причем, если скорость вдруг в такой мелочи важна, то она разительно отличается от метода записи. Слишком много всяких разных вариантов и частных случаев, что бы давать оптимальное решение в общем виде в стандарте.

N>Ну да, ваша реплика была к другому — к ситуации типа "при наличии бита Z в позиции X возникает дополнительное двухбайтовое поле по смещению Y". Вот про это я и говорил, что указателями оно (обычно) разбирается.
Да в том то и дело что не обязательно поле в байтах. Возможно в битах и не кратно байтам, ну и как тут указатели помогут, я не пойму

N>Пакетов чего?
N>Если речь про какие-нибудь данные TCP, это уже не задача прикладного уровня.
Не обязательно TCP. Часто бывает куча протоколов друг в друге, как матрешка. Структура пакетов нижнего уровня зависит от изменений в данных верхнего уровня и всё равно приходится все переупаковывать при каких-то изменениях.

N>Но я согласен, что конкретный выхлоп там ещё мерять надо. Мой поинт был за то, насколько удобство описания для программиста помогает верификации программы.
Вот иногда бывает везёт, можно срезать углы и копировать данные целиком, меняя только нужные поля, но это скорее исключение. Чаше приходится менять всю структуру пакета.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Вот у меня телефон 2016-го года на Qualcomm Snapdragon 650.
ЕМ>...
ЕМ>Восемь секунд, Карл! На полутора гигагерцах и шести ядрах! Что нужно курить, чтобы так сделать? Я не знаю.

А ты профилировал ? Они загружены вообще ?
У тебя, возможно, флешка дохнет. И тупит поэтому. Отдавая сектор не с первого раза, а с пятого, с таймаутами. Всё тормозит, но процессор совершенно непричём.

Здравствуйте, IID, Вы писали:

ЕМ>>Восемь секунд, Карл! На полутора гигагерцах и шести ядрах!

IID>А ты профилировал ?

Чем можно профилировать на самом андроиде? Я знаю только способ через Android Studio, но ставить и разбираться ради такого лень.

IID>Они загружены вообще ?

Но чем еще можно заниматься столько времени? Если тапать на списках и лентах приложений, то страницы приложений открываются почти мгновенно, разве что дорисовываются в процессе. Тормозит именно переделка надписи на кнопке.

IID>У тебя, возможно, флешка дохнет.

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