Мне сказали, что C и C ++ имеют "неопределенное поведение", то есть один и тот же код может вести себя по-разному на разных платформах или с использованием разных компиляторов, если я использую "определенные конструкции".
Это не то, что на самом деле означает неопределенное поведение.Это результат неопределенного поведения, но это не то, для чего он нужен.
Спецификации предназначены для определения того, что происходит, когда вы что-то делаете.Он говорит, какие значения параметров хороши, а какие плохи.Если вы пропустите плохие, он скажет вам, какие ошибки вы получаете и каково будет состояние системы.Если текущее состояние недопустимо для операции, которую вы пытаетесь выполнить, спецификация объясняет, какие другие виды ошибок вы получаете и что это означает для состояния системы впоследствии.
Когда вы используете определенное поведение, выполагаться на договор между вами и реализацией;этот контракт называется спецификацией OpenGL.Вы полагаетесь на реализацию, чтобы обеспечить проверки достоверности, требуемые спецификацией.И вы полагаетесь на реализацию, делающую то, что сказано в спецификации.Если реализация не реализует что-то правильно, то это нарушает контракт.
Когда спецификация говорит, что определенный набор вещей приведет к "неопределенному поведению", это означает, что выполнение этих вещей является Вы нарушаете контракт.Вы находитесь за краем карты.Вы делаете что-то, для чего спецификация не обеспечивает определенного поведения;Вы нарушили свою часть соглашения.
Другими словами, ваш код будет идеально переносимым , пока вы не полагаетесь на неопределенное поведение.Вот что это значит.
Как правило, спецификация помечает что-то неопределенное, если ее тестирование является обременительным бременем для реализаций.В конце концов, OpenGL должен быть достаточно быстрым.Так что обременять водителя, заставляя его проверять вещи, которые почти невозможно проверить, - это то, чего они пытаются избежать.
Затем, существуют тесты, которые невозможно протестировать.В OpenGL запрещено считывать и записывать одно и то же изображение, связывая изображение как текстуру и сэмплируя его, одновременно прикрепляя это изображение к FBO и обрабатывая его.Невозможно гарантированно протестировать этот сценарий.
О, вы можете протестировать большинство из них.Вы можете потерпеть неудачу при вызовах отрисовки, когда одна и та же текстура связана с FBO и сэмплером.Но тогда вы не сможете рендерить разные мипмапы одной и той же текстуры;помните: каждый mipmap - это отдельное изображение.Таким образом, вы можете проверить, позволяет ли диапазон базового / максимального уровня предусмотреть возможность выборки из mipmap, привязанного к FBO.Но это ложится тяжелым бременем на пользователя, так как ему придется постоянно корректировать базовый / максимальный уровень при рендеринге на разные мипмапы.Им гораздо проще просто выбрать правильный mipmap с textureLOD или подобными функциями.И вы не сможете до времени выполнения определить, производят ли они выборку извне этого уровня mipmap.
OpenCL и OpenGL SL имеют неопределенное поведение, как и многие спецификации.И, как правило, он не определен по тем же причинам: его тестирование может сделать реализацию неприемлемо медленной, или тестирование невозможно.