>>Если ты не думаешь о машинном коде, то ты не пишешь эффективный код.
> Думай лучше об алгоритмах и структурах данных, пиши прозрачный, гибкий, масштабируемый
> и переносимый код. Компилятор заоптимизирует намного лучше, чем ты.

"Прозрачный", "гибкий", "масштабируемый", "переносимый" -- ты чё, курсов для эффективных менагеров в IT наслушался? Код надо писать в первую очередь таким, чтобы его можно было бы сопровождать. А всё остальное -- это уже определяется условиями конкретного проекта. На самом деле, если уж так говорить, то и возможность сопровождения не всегда важна. Нахрена мне писать масштабируемый или переносимый код, если я пишу для микроконтроллера? Можно подумать о том, чтобы заложить возможность портирования на другой микроконтроллер из того же семейства, да и то если есть осознанные причины так делать, и если это не требует больших усилий. А масштабироваться -- куда? На кластер из микроконтроллеров? "Гибкий" -- это что вообще такое? Это в каком смысле гибкий? Это в смысле, что я потом легко смогу внести изменения в код, обеспечив его повторное использование в другом проекте, или в смысле virtual на vitrual'е virtual'ом погоняет, и в результате мы получаем чуть ли не C++ с динамической типизацией, и всё ради абстрактной идеи повторного использования и гибкости, которые внезапно могут никогда не потребоваться этому коду? А вот работать ему потребуется, и сквозь весь этот динамизм прорываться тоже. Или в каком-то ещё смысле гибкий?

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

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

Стандарт знать надо. А что там на разных архитектурах творится, по-хорошему, не сильно важно. Они все примерно одинаковы. Если на одной норм получается, то и на другой получится неплохо. Больше вариаций привносит не архитектура, а реализация архитектуры, например, есть ли у неё конвееры, какой они длины, сколько их, кеширует ли эта реализация память, сколько там кеша под инструкции... Но с конвеерами компилятор неплохо справляется, а кеширование памяти сегодня отсутствует разве что в микроконтроллерах, то есть если ты не для мк пишешь, то можешь смело рассчитывать на кеширование, но вот оно кстати очень сильно влияет на структуры данных и алгоритмы, которые тебе следует выбирать, а для этого надо думать о кеше, о том как работает процессор, о том, к каким данным ты сейчас пытаешься обратиться -- к тем что в регистрах, в кеше, в оперативке?

>>Эээ...
> Опять ты мыслью по древу растёкся. Повторю вопрос: зачем перегонять в бинарный
> формат? Какую проблему ты этим решаешь?

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