System c что это

Функция system

Функция выполняет заданную, через параметр syscom , системную команду. На самом деле, функция не сама выполняет команду, она вызывает командный процессор для выполнения команд. После выполнения команды, командный процессор возвращает управление программе, возвращая целочисленное значение, интерпретация которого зависит от системы.

Эта функция может принимать в качестве аргумента нулевой указатель — NULL , для проверки существования командного процессора.

Параметры:

• syscom
  Си-строка содержащая системную команду для выполнения.

Возвращаемое значение

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

Пример: исходный код программы

Пример работы программы

Тестировал программу в Линуксе, очень похожий вывод покажет программа и в ОС Windows. программа показала, что командный процессор готов к выполнению команды системной dir , команда выполнилась и мы на экране увидели список файлов в текущей директории, файлы разделены пробелом.

Классы и пространства имен

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

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

Отличие базовых классов .NET заключается в том, что они спроектированы интуитивно понятными и простыми в использовании. Например, для запуска потока необходимо вызвать метод Start() класса Thread. Чтобы сделать недоступным объект TextBox, свойству Enabled этого объекта присваивается значение false. Такой подход, хорошо знакомый разработчикам Visual Basic и Java, чьи библиотеки использовать столь же легко, принесет огромное облегчение разработчикам С++, которым в течение многих лет приходилось «воевать» с такими API-функциями, как GetDIBits(), RegisterWndClassEx() и IsEqualIID(), а также с множеством функций, которые требовали передачи дескрипторов окон.

Однако разработчики на С++ всегда имели легкий доступ к полному набору Windows API, в то время как разработчики на Visual Basic 6 и Java были ограничены в использовании базовой функциональности операционной системы, доступ к которой они получали из своих языков. Что касается базовых классов .NET, то они комбинируют простоту использования, присущую библиотекам Visual Basic и Java, с относительно полным покрытием набора функций Windows API. Многие средства Windows не доступны через базовые классы, и в этих случаях придется обращаться к API-функциям, но, в общем, это касается лишь наиболее экзотических функций. Для каждодневного применения набора базовых классов, в основном, будет достаточно. Но если понадобится вызвать API-функцию, то для этого .NET предоставляет так называемый механизм вызова платформы (platform-invoke), гарантирующий корректное преобразование типов данных, поэтому теперь эта задача не труднее, чем вызов этих функций непосредственно из кода С++, причем независимо от того, на каком языке пишется код — C#, С++ или Visual Basic 2010.

Пространства имен

— это способ, благодаря которому .NET избегает конфликтов имен между классами. Они предназначены для того, чтобы исключить ситуации, когда вы определяете класс, представляющий заказчика, называете его Customer, а после этого кто-то другой делает то же самое (подобный сценарий достаточно распространен).

Пространство имен — это не более чем группа типов данных, но дающая тот эффект, что имена всех типов данных в пределах пространства имен автоматически снабжаются префиксом — названием пространства имен. Пространства имен можно вкладывать друг в друга. Например, большинство базовых классов .NET общего назначения находятся в пространстве имен System. Базовый класс Array относится к этому пространству, поэтому его полное имя — System.Array.

Платформа .NET требует, чтобы все имена были объявлены в пределах пространства имен; например, вы можете поместить свой класс MyClass в пространство имен MyCompany. Тогда полное имя этого класса будет выглядеть как MyCompany.MyClass.

Запомните, что если пространство имен не указано явно, тип будет добавлен к безымянному глобальному пространству имен.

В большинстве ситуаций Microsoft рекомендует применять хотя бы два вложенных пространства имен: первое — наименование вашей компании, а второе — название технологии или пакета программного обеспечения, к которому относится класс, чтобы это выглядело примерно так: MyCompany.SomeNamespace.MyClass. В большинстве случаев такой подход защитит классы вашего приложения от возможных конфликтов с именами классов, написанных разработчиками из других компаний.

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

Роль корневого пространства Microsoft

При изучении перечня, приведенного в таблице, нетрудно было заметить, что пространство имен System является корневым для приличного количества вложенных пространств имен (таких как System.IO, System.Data и т.д.). Как оказывается, однако, помимо System в библиотеке базовых классов предлагается еще и ряд других корневых пространств имен наивысшего уровня, наиболее полезным из которых является пространство имен Microsoft.

В любом пространстве имен, которое находится внутри пространства имен Microsoft (как, например, Microsoft. CSharp, Microsoft. ManagementConsole и Microsoft .Win32), содержатся типы, применяемые для взаимодействия исключительно с теми службами, которые свойственны только лишь операционной системе Windows. Из-за этого не следует предполагать, что данные типы могут с тем же успехом применяться и в других поддерживающих .NET операционных системах вроде МаcOS X.

Разработка цифровой аппаратуры на C++/SystemC глазами SystemVerilog программиста

SystemC это библиотека для C++ позволяющая моделировать всевозможные аппаратные системы на различном уровне абстракции. Поддерживается как традиционное дискретно-событийное моделирование, привычное программистам на Verilog и VHDL, так и аналоговое моделирование в духе SPICE/Verilog AMS. В комплект также входит библиотека и методология для виртуального прототипирования, библиотеки для написания тестовых окружений и верификации с использованием рандомизированных тестов.

В этой я расскажу о синтезируемом подмножестве SystemC, сравнивая его с синтезируемым SystemVerilog. Сам я пользуюсь SystemC уже где-то 3 года, а до этого несколько лет писал на Verilog/SystemVerilog. Попытаюсь охватить предмет с разных сторон: начиная с философских рассуждений о причинах возникновения SystemC, краткого обзора экосистемы и инструментария и заканчивая практическими примерами синтаксиса и семантики.

Подразумевается, что читатели знакомы с Verilog и C++.

Размышления о причинах возникновения SystemC

За свою длинную историю индустрия разработки электроники нашла применение множеству языков программирования и породила огромное количество DSLей (Domain-specific languages). Если представить себе гипотетического full-stack аппаратчика (по аналогии с full-stack веб-программистом), который в одиночку может спроектировать современную микросхему, от алгоритма до реализации в кремнии, то ему помимо знания матчасти (арихитектура эвм, электроника, алгоритмы из прикладной области и др.) придется владеть целой кучей разнообразных языков: Matlab для разработки алгоритмов, Verilog или VHDL для описания RTL модели, SystemVerilog/E/Vera для написания тестов и тестового окружения, TCL для написания скриптов управляющих САПР пакетами, SPICE/Verilog-AMS для моделирования аналоговых подсистем, SKILL или Python для генерации топологий, Си/Asm для написания всевозможного firmware. При желании список можно продолжать и дальше.

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

В мире цифровой микроэлектроники таким универсальным языком стал SystemVerilog, который помимо классического Verilog (с небольшими расширениями), содержит в себе объектно-ориентированный язык для написания тестовых окружений, язык утверждений (assertions) для формальной верификации а так же специальные конструкции для рандомизации и анализа тестового покрытия. В каком-то смысле SystemVerilog это не совсем новый язык, а скорее конгломерат языков, склеенный общим синтаксисом.

Но что если мы хотим большего? Язык на котором помимо всего вышеперечисленного можно разрабатывать алгоритмы, писать встроенное ПО, создавать виртуальные прототипы. Не пора ли добавить к SystemVerilog еще пару DSL?

We need to go deeper

Существует однако и другой подход: вместо придумывания всё новых DSLей, можно создавать программные библиотеки, предназначенные для решения специального класса задач. Таким путём пошли создатели SystemC — библиотеки для C++, позволяющей моделировать цифровую аппаратуру. Хотя в каком-то смысле SystemC является DLS’ем, созданным средствами метапрограммирования на C++, сам C++ при этом не расширяется новыми синтаксическими конструкциями. Метапрограммирование широко применяется и в других C++ библиотеках.

У такого подхода существуют свои плюсы и минусы. Основной плюс C++ в его универсальности: сегодня ты можешь писать хардвер на SystemC, а завтра GUI на Qt. (Хотя придется потратить достаточно много времени на изучение каждой из этих библиотек). Основной минус в синтаксисе: код на чистом DSL будет намного красивей, особенно если нужно сделать что-то простое (для простых модулей код на Verilog будет компактней и проще, чем аналогичный код на SystemC).

Помимо недостаточной универсальности у Verilog есть и другая проблема: он очень низкоуровневый. В каком-то смысле синтезируемый Verilog это макроассемблер для аппаратуры ( если ассемблер для аппаратуры это логическая схема). Новые конструкции, появившиеся в синтезируемом SystemVerilog не решают эту проблему низкоуровневости. Очень часто приходится прибегать к использованию всевозможных генераторов кода на Verilog, например скриптов на Python. Среди моих коллег популярной была идея вставлять код на Perl внутрь модулей на Verilog. Полученный таким путём гибрид назвали перлилогом. Думаю многие знакомы с Verilog-mode для emacs, который умеет генерировать Verilog код для соединения модулей.

По сравнению с SystemVerilog, синтезируемый SystemC позволяет гораздо больше. Да, вы можете писать синтезируемый код с классами! При решении сложных задач средства абстракции C++ позволяют писать более элегантный (простой и компактный) код.

Экосистема SystemC

Рассмотрим основные программные инструменты, с которыми приходится иметь дело разработчикам на SystemVerilog и SystemC.

Среда разработки

SystemVerilog:
Большинство программистов на Verilog для написания кода используют текстовый редактор: поддержка Verilog есть в Vim, Emacs, Sublime Text, Notepad++, Slickedit и других популярных редакторах. Прикладным программистам написание кода в тестовом редакторе может показаться архаизмом: большинство из них используют умные IDE с авто-подсказками, автоматизированными рефакторингами, удобной навигацией. Однако в мире синтезируемого Verilog огромной пользы от использования IDE нет: это объясняется тем что вся функциональность разбивается на совершенно независимые друг от друга модули. Весь контекст с которым работает разработчик отдельного модуля обычно умещается в один файл. Совсем другое дело с написанием тестбенчей на SystemVerilog, здесь вполне может пригодится IDE, такая как DVT.

SystemC:
При написании синтезируемого C++/SystemC простым текстовым редактором уже не обойтись. К счастью, существует множество C++ IDE (в том числе и бесплатных), которые в состоянии справиться с кодом на SystemC. Например, можно использовать привычную многим MS Visual Studio. Я долгое время пользовался Eclipse CDT и Netbeans для написания кода на C++/SystemC. Последнее время пробую Clion от Jetbrains.
Написание SystemC кода в Clion

Симуляция и отладка

SystemVerilog:
Для симуляции и отладки кода на Verilog используется HDL симулятор. Существуют как бесплатные (IcarusVerilog), так и платные симуляторы. По сравнению с бесплатным симулятором коммерческие решения обеспечивают большую скорость симуляции и предоставляют удобные графические среды для отладки.

SystemC:
C SystemC ситуация в целом похожа: можно использовать референсный симулятор и GDB для отладки, но когда нужно отлаживать какой-то более-менее сложный сигнальный протокол приходится пользоваться одним из коммерческих симуляторов.

Отладка SystemC в симуляторе

Синтез

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

SystemC:
Для синтеза SystemC используются специальные пакеты высокоуровневого синтеза (англ. High-level Synthesis, HLS). Что в них такого высокоуровневого спросите вы? Всё дело в том, что HLS пакеты, помимо традиционного RTL кода написанного на SystemC умеют синтезировать и чисто поведенческий (“untimed”) код, автоматически вставляя регистры, там где это необходимо.

Большинство HLS пакетов могут синтезировать и чистый C/C++, SystemC используется только в тех случаях, когда нужно добавить модульность и сигнальные интерфейсы. В каком-то смысле синтез с C/C++ является технологией для разработки акселераторов, конкурирующей с синтезом с OpenCL. Хотя при использовании SystemC мы не ограничены только разработкой акселераторов, а можем разрабатывать совершенно любые цифровые схемы. Чуть позже я расскажу про HLS немного подробнее.

На выходе HLS пакета мы обычно имеем привычные RTL модули на Verilog, которые затем синтезируются с помощью Verilog синтезатора.

К сожалению, все существующие HLS с поддержкой SystemC исключительно коммерческие и стоят много денег. Бесплатных версий нет, хотя университетам всё продают с большой скидкой.
Лучшими средствами синтеза SystemC на рынке являются Stratus от Cadence и Catapult C от Calypto/Mentor Graphics.

Другие EDA пакеты для SystemC

Помимо написания синтезируемого кода, SystemC достаточно широко используется для виртуального прототипирования. Создание виртуальных прототипов (эмуляторов) на C++/SystemC используется в пакетах Synopsys Virtualizer, Mentor Graphics Vista, Cadence Virtual System Platform. При этом нельзя сказать что SystemC на этом рынке является доминирующим решением: существуют и продукты SystemC не использующие, например WindRiver Simics.

На этом обзорная часть статьи завершается. Пришло время погрузиться в код.

Погружение в код

Синтезируемый SystemC. Базовые строительные блоки

Типы данных

SystemVerilog:
Основным типом используемым в синтезируемом SystemVerilog является тип logic. Переменная типа logic может принимать 4 значения: 1, 0, x, z. x означает неизвестное значение. z означает высокоимпедансное состояние. Можно создавать вектора типа logic различной длины, например:
Выведет в консоль:3

SystemC:
В SystemC тоже есть типы с 4-мя состояниями. Однако на практике в основном используются типы с 2-мя состояниями 1 и 0. Основная причина — типы с 2-мя состояниями симулируются быстрее.

После синтеза все типы с 2-мя состояниями превращаются в logic. Это может привести к различиям в результатах симуляции SystemC (до синтеза) и Verilog (после синтеза). В SystemC не сброшенный регистр будет иметь значение 0, в Verilog — x. К счастью, синтезатор выдает предупреждение каждый раз когда видит регистр без сброса, поэтому на практике после чтения лога синтезатора проблем с расхождением результатов симуляции можно избежать.

Очень часто в коде на SystemC используются встроенные типы C++, такие как int или char. Если же нам требуется число с заданным количеством бит, можно использовать тип sc_uint:Выведет в консоль:3

Как реализован sc_uint? Это просто шаблонный класс в котором перегружены все основные операторы.

Модули

Рассмотрим пример пустого модуля на SystemVerilog и SystemC
SystemVerilog:

SystemC:
Разберем интересные строки подробнее:
модули в SystemC это производные классы от класса sc_moduleДля создания портов в SystemC используются специальные классы sc_in и sc_out.Конструкторам модуля и портов передаются строки содержащие их имя. Это нужно для того чтобы симуляционное ядро могло выдавать удобные для чтения логи, например:
Error: (E109) complete binding failed: port not bound: port ‘top.dout’ (sc_out)
Ошибка: порт dout модуля top никуда не подключен.
( Возможно, когда в C++ появится нормальная поддержка интроспекции объекты в SystemC смогут узнавать свои имена самостоятельно )
Для удобства создания модулей в SystemC определено несколько макросов. С их использованием аналогичный модуль выглядит следующим образом:

Переменные и присваивания

SystemVerilog:
Можно утверждать что все переменные в синтезируемом SystemVerilog- статические: они существуют с начала и до конца симуляции. И имеют глобальную область видимости (хотя доступ к сигналам “через крышу” по иерархическому имени не допускается в синтезируемом коде). Еще одной особенностью SystemVerilog является наличие нескольких операторов присваивания: блокирующего и неблокирующего присваивания в процедурных блоках, а так же непрерывного присваивания.
Блокирующее присваивание происходит либо сразу, либо блокирует исполнение текущего процесса до момента когда присваивание совершится.
Пример:Выведет в консоль:42
т.к. вызов функции $display произойдет лишь в момент времени 42, когда присваивание произойдет.
Неблокирующее присваивание откладывает присваивание на какой-то момент симуляционного времени в будущем и не блокирует исполнение процесса. Если время не указано явно, присваивание происходит на следующем дельта-цикле. Выведет в консоль: 0

SystemC:
Переменные в C++ ничего не знают про симуляционное ядро SystemC и поэтому ведут себя привычным для C++ программиста образом. Для того чтобы промоделировать неблокирующее присваивание в SystemC используется специальный тип sc_signal, переменные этого типа далее называются сигналами:Любое присваивание значения data будет неблокирующим.
Синтезируемый SystemC требует, чтобы взаимодействие между несколькими процессами происходило через сигналы. Аналогично, в Verilog хорошим стилем является использование исключительно неблокирующих присваиваний в always_ff процедурных блоках. В противном случае рискуем получить неопределенное поведение (состояние гонки), когда результат симуляции будет зависеть от порядка вызова процессов в одном дельта цикле.
Аналога блокирующего присваивания в SystemC нет.

Процессы (Процедурные блоки)

SystemVerilog :
Синтезируемый SystemVerilog поддерживает два основных типа процедурных блоков always_comb и always_ff. Помимо них есть еще always_latch, но использовать регистры-защелки на практике приходится довольно редко.
always_comb используется для описания комбинаторной логикиПроцесс будет исполняться каждый раз, когда изменяется значение b или c. То же самое можно было бы написать более явно, как в классическом Verilog:Помимо процедурного блока always_comb для описания комбинационных схем можно использовать оператор непрерывного присваивания:Процедурный блок always_ff используется для описания последовательностной логики, т.е. схем с памятью.Этот пример описывает двоичный счетчик с асинхронным сбросом.

SystemC:

Процессы в SystemC создаются в конструкторе модуля. Тело процессов описывается в функциях-членах модуля. Тип процесса похожего на always блок из Verilog в SystemC называется SC_METHOD.
Рассмотрим примеры процессов, аналогичные приведенным ранее процедурным блокам на SystemVerilog:
Комбинаторная логика:Последовательностная логика:Аналога непрерывного присваивания в SystemC нет. Так же как и нет возможности указать wildcard в списке чувствительности ( always@* в Verilog). Даже мощная шаблонная магия C++ не позволяет реализовать это средствами метапрограммирования.

Параметризация

Модули на SystemVerilog можно параметризовать. К примеру, можно написать параметризуемое FIFO, ширина и глубина которого будут указываться при создании экземпляра.

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

Промежуточные итоги

Хороший SystemC. Возможности синтезируемого SystemC, которых нет в SystemVerilog

Пользовательские типы данных

SC_CTHREADS (clocked threads). Процессы с неявным состоянием

Синтезируемые процессы в Verilog не могут использовать выражения для управления временем и ожидания событий. Т.е. запущенный процесс должен исполниться до конца и только потом передать управление другому процессу. К примеру, данный процесс не синтезируется:В Verilog мы должны явно специфицировать регистр состояния, который будет определять поведение процесса на каждом такте. Синтезируемым аналогом предыдущего примера кода будет следующий процесс:В SystemC синтезируемые процессы описывающие последовательностную логику (цифровой автомат) могут останавливаться на ожидании события от тактового сигнала. Это позволяет описывать автомат без явной спецификации регистра состояния. Процессы такого типа создаются с помощью макроса SC_CTHREAD. Остановка процесса до следующего тактового сигнала осуществляется путём вызова функции wait(); Пример:На первый взгляд польза от наличия таких процессов не очевидна. В конце концов не так уж и сложно явно закодировать переменную для состояния цифрового автомата (переменная state в примере на Verilog).
Истинная мощь SC_CTHREAD процессов заключается в возможности вызова функций, которые могут заблокировать процесс, т.е. вызывать функцию wait(). Такая функция может исполняться несколько тактов! Аналогом из мира Verilog являются task’и, они однако не синтезируются и используются только в тестах.
Например:Ещё больше пользы от функций, исполнение которых иногда занимает несколько тактов, а иногда происходит мгновенно, без вызова wait().
Для примера рассмотрим процесс, который читает данные из FIFO, обрабатывает их, после чего отправляет результат в память по системной шине (например, AMBA AXI). Пускай данными будет 3-х мерный вектор рассмотренный раннее, а обработка будет заключаться в нормализации этого вектора. С использованием SC_CTHREAD и готовых классов для работы с FIFO и AXI написать такой процесс очень просто:Предположим что нормализация вектора реализована в виде комбинационной схемы. Тогда, в зависимости от готовности FIFO и шины, исполнение одного цикла такого процесса может занимать от одного такта и более. Если в FIFO есть данные и шина не занята, то нормализация одного вектора будет происходить за такт. Если FIFO пустое, то процесс заблокируется на функции чтения из FIFO data_fifo.pop до момента поступления новых данных. Если шина занята, то процесс заблокируется на функции bus_master.write до момента когда шина освободится.

• Если мы никуда не торопимся, то можно сэкономить на ресурсах и реализовать нормализацию в виде FSMD с одним умножителем, сумматором, делителем и модулем извлечения квадратного корня. В этом случае мы потратим 6 тактов на вычисление длины вектора и еще 3 такта для вычисления значения каждого из элементов результата, в сумме — 9 тактов на один вектор.
  
• Если мы сильно торопимся, а ресурсов не жалко, оригинальную комбинационную схему можно превратить в конвейер. В этом случае в пике (когда в FIFO постоянно есть данные) мы получим тот же 1 такт на вектор, но уже на большей тактовой частоте.
  
• Так же возможны любые промежуточные между первым и вторым варианты. К примеру, если логика дорогая а регистры дешевые, то в первом рассмотренном варианте микроархитектуры можно начинать обработку следующего вектора не дожидаясь завершения выполнения предыдущего, по мере освобождения ресурсов. После вычисления трех квадратов элементов первого вектора, умножитель освобождается и можно начинать обработку следующего вектора. Такая реализация называется конвейером с интервалом инициализации в 3 такта. Т.е. каждые три такта конвейер будет забирать из FIFO новый вектор.

Высокоуровневый синтез.

• Исходный код. Иногда его называют untimed code, т.к. он не содержит конструкций для остановки процесса, таких как функция wait
• Timing constraints. Временные ограничения. Задают список тактовых сигналов и их период, а так же задержки на внешних портах
• Спецификация микроархитектуры. В качестве микроархитектуры мы можем выбрать любой из рассмотренных ранее вариантов

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

Заключение

В качестве заключения хочу попробовать ответить на вопрос который часто задают RTL разработчики увидев новый тул: А что с качеством результата? Как будут отличаться тайминги, площадь, энергопотребление схем описанных на SystemC и синтезированных с помощью HLS в сравнении с RTL описанным на SystemVerilog?

На самом деле никак. Всё в ваших руках: SystemC и HLS не лишают вас возможности затюнить всё с точностью до гейта там где это требуется. И в то же время HLS не освобождает вас от необходимости понимать основы цифровой схемотехники. HLS это не магическое средство, превращающее C++ программиста в аппаратчика, это средство позволяющее автоматизировать рутинную работу, облегчающее процесс написания и поддержки синтезируемого кода.

В этой статье я никак не коснулся вопроса верификации. Верификация всегда занимает большую часть времени разработки и SystemC есть что предложить на этом поприще. Хорошо написанный SystemC стимулируется быстрее чем RTL, т.к. часть кода написана в “untimed стиле”, а сигнальные интерфейсы можно заменить на вызовы функций (Transaction-level modeling). Библиотека SCV (SystemC Verification Library) позволяет рандомизировать тестовые вектора, так же на подходе SystemC версия UVM. А т.к. SystemC это C++, то части исходного кода можно переиспользовать между синтезируемым кодом, референсной моделью, виртуальным прототипом и драйвером операционной системы. Но рассказ обо всём этом достоин отдельной статьи.

Функция system() в C++

В этой статье будет продемонстрировано несколько способов использования библиотечной функции system() в C++.

Please enable JavaScript

Используйте функцию system() в C++ для выполнения команды оболочки

Функция system() некоторое время была частью стандартной библиотеки C и может быть включена в код C++ без дополнительных библиотек. Функция используется для выполнения команды оболочки из вызывающего процесса. Обратите внимание, что system создается для особых случаев использования, когда вызывающей программе необходимо создать единственный дочерний процесс и немедленно начать ожидание его завершения. Таким образом, сама функция реализована с помощью нескольких системных вызовов, которые доступны как часть системного интерфейса.

Если предположить среду UNIX, пользователю не нужно иметь дело непосредственно с функциями fork , exec и wait , которые управляют созданием / очисткой нового процесса. Следующий пример демонстрирует простейший вариант использования функции system , которая запускает утилиту командной строки ls для печати файлов в текущем рабочем каталоге.

Функция system() обычно создает два процесса для выполнения одной команды. А именно, он создает оболочку с одним вызовом exec и еще одним для данной команды, которую оболочка будет выполнять. Это отрицательно влияет на производительность по сравнению с прямым использованием базовых системных вызовов. Обратите внимание, что если мы запустим команду top с system , программа будет ждать, пока пользователь выйдет из top вручную, что вернется в вызывающий процесс и заставит его перейти к оператору return , как показано в следующий пример.

Используйте system(nullptr) , чтобы проверить, доступна ли оболочка в системе

Функция system() принимает в качестве аргумента односимвольную строку, которая является командой, которую необходимо запустить из оболочки. Если мы передаем ему nullptr или NULL , ненулевое значение возвращается, когда программа оболочки доступна в системе, или если возвращается ноль, это означает, что оболочка недоступна.

Используйте макрос wstatus для проверки статуса выполненной команды

Если системный вызов не может создать дочерний процесс, он возвращает -1 и соответственно устанавливает errno . Если вызов функции успешен, возвращаемое значение — это код состояния завершения оболочки, которая выполнила данную команду. Кроме того, этот код состояния завершения совпадает с кодом выхода последней выполненной команды. Таким образом, можно проверить его значение с помощью макроса wstatus , описанного в системном вызове wait страница руководства. Следующий фрагмент кода реализует функцию printWaitStatus для проверки system возвращаемого значения и вывода сведений о последней выполненной команде.