История изменений
Исправление hateyoufeel, (текущая версия) :
Я вот против этого, против крайностей.
Ты, кажется, против всего подряд тут. Против defer, против этого.
За нормальное и качественное понимание происходящего под капотом.
Под капотом происходит следующее: компилятор следует гарантиям, описанным в стандарте языка. Других гарантий компилятор не даёт.
А флагов в компиляторе/линкере тьма тьмущая, практически на любое требуемое поведение скомпилированной программы.
Поведение этих флагов может измениться в следующей же версии, и ты будешь переписывать свой говнокод. Сходи в багзиллу GCC и почитай вопли вот таких же говнокодеров, у которых новая версия компилятора сломала их код.
Т.е. программист сначала придумывает, как в итоге должен работать бинарный код на процессоре, а потом пользуется теми инструментами, которые есть, включая флаги компиляции и линковки.
Программист должен подумать, как будет работать его код согласно абстрактной машине языка. Семантика абстрактной машины языка – это единственная гарантия, которую даёт язык. Потому что иначе процессор завтра будет другой (x86_64 -> ARM), и тогда код придётся переписывать.
Для нативных программ, программу исполняет процессор, он и есть верховный судья.
Нихрена подобного. Процессоры меняются регулярно, гораздо чаще чем код.
Исправление hateyoufeel, :
Я вот против этого, против крайностей.
Ты, кажется, против всего подряд тут. Против defer, против этого.
За нормальное и качественное понимание происходящего под капотом.
Под капотом происходит следующее: компилятор следует гарантиям, описанным в стандарте языка. Других гарантий компилятор не даёт.
А флагов в компиляторе/линкере тьма тьмущая, практически на любое требуемое поведение скомпилированной программы.
Поведение этих флагов может измениться в следующей же версии, и ты будешь переписывать свой говнокод. Сходи в багзиллу GCC и почитай вопли вот таких же говнокодеров, у которых новая версия компилятора сломала их код.
Т.е. программист сначала придумывает, как в итоге должен работать бинарный код на процессоре, а потом пользуется теми инструментами, которые есть, включая флаги компиляции и линковки.
Программист должен подумать, как будет работать его код согласно абстрактной машине языка. Семантика абстрактной машины языка – это единственная гарантия, которую даёт язык. Потому что процессор завтра будет другой (x86_64 -> ARM), и тогда код придётся переписывать.
Для нативных программ, программу исполняет процессор, он и есть верховный судья.
Нихрена подобного. Процессоры меняются регулярно, гораздо чаще чем код.
Исходная версия hateyoufeel, :
Я вот против этого, против крайностей.
Ты, кажется, против всего подряд тут. Против defer, против этого.
За нормальное и качественное понимание происходящего под капотом.
Под капотом происходит следующее: компилятор следует гарантиям, описанным в стандарте языка. Других гарантий компилятор не даёт.
А флагов в компиляторе/линкере тьма тьмущая, практически на любое требуемое поведение скомпилированной программы.
Поведение этих флагов может измениться в следующей же версии, и ты будешь переписывать свой говнокод. Сходи в багзиллу GCC и почитай вопли вот таких же говнокодеров, у которых новая версия компилятора сломала их код.
Т.е. программист сначала придумывает, как в итоге должен работать бинарный код на процессоре, а потом пользуется теми инструментами, которые есть, включая флаги компиляции и линковки.
Программист должен подумать, как будет работать его код согласно абстрактной машине языка. Семантика абстрактной машины языка – это единственная гарантия, которую даёт язык. Потому что процессор завтра будет другой (x86_64 -> ARM), и тогда код придётся переписывать.