Что такое время компиляции

Время компиляции (фаза жизненного цикла программы)

Компиляция программы может осуществляться компилятором как по команде от пользователя, так и по команде от среды разработки при изменении исходного кода программы, в отличие от других этапов жизненного цикла (англ. program lifecycle phase) программы, таких как время выполнения, время установления связей («линковки») (англ. link time) и время загрузки (англ. load time).

Связанные понятия

Сопрограммы (англ. coroutines) — методика связи программных модулей друг с другом по принципу кооперативной многозадачности: модуль приостанавливается в определённой точке, сохраняя полное состояние (включая стек вызовов и счётчик команд), и передаёт управление другому. Тот, в свою очередь, выполняет задачу и передаёт управление обратно, сохраняя свои стек и счётчик.

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

В теории компиляторов удалением мёртвого кода (англ. dead code elimination, DCE) называется оптимизация, удаляющая мёртвый код. Мёртвым кодом (так же бесполезным кодом) называют код, исполнение которого не влияет на вывод программы, все результаты вычисления такого кода являются мёртвыми переменными, то есть переменными, значения которых в дальнейшем в программе не используются.

Источник

Время компиляции

Время компиляции / раннее связывание против времени выполнения [ править ]

Обзор [ править ]

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

Свойства программы, о которых можно рассуждать во время компиляции, включают проверки диапазона (например, доказательство того, что индекс массива не выходит за границы массива), свободу тупиковых ситуаций в параллельных языках или тайминги (например, доказательство того, что последовательность кода принимает не более выделенного количества времени).

Время компиляции происходит до того времени связи (когда выход одного или несколько файлов скомпилированных соединены вместе) и выполнения (когда программа будет выполнена ). В некоторых языках программирования может потребоваться некоторая компиляция и компоновка во время выполнения. Существует компромисс между временем компиляции и временем компоновки, поскольку многие операции времени компиляции можно отложить до времени компоновки без дополнительных затрат времени выполнения.

«Время компиляции» также может относиться к количеству времени, необходимого для компиляции.

См. Также [ править ]

Источник

Что такое функция времени компиляции в C ++?

Я искал этот вопрос здесь (на SO), и, насколько я знаю, все вопросы предполагают, что такое функции времени компиляции, но для новичка почти невозможно понять, что это значит, потому что ресурсы, чтобы знать, что это довольно редко.

Я нашел короткую статью в Википедии, в которой показано, как писать непонятный код, написав никогда не виданный ранее использование перечислений в C ++ и видео о его будущем, но объясняет очень мало об этом.

Мне кажется, что есть два способа написать функцию времени компиляции в C ++

Я прошел через краткое введение их обоих, но я понятия не имею, как они появляются здесь.

Может ли кто-нибудь объяснить функцию времени компиляции с достаточно хорошим примером, чтобы она охватывала большинство его функций?

2 ответа

Сказав все это, давайте посмотрим на функцию времени компиляции max :

Шаблоны действительно могут использоваться для вычисления произвольных вещей, набора методов, называемых «шаблонное метапрограммирование». Это в основном случайно, поскольку они вообще не были предназначены для этой цели, отсюда и сумасшедший синтаксис и борьба со старыми компиляторами. Но в C ++ 03 и раньше это все, что у нас было.

constexpr был добавлен в C ++ 11 после того, как увидел необходимость вычислений во время компиляции, и возвращает их на несколько более разумную территорию. С тех пор его набор инструментов расширяется, позволяя запускать все больше и больше нормально выглядящего кода во время компиляции, просто вставив constexpr в нужное место.

Источник

Время выполнения против времени компиляции

В чем разница между временем выполнения и временем компиляции?

Время компиляции

Время выполнения

Что может пойти не так, это ошибки времени выполнения :

Также могут быть ошибки, которые обнаруживает сама программа:

Я думаю об этом с точки зрения ошибок, и когда они могут быть обнаружены.

Строковому значению нельзя присвоить переменную типа 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 немного говорит об этом, но это не очень хорошо для изучения.

Источник

Аннотации времени компиляции на примере @Implement

Все мы любим отлавливать ошибки на этапе компиляции, вместо исключений времени выполнения. Их устранить проще всего, компилятор сам показывает все места, нуждающиеся в исправлении. Хотя большинство проблем можно обнаружить только при запуске программы, все же мы стараемся сделать это как можно раньше. В блоках инициализации классов, в конструкторах объектов, при первом вызове метода и т.д. И иногда нам везет, и даже на этапе компиляции известно достаточно, чтобы проверить программу на наличие определенных ошибок.

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

Я опишу общий алгоритм проверки, а также все шаги и нюансы на которые я тратил время и нервные клетки.

Постановка задачи

В этом разделе я приведу пример использования этой аннотации. Если Вы уже знаете какую проверку хотите сделать можете смело его пропускать. Уверен, это никак не повлияет на полноту изложения.

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

Допустим, есть класс UnitManager, который, по сути, является коллекцией юнитов. В нем есть методы для добавления, удаления, получения юнита и т.д. При добавлении нового юнита менеджер присваивает ему id. Генерация id делегирована классу RotateCounter, который, возвращает число в заданном диапазоне. И тут есть крошечная проблема, RotateCounter не может знать о том, свободен ли выбранный id. Согласно принципу инвертирования зависимостей, можно создать интерфейс, в моем случае это RotateCounter.IClient, у которого есть единственный метод isValueFree(), который получает id и возвращает true, если id свободен. А UnitManager реализует этот интерфейс, создаст экземпляр RotateCounter и передаст ему себя в качестве клиента.

Я так и сделал. Но, открыв исходник UnitManagerа через несколько дней после написания, я вошел в легкий ступор увидев метод isValueFree(), который не очень то подходил по логике для UnitManagerа. Было бы намного проще, если бы была возможность указать какой интерфейс реализует этот метод. Например, в языке C#, из которого я пришел в Java, с этой проблемой помогает справиться явная реализация интерфейса. В этом случае, во-первых, вызвать метод можно только при явном касте к интерфейсу. Во-вторых, что более важно в данном случае, в сигнатуре метода явно указывается имя интерфейса (и без модификатора доступа), например:

Немного теории

Обработкой элементов на этапе компиляции занимаются специальные классы-процессоры. Это классы которые наследуются от javax.annotation.processing.AbstractProcessor (можно просто реализовать интерфейс javax.annotation.processing.Processor ). Больше про процессоры можно прочитать здесь и здесь. Самый важные метод в нем process. В котором мы можем получить список всех аннотированных элементов и провести необходимые проверки.

Сначала, по наивности душевной, я думал, что работа с типами на этапе компиляции осуществляется в терминах рефлексии, но… нет. Там все основано на элементах.

Element (javax.lang.model.element.Element) — основной интерфейс для работы большинством структурных элементов языка. У элемента есть наследники, которые точнее определяют свойства конкретного элемента (за подробностями можно заглянуть сюда):

Types (javax.lang.model.util.Types) — к этому классу советую присмотреться повнимательнее. Там можно найти много интересного. По сути, это набор утилит для работы с типами. Например, он позволяет получить обратно TypeElement из TypeMirror.

TypeKind (javax.lang.model.type.TypeKind) — перечисление, позволяет уточнить информацию о типе, проверить является ли тип массивом (ARRAY), пользовательским типом (DECLARED), переменной типа (TYPEVAR) и т.д. Получить можно через TypeMirror.getKind()

ElementKind (javax.lang.model.element.ElementKind) — перечисление, поваляет уточнить информацию об элементе, проверить является ли элемент пакетом (PACKAGE), классом (CLASS), методом(METHOD), интерфейсом(INTERFACE) и т.д.

В основном, этих типов мне было достаточно для написания алгоритма проверки.

Алгоритм проверки

Дальше начинается самое интересное — создание процессора. В методе process получаем список всех аннотированных элементов. За тем получаем саму аннотацию и ее значение — указанный интерфейс. В общем, каркас класса-процессора выглядит так:

Хочу заметить, что нельзя просто так взять и получить value аннотации. При попытке вызвать annotation.value() будет брошено исключение MirroredTypeException, а вот из него можно получить TypeMirror. Этот читерский способ, а также правильное получение value я нашел тут:

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

Первым делом нужно проверить, является ли value аннотации интерфейсом. Тут все просто:

Вызов нужно поместить в конец цикла в методе process, вот так:

А сам метод haveMethod() выглядит следующим образом:

Видите проблему? Нет? А она там есть. Дело в том, что я так и не смог найти способ получить фактические параметры типов для обобщенных интерфейсов. Например, у меня есть класс, который реализует интерфейс Predicate:

Подключение к Eclipse

Все вместе и в Eclipse-проекте можно увидеть на GitHub. На момент написания статьи там всего два класса, если аннотацию можно так назвать: Implement.java и ImplementProcessor.java. Думаю, об их назначении вы уже догадались.

PS. Благодарю пользователей ohotNik_alex и Comdiv за помощь в исправлении ошибок.

Источник