Б. Страуструп - Дизайн и Эволюция C++. 2006 (1160775), страница 55
Текст из файла (страница 55)
9З.2.3. Встроенные системы В ряду областей системного программирования встроенные системы должны быть рассмотрены особо. Под встроенными системами понимаются программы, управляющие работой компьютеризованных устройств: видеокамер, автомобилей, ракет, телефонных коммутаторов и т.д. Думается, что важность таких систем со временем возрастет и применяться в них будет смесь низко- и высокоуровневого Всего лишь мост? МИИИИИИП системного программирования. В таком случае, С++ должен будет удовлетворять самым разнообразным требованиям, которые вряд лн сможет выполнить узкоспециализированный язык.
В олних проектах начнут интенсивно использова~ься исключения, в других они будут запрещены как слишком непрелсказуемые. Аналогично требования к управлению памятью будут варьироваться от чполного отсутствия динамической памяти» до чнеобходимости использовать автоматическую сборку мусора». Ко всему прочему, начнется интенсивное применение самых разных моделей параллельности. Важно, что С++ — это язык, а не законченная система. Это позволяет использовать его ~ри разработке специализированных систем и генерировать код для исполнения на специальном оборуловании.
Возможность запускать С++ в отдельных средах разработки и под управлением симуляторов на стандартной аппаратуре может оказаться для проекта существенной. Тот факт, что написанные на С++ программы допустимо помешать в постоянную память, в свое время тоже был важен. С использованием С++ для программирования разнообразных компьютеризованных устройств у меня связаны большие надежды.
В этой области могу~ быть востребованы сильные возможности С, поддерживаемые и в С++. 9.3.2.4. 4исленные и научные расчеты Численные и научные расчеты — сравнительно небольшая область программирования, в ней нс занято много специалистов, но опа очень ценна и интересна. Я наблюдаю смешение акцента в сторону развитых алгоритмов, для которых важна способность языка описывать и эффективно использовать разнообразныс структуры данных.
Гогсгап такой гибкостью не обладае~, но это компенсируется эффективностью при выполнении базовых операций над векторами. Важно, что С++-программа может вызывать подпрограммы, написанные на Гогсгап или ассемблере, там, где это необходимо или просто удобно. Интеграция численных программ в более крупные приложения прелъявляет требования, которым удовлетворяет С++. Например, преимушества Гогсгап в низкоуровневых вычислениях пс так существенны, когда основной упор делается на нечисленные аспекты: визуализацию, моделирование, доступ к базе данных и сбор данных в реальном времени. 9.3.25.
Общее прикладное программирование С++ не является идеальным инструментом для приложений, где не нужны развитые системные компоненты, а требования к быстродействию и потреблению памяти не слишком жесткие. Однако при поддержке со стороны библиотек и, возможно, сборщика мусора, он может найти применение и здесь. Я полагаю, что во многих полобных предметных областях преобладающими станут специализированные языки, генераторы программ и инструментальные средства для прямого манипулирования. Например, зачем набирать текст программы для создания пользовательского интерфейса, когда это может сделать автоматический генератор при подаче ему на вход примера размешения элементов на экране? Точно так же, зачем программировать сложные математические расчеты на Гогсгап или С++, если можно использовать специализированный язык более высокого уровня? Однако и высокоуровневый язык, и генератор интерфейсов нужно реализовывать на подходящем языке.
Самим генератором также зачастую ИИИИИИИВ Перспективы развития языка С++ создается код на другом языке, который уже и выполняет нужные действия. Требованиям к языку реализации и к целевому языку С++ удовлетворяет очень хорошо, так что я предвижу возрастание его роли в таких приложениях. Эту роль С++ наследует от С. Но такие детали, как возможность объявлять переменные почти повсеместно в сочетании со средствами организации программ (пространства имен), делают С++ даже более удобным в качестве целевого языка, чем С.
Высокоуровневые инструменты и языки тяготеют к специализации. Поэтому хорошие средства такого уровня должны предоставлять пользователям возможность расширения и модификации стандартного поведения путем добавления кода, написанного на языке более низкого уровня. Механизмы абстракции С++ позволяют легко интегрировать его в каркас, предоставляемый инструментальным средством высокого уровня. 93.2.6. Смешанные сипемы Самая существенная из сильных сторон С++ проистекает из его способности работать в системах, в которых сочетаются особенности приложений всех вышеупомянутых видов.
Для пользовательских интерфейсов нужна графика; специфические приложения требуют наличия специализированных языков и генераторов программ; симуляторам и аналитическим подсистемам необходимо выполнять сложные вычисления; в коммуникационных подсистемах широко применяется системное программирование; большие системы, как правило, нуждаются в базе данных; для работы со специальной аппаратурой требуется низкоуровневое программирование.
Во всех этих (и многих других) областях предпочтение будет отдано С++, если не в первую, то, по крайней мере, во вторую очередь. Но самым широкоиспользуемым он будет достаточно часто, для того чтобы считаться основным языком, Все языки либо перестают существовать сами собой, либо изменяются в соответствии с новыми требованиями.
Язык с многочисленным и энергичным сообществом пользователей, скорее, изменится, чем исчезнет. Это случилось с С, который уступил дорогу С++, и то же самое когда-нибудь произойдет с С++. С+«в относительно молодой язык, но все же стоит присмотреться к его сильным и слабым сторонам, чтобы задействовать первые и компенсировать последние. С++ не совершенен. Однако он достаточно хорош, так что замена аналогичным языком ему не грозит. Только принципиально иной язык мог бы предоставить по-настоящему серьезные преимущества, чтобы его стали считать безусловно лучшим. Быть просто «улучшенным С++« недостаточно, чтобы сменить его.
Вот почему С++ — это не просто улучшенный С. Если бы С++ не предлагал совершенно новые способы написания программ, то программисты не отказывались бы от С. Именно поэтому Разса1 и Мог1ц!а-2 потерпели неудачу как альтернативы С, хотя многие представители академических кругов рекламировали их в течение многих лет. Они просто не настолько сильно отличались от С, чтобы намного превзойти его.
Я не вижу принципиально отличного языка, который в ближайшем будущем мог бы заменить С++ в тех областях, где он применяется. Есть только языки, обладающие, по сути, теми же, хоть и иначе представленными возможностями, а также узкоспециализированные и экспериментальные языки. Что может сделать С++ более эффективным 4ифффффЩ 9.4. Что может сделать С++ более эффективным На протяжении многих лет ожидания опережали самые фантастические усовершенствования аппаратного и программного обеспечения, и в этом отношении вряд ли что-то изменится. Многое можно сделать, чтобы компилятор С++ стал еще полезнее пользователям, а программистам и проектировщикам есть чему поучиться, чтобы работать эффективнее. Выскажу нссколько замечаний о том, что, по моему мнению, следует прелпринять, чтобы программирование на С++ стало более продуктивным.
9.4.1. Стабильность и стандарты Стабильность определения, основных библиотек и интерфейсов занимает высокое место в списке требований к дальнейшему разалию языка. Псрвое должен обеспечить комитет по стандартизации АХБ1/190, второе — дело организаций и компаний, работающих над интерфейсами операционных систем, баз ланных, динамически подключаемыми библиотеками н т.д. Разумеется, пользователи, вправе требовать новых возможностей, но лично мне достаточно видеть С++ и таким, каким он представлен в этой книге. Думаю, что большинство программистов, пишущих промышленные коды, согласятся со мной.
Нс стоит забывать, что никакое средство, взятое в отдельности, пс является достаточным для создания «удачной программы» (что бы ни имелось в виду под этим словосочетанием). 9.4.2. Обучение и приемы Наибольший потенциал для улучшений языка я вижу в простом изучении новых приемов проекгирования и программирования. Самых простых н экономичных результатов можно было бы добиться просто за счет более эффективного использования С++. И не нужно никаких дорогостоящих инструментов.
С другой стороны, изменить образ мышления нелегко. Большинству программистов недостаточно просто выучить новый синтаксис, надо еше глубоко освоить новые концепции. Посмотрите, что написано в разделе 7.2 и в учебнике, где затрагиваются вопросы проектирования, например, в [2пд[ или [ВоосЬ, 19931. Я предчувствую, что в ближайшие несколько лет мы станем свидетелями значительного улучшения методов проектирования и программирования, но это все равно не дает нам права сидеть сложа руки и ждать. 9.4.3.
Системные вопросы С++ — язык, а не полная система. В большинстве случаев это достоинство, а для организации среды полного цикла разработки и тестирования суп1ествуют инструментальные средства. Но между языком и средой должен быть интерфейс. Его отсутствие привело к удручающе медленному развитию в области динамической загрузки. Пользователи либо ничего не предпринимали, полагаясь на механизмы, спроектированные для С++, либо работали над механизмами, достаточно общими для подлержки члюбых объектно-ориентированных языковы С точки зрения программиста на С++ результаты оказались довольно плачевными.
ИЙИИИИИ3~ Перспективы развития языка С++ Ранние эксперименты по интегрированию С++ и динамического связывания были настолько многообещающими, что я ожидал повсеместного распространения динамического связывания классов еше несколько лет назад. Например, еше в 1990 г. существовала работающая методика эффективного и безопасного инкрементного связывания, основанная на абстрактных типах [Ягоцз1гор, 1987Ц [Погщаго, 1990[.
В реальных системах она использовалась не очень широко, но абстрактныее классы оказались важны для уменьшения числа повторных компиляций после изменения исходного кода и вообще для упрощения использования компонентов, полученных из разных источников (см. раздел 13.2.2). Еше один важный вопрос, остающийся нерешенным, — поддержка эволюции программного обеспечения. Коль скоро библиотека выпущена в обращение, ее реализацию можно изменить только в том случае, если пользователи не зависят от таких деталей, как размер объекта, или могут и готовы перекомпилировать свой код с новой версией библиотеки. Объектные модели — ОЕЕ2 от М1сгозо(ц БОМ от 1ВМ и СОКВА от ОЬ)ест Мапайешеп1 Сгопр — решают эту проблему путем предоставления интерфейса, скрывающего детали реализации и задуманного независимым от конкретного языка.
Последнее вызывает у программиста на С++ некоторые неудобства и обычно сопровождается потерями программы скорости или памяти. Кроме того, у каждого из гигантов индустрии, похоже, есть свой собственный «стандарт» для решения описанной проблемы. Только время покажет, насколько эти методы помогают или мешают С++-программистам. Механизм пространств имен — подход к эволюции интерфейсов внутри самого С++ (см. раздел 17.4.4). С большой неохотой я вынужден признать, что некоторые системные проблемы стоило бы решать в самом С++. Вообще-то такие вопросы, как динамическое связывание классов и эволюция интерфейсов, логически не относятся к языку, и встраивание в язык средств для их решения нежелательно.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
