Б. Страуструп - Дизайн и Эволюция C++. 2006 (1160775), страница 56
Текст из файла (страница 56)
Но выработать по- настоящему стандартное решение можно только, работая с самим языком. Например, соглашения о вызове подпрограмм, написанных на Рогггап и С, стали стандартом де-факто. Так случилось потому, что С и Гогсгап популярны, а интерфейсы вызова просты и эффективны. Для принятия стандарта это минимальный набор условий. Мне не нравится такой вывод: из него следует, что на пути использования разных языков в системе стоит барьер, если только один из языков не предоставит механизма, который другими будет принят в качестве стандарта.
9.4.4. За пределами файлов и синтаксиса Как я вижу среду для разработки программ на С++? Прежде всего — инкрементная компиляция. Если вносится небольшое изменение, то система «понимает», что оно небольшое, и генерирует новую версию программы мгновенно. Моментальные ответы хотелось бы получать также на простые вопросы и указания типа: «Показать объявление г», «Какие еще Е есть в области действия?», «Как разрешен этот вызов оператора»?», «Какие классы произведены от Япаре?» и «Какие деструкторы вызываются в конце этого блока?» В программе на С++ есть много информации, которая в типичной среде доступна только компилятору. Уверен, что она должна быть предоставлена программисту. Что может сделать С++ более эффективным ~ЯфффЯЩ$ Однако люди в большинстве своем смотрят на С++-программу, как на набор исходных файлов или строк символов. Программа — это набор типов, функций, предложений и т.д.
Данные понятия представляются в виде символов в файлах только для удобства изображения в традиционных средах программирования. То, что в основе реализаций С++ лежат символьно-ориентированные шктрументы, всегда было главным препятствием на пути развития языка.
Если нужно препроцессировать и перекомпилировать каждый заголовочный файл, прямо нли косвенно включенный в файл, где находится слегка измененная функция, то для этого требовалось определенное, пусть и небольшое время. Сущесгвует несколько методов, позволяющих избежать ненужных перекомпиляций, но, по-моему, наиболее перспективный и интересный подход — отказаться от традиционного исходного текста и положить в основу инструментов абстрактное внутреннее представление. Ранний вариант такого представления можно найти в работах ~Мцггау, 1992), 1Коеп19, 19921. Естественно, ~скет все равно необходим — его вводят и читаю~ пользователи, — но он легко преобразуется системой во внутреннюю форму и реконструируется по запросу.
Форматирование текста с соблюдением некоторых правил отступа- лишь один из многих возможных взглядов на программу, Простейшее применение этого замечания: текст программы, который каждый нз пользователей видит отформатированным в своем любимом стиле, а вы — в вашем.
Нетекстовое представление могло бы быть создано языками более высокого уровня, генераторами программ, инструментами визуального программирования и т.д. Это позволило бы таким инструментам работать в обход обычного синтаксиса С++ и даже помогло бы избави~ь язык от некоторых неудачных особенностей его синтаксиса.
Я утверждаю, что система типов и семантика С++ чище, чем его синтаксис. Из представления о синтаксисе как об интерфейсе между языком и пользователем следует, что возможны и другие интерфейсы. Единственная фундаментальная константа — это базовая семантика языка. Она не должна меняться ни при каких обстоятельствах, и, учитывая это, вполне можно выдать С++-код в обычной текстовой форме по запросу. В среде, основанной на абстрактном представлении С++, можно было бы предоставлять альтернативные способы создания и просмотра программ, а равно и другие пути компоновки, компиляции и исполнения кода. Например, компоновка выполнялась бы до генерации кода, поскольку наличие объектного кода не являлось бы обязательным для доступа к информации о связях. Разчичне между интерпретатором и компилятором в значительной мере сгладилось бы, поскольку нх работа была бы основана на одной и той же информации примерно в одном н том же формате.
9.4.5. Подведение итогов и перспективы С++ представляет собой множество составляющих, и в этом его наиболее сильная сторона. Так же и развитие языка является следствием не одного какогото улучшения, а многих усовершенствований в самых разных областях (улучшенные библиотеки, более совершенные методы проектирования, наличие стандарта ИИИИИИИВ Перспективы развития языка С++ языка, необязательной сборки мусора, стандартов на передачу объектов, баз данных, нетекстовых сред разработки, более богатый набор инструментов, более быстрые компиляторы и т.д.). Думается, что пока мы работали лишь с наименьшей частью возможностей языка С+ч-. Я предвижу, что в будущем центр деятельности и развития сместится от собственно языка к инструментам, средам, библиотекам, приложениям и т.д., которые зависят от него и возводятся на его фундаменте.
Глава 10. Управление памятью Глава 11. Перегрузка Глава 12. Множественное наследование Глава 13. Уточнения понятия класса Глава 14. Приведение типов Глава 15. Шаблоны Глава 16. Обработка исключений Глава 17. Пространства имен Глава 18. Препроцессор С В части В описываются средства С++, появившиеся после выхода версии 1.0. Разбиение на главы основано на логических взаимосвязях между различными возможностями.
Хронология их включения в С++ для языка в целом не существенна и здесь не отражена. Порядок глав тоже не играет большой роли. Глава 10. Управление памятью Никакому гению не преодолеть прокпятия деталей. Анонимный овгор 10.1. Введение В С++ есть оператор петт для выделения памяти из кучи и оператор г1е1есе для освобождения выделенной памяти (см. раздел 2.11.2). Но иногда пользователю необходим более тщательный контроль над распределением и освобождением памяти. Важный частный случай — выделение памяти на уровне часто используемого класса [2пт(, стр.
1771. Многие программы создают и уничтожают болыцое число мелких объектов, принадлежащих несколъким важным классам, например узлы дерева или связанного списка, точки, линии, сообщения и т.д. На выделение и освобождение лама~и для таких объектов с помощью распределителя общего назначения может уходить почти все время работы программы, причем память будет использоваться неэффективно. Здесь играют роль два фактора: затраты по времени и памяти, присущие универсальному распределителю, и фрагментация свободной памяти из-за того, что в ней создаются объекты разных размеров. Я обнаружил, что применение специализированного распределителя, определенного на уровне класса, обычно позволяет вдвое увеличить скорость действия симулятора, компилятора или аналогичной программы по сравнению с применением стандартного алгоритма управления памятью.
Приходилось видеть и десятикратное ускорение в случаях, когда проблемы фрагментации были особенно острыми. Средства, включенные в версию 2.0, позволяют добавить в класс распределитель (написанный самостоятельно или взятый из стандартной библиотеки) всего за несколько минут. Более тщательное управление необходимо также при рабо~е с программами, которые должны функционировать без остановки в течение длительного времени и в условиях крайней ограниченности ресурсов.
Аналогичные требования предъявляются к системам реального времени, в которых требуется гарантировать предсказуемое потребление памяти с минимальными затратами. Традиционно в таких программах вообще старались избегать динамической памяти. Но для управления ограниченными ресурсами можно применить специализированный распределитель. И, наконец, я сталкивался со случаями, когда из-за требований аппаратуры или системы объект следовало разместить по конкретному адресу. Вследствие всего этого механизм управлсния памятью в С++ (см. раздел 2.11.2) в версии 2.0 был пересмотрен.
В основном усовершенствования коснулись Распределение памяти и инициализации ЯффффЯЩП механизмов контроля над распределением памяти, при этом предполагалось, что программист понимает, как это происходит. Эти механизмы должны были работать совместно с другими языковыми средствамн, чтобы инкапсулировать тс фрагменты кода, где осуществляется нестандартное управление памятью. Работа над ними завершилась в 1992 г. введением операторов орегасог пеы ( ) и арета сот де1есе [] управления памятью для массивов.
В нескольких случаях предложения исходили от моих друзей из компании Меп(ог СгарЫсв, где на С++ была создана большая и сложная система СА()/САМ. Арчи Лахнер из Мепгог подал мне несколько блестящих идей об управлении памятью, которые были учтены в версии 2.0. 10.2.
Отделение распределения паыяти и инициализации Применявшийся до выхода 2.0 способ управлять распределением и освобождением памяти на уровне класса с помощью присваивания указателю с)зйв (см, раздел 3.9.) провоцировал ошибки и был объявлен устаревшим. В версии 2.0 в качестве альтернативы допускались раздельные выделение и инициализация памяти. Это значит, что инициализация выполняется конструктором после топь как память уже выделена каким-то независимым механизмом.
Такой прием позволяет использовать разные механизмы распределения, в том числе написанные пользователем. Память для статических объектов выделяется на стадии редактирования связей, память под локальные объекты распределяется из стека, а для динамических объектов — с помощью подходящего орегас ог пеи ( ) . Освобождение памяти производится аналогично. Например: с1авв Х ( // рц)з11с: чогак орегагог пеи(вьзе С вз); лога орегагог Пе1еге(нога* р); // выделить вг байт // освободить р Х(); // инициализировать х(ьпс 1); // инициализировать -Х(); // очистка // Тип вузе с — это зависящий от реализации интегральный тип, используемый для представления размеров объектов; он позаимствован из стандарта АХИ С. Именно с помощью оператора пеы правильно выделяется и инициализируется память, если эти операции выполняются раздельно.
Компилятор генерирует вызов распределителя памяти Х:: орегагог пеы ( ) и вызов конструктора Х в месте вызова пен для х. Логически х:: орегасог пен ( ) вызывается раньше конструктора. Поэтому он должен вернуть чоЫ*, а не х*. Конструктор создает объект уже в выделенной памяти. ЕИИИИИИ3~ Управление памятью Деструктор, наоборот, уничтожает объект, но не освобождает его память, полагая, что это сделает орекасок г]е1есе ( ) . Поэтому х:: орехасок с)е1есе () принимает аргумент типа юоЫ*, а не Х*. Применимы обычные правила наследования, поэтому память для объектов производного класса выдсляется с помощью орега с ох пе»г ( ) из базового класса: с1аяя т : рсЫгс Х ( // объекты класса т также распределяются // с помо"ью Х::сретакот леы() // Чтобы этот фрагмент кода работал, х::орегасох пе»г() нужен аргумент, указывающий, сколько памяти выделить: зузеой (у) чаще всего не совпадает с зькео1 (Х) .
К сожалению, неопытные пользователи обычно удивляются, когда узнаю~, что нужно объявить этот аргумент, но не передавать его явно при вызове. Идея об определенной пользователем функции, фактический аргумент которой передает «система», некоторыми усваивается с трупом. Но в качестве компенсации за излишнюю сложность базовый класс теперь может предоставлять услуги по выделению и освобождению намятп всем производным от него классам. Кроме того, не возникает ненужных исключений из правил наследования.
10.3. Выделение памяти для массива Определенный в классе оператор х::орегасок пе»/() применяется только к индивидуальным объектам класса Х (включая и объекты производных от Х классов, в которых нет собственного орегасок пе»г () ). Отсюда следует, что предло- жение Х* р = лен Х(10); нс порождает вызова Х::орекагог пе»г(), поскольку Х [10] — массив, а не объект типа Х. Это стало причиной претензий, поскольку пользователи не могли управлять распределением памяти для массивов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
