Что такое compile time
Compile-time проверка в C/C++
BOOST_STATIC_ASSERT и все-все-все
Существуют много способов сломать компилятор во время компиляции. Из них мне больше всего нравится такое исполнение:
Но если у вас в программе используется boost, то ничего изобретать не нужно: BOOST_STATIC_ASSERT. Также поддержка обещает быть в С++11 (static_assert).
С инструментом разобрались, теперь об использовании.
Контроль количества элементов в enum
Перечисления — набор связанных по смыслу констант, которые, как правило, используются в точке ветвления логики программы. Точек ветвления обычно несколько, и можно легко что-нибудь пропустить.
Пример:
Последний элемент — не алгоритм, а вспомогательная константа с номером на единицу большим, чем максимальный смысловой элемент.
Теперь везде, где используются константы из этого набора, нужно просто добавить проверку:
Если в будущем добавятся новые константы, код в этом месте перестанет компилироваться. Значит, автор изменений должен будет просмотреть этот участок кода и, при необходимости, учесть новую константу.
В качестве бонуса от введения EM_ItemsCount появляется возможность вставлять runtime-проверки параметров функции:
Сравните с вариантом без такой константы:
(добавляем EM_AES512 и получает неправильную проверку)
Массивы и enum
Частный случай проверки из предыдущего раздела.
Предположим, у нас есть массив с параметрами к тем же алгоритмам шифрования (пример немного высосан из пальца, но в жизни встречаются похожие случаи):
Требуется поддерживать эту структуру синхронной с TEncryptMode.
(Зачем нужен последний элемент массива, думаю, объяснять не нужно.)
Нам понадобится вспомогательный макрос для вычисления длины массива:
Теперь, можно записать проверку (лучше, если сразу за определением params):
upd: В комментариях хабраюзер skor предложил более безопасный вариант макроса lengthof, за что ему спасибо.
switch
Тут всё очевидно (после примеров выше). Перед switch(mode) добавляем:
Чуть менее очевидная runtime-проверка:
Дополнительный бастион для обороны от ошибок. Если действия обрабатываются одинаково, лучше перечислить несколько case-условий для одного действия, оставив default не занятым:
Классы с разнородными данными
Отвлечёмся от enum’ов и посмотрим на такой класс:
Очень может быть, что когда-то в будущем кто-то захочет добавить в него переменную int c. Класс к этому времени стал большим и сложным. Как найти точки, в которые нужно прописать переменную c?
Предлагается такой полуавтоматический способ решения — заводим в классе константу версии данных:
Теперь во всех методах, в которых важно отследить целостность всех данных, можно прописать:
Benefit
compile time
Смотреть что такое «compile time» в других словарях:
Compile time — In computer science, compile time refers to either the operations performed by a compiler (the compile time operations ), programming language requirements that must be met by source code for it to be successfully compiled (the compile time… … Wikipedia
compile time — kompiliavimo laikas statusas T sritis informatika apibrėžtis Laiko tarpas, per kurį kompiliuojama programa. atitikmenys: angl. compile time; compiletime ryšiai: palygink – saistymo laikas palygink – vykdymo laikas … Enciklopedinis kompiuterijos žodynas
compile time — kompiliavimo trukmė statusas T sritis informatika apibrėžtis Laikas, per kurį sukompiliuojama programa. atitikmenys: angl. compile time; compiletime … Enciklopedinis kompiuterijos žodynas
compile time — noun The point at which a program is converted from source code to machine code; literally the time of compilation. Ant: runtime … Wiktionary
Compile time function execution — (or compile time function evaluation, CTFE) is the ability of a compiler, that would normally compile a function to machine code and execute it at run time, to execute the function at compile time. This is possible if the arguments to the… … Wikipedia
compile time constant — kompiliavimo konstanta statusas T sritis informatika apibrėžtis Konstanta, kuriai reikšmė suteikiama programos kompiliavimo metu ir vėliau nebegali būti pakeista. Tai ↑literalinės konstantos arba ↑vardinės konstantos, kurioms konstantų aprašuose… … Enciklopedinis kompiuterijos žodynas
compile-time binding — statinis saistymas statusas T sritis informatika apibrėžtis Adresų saistymas programos kompiliavimo arba saistymo metu. atitikmenys: angl. compile time binding; early binding; static binding ryšiai: palygink – dinaminis saistymas … Enciklopedinis kompiuterijos žodynas
compile-time error — kompiliavimo klaida statusas T sritis informatika apibrėžtis Programos tekste esanti ↑klaida, kuri aptinkama kompiliuojant programą. Tai ↑sintaksės klaida arba kuri nors kita klaida, kuri gali būti aptinkama nevykdant programos, pavyzdžiui,… … Enciklopedinis kompiuterijos žodynas
Compile farm — A compile farm is a server farm, a collection of one or more servers, which has been set up to compile computer programs remotely for various reasons. Uses of a compile farm include: Cross platform development: When writing software that runs on… … Wikipedia
Just-in-time compilation — In computing, just in time compilation (JIT), also known as dynamic translation, is a method to improve the runtime performance of computer programs. Historically, computer programs had two modes of runtime operation, either interpreted or static … Wikipedia
Worst-case execution time — The worst case execution time (WCET) of a computational task is the maximum length of time the task could take to execute on a specific hardware platform. Knowing worst case execution times is of prime importance for the schedulability analysis… … Wikipedia
Compile-time рефлексия D
Доброго времени суток, хабр!
Сегодня поговорим о том, что делает метапрограммирование в D таким гибким и мощным — compile-time рефлексии. D позволяет программисту напрямую пользоваться информацией, которой оперирует компилятор, а не выводить её хитрыми способами. Так какую информацию позволяет получить компилятор и как её можно использовать?
Начнём с, наверное, самых частых в использовании, приёмов — выяснение валидности выражения:
И __traits(compiles, expr) и is(typeof(expr)) ждут валидное, с точки зрения лексики, выражение expr (например, выражение 12thb не является валидным идентификатором, поэтому компилятор выдаст ошибку). Ведут себя они одинаково, но у них есть одно тонкое идейное различие — is(typeof(expr)) не проверяет возможность компиляции, а проверяет существование типа выражения. Следовательно, теоретически, возможна ситуация, когда тип может быть известен, но по каким-либо правилам данная конструкция не может быть скомпилирована. На практике я не встречал таких ситуаций (возможно, их пока нет в языке).
Задача: создание функции, принимающей любые «похожие» на массивы объекты, содержащие «похожие» на числа элементы, возвращающей среднее значение (мат. ожидание).
Решение:
Внимание: не используйте код из примера (isNumArray), так как он не учитывает некоторых деталей (opIndex может возвращать константную ссылку, тогда не будут возможны операции присвоения).
Конструкция is(… )
Так же можно проверять чем является тип, выяснить его модификаторы
В этом случае Specialization это одно из возможных значений: struct, union, class, interface, enum, function, delegate, const, immutable, shared. Соответственно проверяется является ли тип T структурой, объединением, классом и т.д. И существует форма, комбинирующая проверку и объявление alias’а
Есть ещё один интересный приём — pattern-matching типов.
В этом случае TypeTempl — описание типа (составного), а TemplParams — элементы, из которых состоит TypeTempl.
Большая часть __traits, после ключегого слова, принимает выражение в качестве аргумента (или их список, разделённый запятыми), проверяет его результат на соответствие требованиям и возвращает булево значение, отражающее прохождение проверки. Выражения должны возвращать либо как таковой тип, либо значение типа. Другая часть принимает 1 аргумент и возвращает что-либо более информативное, нежели булево значение (в основном списки чего либо).
Для наглядности написал небольшой тест, показывающий разницу
isVirtualMethod возвращает true для всего, что можно перегрузить или уже было перегружено. Если функция не перегружалась, а изначально была final, она не будет виртуальным методом, но будет виртуальной функцией.
Насчёт знаков вопроса около лямбды и функции (литерал функционального типа) пояснить не могу, они по неведомой мне причине не прошли проверку ни на function ни на delegate.
Шаблонизация и ограничение сигнатуры
В простейшем исполнении шаблонная функция выглядит так
Но так же у аргументов шаблонизации есть формы как и у конструкции is для проверки неявного приведения и даже для pattern-matching’а. Комбинируя это вместе с ограничениями сигнатуры можно создавать интересные комбинации перегруженных шаблонных функций:
Compile-time функциональное программирование в D
Сегодня мы рассмотрим одну из главных фич языка D, ради которой он и создавался — это продвинутое программирование на этапе компиляции. Некоторые могут припомнить как на C++ высчитывается факториал или, что посложнее, реализацию игры «Жизнь» и испугаться. Не стоит, шаблоны в D на порядок проще и мощнее аналога из C++, но все равно они требуют особого подхода в размышлениях, поэтому для акклиматизации сложность материала будет нарастать постепенно.
Постановка задачи
В D очень часто используется структурная типизация (аналог duck typing для статической типизации), например, чтобы проверить, поддерживает ли тип операции для его использования в операторе foreach:
static assert является вариантом классического assert, но который выполняется на этапе компиляции, и если в него передали выражение равное false, то он остановит компиляцию. А isInputRange объявлен как шаблон, который проверяет на наличие необходимых методов (можно детально и не вникать в следующий пример, все концепции рассмотрим дальше):
И на каждый свой compile-time интерфейс приходится делать по одному или несколько проверяющих шаблонов. Это немного утомляет, хотелось бы проверять на реализацию compile-time интерфейса следующим образом:
Вот функцию isExpose мы и будем реализовывать, попутно вникая в шаблонное программирование.
Разогрев
Для начала посчитаем факториал на шаблонах:
Ключевой момент в написании шаблонов — объявление константы или псевдонима с именем идентичным имени шаблона, это аналог return в обычных функциях. В данном шаблоне используется еще один внутренний, чтобы организовать хвостовую рекурсию (через аккумулятор).
В шаблоны можно передавать значения базовых типов, типы, списки типов, и, самое интересное, спикси выражений. Со значениями и типами все вполне понятно, такое есть во многих языках, но expression lists нужно пояснить:
С помощью expression lists в шаблоны можно передать что угодно, что можно вычислить на этапе компиляции. Итого далее мы будем работать со списками выражений практически повсеместно.
Операции над символами
Начнем собирать необходимый шаблон isExpose:
Посмотрим на шаблон allSatisfy, он объявлен в стандартной библиотеке:
Он берет другой шаблон как первый параметр, который объявлен с ключевым словом alias, что обозначает «передача по имени». Без этого ключевого слова компилятор ругнулся бы о том, что шаблон F применен неправильно, а с alias получается аналог отложенного вычисления в функциональных языках. allSatisfy применяет F к каждому элементу T и проверяет, чтобы каждый раз шаблон F вернул true. Также может показаться странным способ разбиения списка агрументов в ветке else. Этот прием позволяет значительно оттянуть срабатывание защиты компилятора на бесконечную рекурсию, так как таким образом мы строим сбалансированное «дерево вызовов» вместо линейного откусывания по одному элементу от списка. Если все еще непонятно, вот схема:
Теперь нужно решить подзадачу проверки типа на наличие одного compile-time интерфейса. Для начала нам нужна способность явно создавать новые списки выражений, сделать это можно с помощью хитрого трюка:
Теперь воспользуемся помощью компилятора и узнаем список членов интерфейса (методы и поля):
__traits(allMembers, T) вернет список имент всех внутренних элементов типа T, подобронее о traits можно почитать тут. Теперь у нас есть имена методов и полей compile-time интерфейса, но этого недостаточно, имена элементов интерфейса и проверяемого типа могут совпадать, а их типы нет. Чтобы прикрепить типы элементов к их именам, организуем простой конвеер, но прежде нам понадобятся несколько вспомогательных шаблонов.
Шаблон, который повторяет свой аргумент n раз и возвращает этот список копий:
Шаблон, который применяет шаблон с двумя параметрами к списку:
Аналог fold или reduce для шаблонов:
При передаче нескольких List в любой шаблон, они автоматически раскрываются и склеиваются, что зачастую мешает реализовать операции над несколькими списками, поэтому объявим еще «жесткую» обертку над списком, которая раскрывается при явном вызове ее подшаблона:
В этом шаблоне мы не объявляли псевдоним с именем StrictList, что не позволяет этому шаблону автоматически заменяться на этот псевдоним при использовании. Также можно провести аналогию между подшаблонами и методами, при вызове StrictList!(T,U).expand нам вернут список из T и U.
Используя предыдущие шаблоны, реализуем последний вспомогательный шаблон. Он будет брать список списков(!) выражений и формировать новый список, в который элементы аргументов попадают по очереди (аналог функции zip в функциональных языках):
Вот когда у нас есть все необходимые кирпичики конвеера, можно нарисовать его схему:
Первая часть конвеера, реализуется так:
Для получения типа элемента интерфейса мы воспользовались примесью, которая присоединила тип интерфейса через точку к имени метода. И с помощью оператора typeof получаем тип выражения, сгенерированного в примеси. Далее проверяем, действительно ли пары тип-имя присутствуют в проверяемом классе/структуре:
Все кусочки пазла встали на свое место, итого полный код шаблона:
Время выполнения против времени компиляции
В чем разница между временем выполнения и временем компиляции?
Время компиляции
Время выполнения
Что может пойти не так, это ошибки времени выполнения :
Также могут быть ошибки, которые обнаруживает сама программа:
Я думаю об этом с точки зрения ошибок, и когда они могут быть обнаружены.
Строковому значению нельзя присвоить переменную типа int, поэтому компилятор точно знает, у этого кода есть проблема
Здесь результат зависит от того, какая строка была возвращена ReadLine (). Некоторые значения могут быть проанализированы в int, другие не могут. Это можно определить только во время выполнения
Время компиляции: период времени, в течение которого вы, разработчик, компилируете свой код.
Время выполнения: период времени, в течение которого пользователь запускает ваше программное обеспечение.
Вам нужно более четкое определение?
( редактировать : следующее относится к C # и подобным, строго типизированным языкам программирования. Я не уверен, поможет ли это вам).
Например, следующая ошибка будет обнаружена компилятором (во время компиляции ) перед запуском программы и приведет к ошибке компиляции:
С другой стороны, ошибка, подобная следующей, не может быть обнаружена компилятором. Вы получите ошибку / исключение во время выполнения (при запуске программы).
Преобразование исходного кода в вещи, происходящие на экране [screen | disk | network], может происходить (примерно) двумя способами; называть их составлением и интерпретацией.
В скомпилированной программе (примеры c и fortran):
Говорят, что то, что происходит на первом этапе, происходит во «время компиляции», а то, что происходит на втором этапе, происходит во «время выполнения».
В интерпретируемой программе (например, MicroSoft Basic (на DOS) и Python (я думаю)):
В этом случае разницу между временем компиляции и временем выполнения довольно сложно определить, и она гораздо менее важна для программиста или пользователя.
Java является своего рода гибридом, где код компилируется в байт-код, который затем запускается на виртуальной машине, которая обычно является интерпретатором байт-кода.
Существует также промежуточный случай, когда программа компилируется в байт-код и запускается немедленно (как в awk или perl).
По сути, если ваш компилятор может понять, что вы имеете в виду или что означает «во время компиляции», он может жестко закодировать это в код времени выполнения. Очевидно, что если ваш код времени выполнения должен выполнять вычисления каждый раз, когда он будет выполняться медленнее, то, если вы сможете что-то определить во время компиляции, это будет намного лучше.
Компилятор может выполнить это вычисление во время компиляции, потому что он знает, что такое 2 и что такое MY_CONSTANT. Как таковой он избавляет себя от выполнения вычислений при каждом отдельном выполнении.
Хм, ладно, время выполнения используется для описания того, что происходит во время работы программы.
Время компиляции используется для описания того, что происходит при сборке программы (обычно компилятором).
Время компиляции:
Вещи, которые выполняются во время компиляции, не вызывают (почти) никаких затрат при запуске результирующей программы, но могут повлечь за собой большие затраты при сборке программы.
Run-Time:
Более или менее полная противоположность. Меньше затрат при сборке, больше затрат при запуске программы.
С другой стороны; Если что-то делается во время компиляции, оно запускается только на вашем компьютере, а если что-то выполняется во время выполнения, оно запускается на вашем компьютере пользователя.
Актуальность
Примером того, где это важно, был бы тип, несущий единицу. Версия во время компиляции (например, Boost.Units или моя версия в D ) оказывается такой же быстрой, как решение проблемы с собственным кодом с плавающей запятой, в то время как версия времени выполнения вынуждена собирать информацию о единицах измерения, в которых находятся значения. и выполнять проверки в них вдоль каждой операции. С другой стороны, версии времени компиляции требуют, чтобы единицы значений были известны во время компиляции, и не могут иметь дело со случаем, когда они поступают из ввода во время выполнения.
Узнайте больше обо всех ошибках программирования здесь
В качестве дополнения к другим ответам, вот как я объясню это неспециалисту:
Ваш исходный код похож на план корабля. Это определяет, как корабль должен быть сделан.
Если вы передадите свой проект на верфь и обнаружите дефект при строительстве корабля, они прекратят его строительство и немедленно сообщат вам об этом, прежде чем корабль покинет сухой док или коснется воды. Это ошибка во время компиляции. Корабль даже не плавал и не использовал свои двигатели. Ошибка была найдена, потому что это препятствовало тому, чтобы судно было даже сделано.
Когда ваш код компилируется, это похоже на завершение корабля. Построен и готов к работе. Когда вы выполняете свой код, это все равно что запускать корабль в путешествие. Пассажиры садятся, двигатели работают, а корпус находится на воде, так что это время выполнения. Если у вашего корабля есть фатальный недостаток, который потопил его во время первого рейса (или, может быть, какой-то рейс после дополнительных головных болей), то он потерпел ошибку во время выполнения.
Например: в строго типизированном языке тип может быть проверен во время компиляции или во время выполнения. Во время компиляции это означает, что компилятор жалуется, если типы не совместимы. Во время выполнения это означает, что вы можете просто скомпилировать вашу программу, но во время выполнения она выдает исключение.
Просто разница слов ч / б время компиляции и время выполнения.
Вот цитата Даниэля Ляна, автора «Введение в программирование на JAVA», на тему компиляции:
Проще говоря: ошибка во время компиляции происходит во время этой фазы, а ошибка во время выполнения возникает позже.
Помните: только то, что программа скомпилирована без ошибок, не означает, что она будет работать без ошибок.
Ошибка времени выполнения будет возникать в части готовности, выполнения или ожидания в жизненном цикле программ, в то время как ошибка времени компиляции будет возникать до этапа «Новый» жизненного цикла.
Пример ошибки времени компиляции:
Пример ошибки во время выполнения:
И это разница между ошибкой во время компиляции и ошибкой во время выполнения
Время выполнения означает, что что-то происходит при запуске программы.
Время компиляции означает, что что-то происходит при компиляции программы.
Вещи, которые выполняются во время компиляции, не вызывают (почти) никаких затрат при запуске результирующей программы, но могут повлечь за собой большие затраты при сборке программы. Run-Time:
Более или менее полная противоположность. Меньше затрат при сборке, больше затрат при запуске программы.
С другой стороны; Если что-то делается во время компиляции, оно запускается только на вашем компьютере, а если что-то выполняется во время выполнения, оно запускается на вашем компьютере пользователя.
Время компиляции: Время, необходимое для преобразования исходного кода в машинный код, чтобы он стал исполняемым, называется временем компиляции.
Время выполнения: когда приложение работает, оно называется временем выполнения.
Представьте, что вы босс, у вас есть помощник и служанка, и вы даете им список задач, которые нужно выполнить, помощник (время компиляции) возьмет этот список и проверит, понятны ли эти задачи, и что вы не писал ни на каком неловком языке или синтаксисе, поэтому он понимает, что вы хотите назначить кого-то на работу, поэтому он назначает его для вас, и он понимает, что вы хотите немного кофе, поэтому его роль закончена и служанка (время выполнения) начинает выполнять эти задачи, поэтому она идет, чтобы приготовить вам кофе, но внезапно она не находит кофе для приготовления, поэтому она перестает делать его или она действует по-другому и делает вам чай (когда программа действует по-другому, потому что он обнаружил ошибку ).
Производительность продукта во время выполнения повышает его качество за счет более быстрого предоставления результатов. Производительность продукта во время компиляции способствует его своевременности, сокращая цикл edit-compile-debug. Однако как производительность во время выполнения, так и производительность во время компиляции являются вторичными факторами в достижении своевременного качества. Следовательно, следует учитывать улучшения производительности во время выполнения и во время компиляции, только если это оправдано улучшением общего качества и своевременности продукта.
Отличный источник для дальнейшего чтения здесь :
Я всегда думал об этом как о накладных расходах на обработку программ и о том, как это влияет на предварительную производительность, как было сказано ранее. Простым примером будет либо определение абсолютной памяти, необходимой для моего объекта в коде, либо нет.
Определенное логическое значение занимает х памяти, оно находится в скомпилированной программе и не может быть изменено. Когда программа запускается, она точно знает, сколько памяти выделить для х.
С другой стороны, если я просто определяю общий тип объекта (т. Е. Вид неопределенного заполнителя или, возможно, указатель на какой-то гигантский BLOB-объект), фактическая память, необходимая для моего объекта, неизвестна до тех пор, пока программа не будет запущена, и я не назначу ей что-либо таким образом, он затем должен быть оценен, а распределение памяти и т. д. будет динамически обрабатываться во время выполнения (больше накладных расходов во время выполнения).
То, как он обрабатывается динамически, зависит от языка, компилятора, ОС, вашего кода и т. Д.
Однако на этом замечании это действительно зависит от контекста, в котором вы используете время выполнения и время компиляции.
мы можем классифицировать их по двум различным группам: статическое и динамическое. Он основан на том, когда привязка выполняется с соответствующими значениями. Если ссылки разрешаются во время компиляции, то это статическая привязка, а если ссылки разрешаются во время выполнения, то это динамическая привязка. Статическое связывание и динамическое связывание также называют ранним связыванием и поздним связыванием. Иногда их также называют статическим полиморфизмом и динамическим полиморфизмом.
Основное различие между временем выполнения и временем компиляции:
int a = 1 int b = a/0;
вот очень простой ответ:
Скомпилированная программа может быть открыта и запущена пользователем. Когда приложение работает, оно называется временем выполнения.
Если исходный код программы уже был скомпилирован в исполняемую программу, у него могут все еще быть ошибки, которые возникают во время работы программы. Примеры включают функции, которые не работают, неожиданное поведение программы или сбои программы. Эти типы проблем называются ошибками во время выполнения, поскольку они возникают во время выполнения.
ИМХО, вам нужно прочитать много ссылок, ресурсов, чтобы составить представление о разнице между временем выполнения и временем компиляции, потому что это очень сложная тема. У меня есть список ниже некоторых из этих фотографий / ссылок, которые я рекомендую.
Помимо сказанного выше, хочу добавить, что иногда картинка стоит 1000 слов:
CLR_diag время компиляции и затем runtime2 
Время выполнения, время выполнения или время выполнения может относиться к:
Выполнение программного обеспечения, процесс выполнения инструкций одна за другой во время фазы выполнения
Список компиляторов https://en.wikipedia.org/wiki/List_of_compilers
;
3.2 разница между этими 3 вещами: компиляция против сборки против времени выполнения
https://www.quora.com/What-is-the-difference-between-build-run-and-compile Фернандо Падоан, разработчик, которому немного любопытно на языковой дизайн Ответил 23 февраля Я возвращаюсь в отношениях на другие ответы:
Посмотрите на этот пример:
Приведенный выше код успешно скомпилирован, синтаксической ошибки нет, он совершенно корректен. Но во время выполнения выдает следующую ошибку.
Например, когда во время компиляции проверяются определенные случаи, после этого времени выполнения проверяются определенные случаи, когда программа удовлетворяет всем условиям, которые вы получите на выходе. В противном случае вы получите ошибку времени компиляции или выполнения.
открытый класс RuntimeVsCompileTime <
Вы можете понять структуру компиляции кода, прочитав реальный код. Структура времени выполнения не ясна, если вы не понимаете шаблон, который был использован.
Это не очень хороший вопрос для SO (это не конкретный вопрос программирования), но в целом это неплохой вопрос.
И проблемное пространство вокруг времени компиляции и выполнения огромно и все еще в значительной степени не изучено. Это не значит, что SO является подходящим местом для обсуждения, но я призываю людей исследовать эту территорию дальше, особенно тех, у кого нет предвзятых представлений о том, что это должно быть. Вопрос не простой и не глупый, и мы могли бы, по крайней мере, указать инквизитору в правильном направлении.
К сожалению, я не знаю хороших ссылок на это. CLTL2 немного говорит об этом, но это не очень хорошо для изучения.