Б. Страуструп - Дизайн и Эволюция C++. 2006, страница 10

Когда формулировался этот критерий, поддержка встроенных типов была гораздо обширнее, но развитие языка С++ продолжалось, так что теперь данные типы поддержаны чуть хуже пользовательских (см. раздел 15.11.3). В первой версии С тчйЬ С1аззез отсутствовали встраиваемые (1п1ше) функции, но вскоре они были добавлены.

Основная причина их включения в язык — опасение, что из-за расходов на преодоление ~защитного барьера» люди не захотят пользоваться классами для сокрытия представления. Так, в [8ггоцзггцр,1982Ь] отмечено, что многие делают члены классов открытыми, дабы не расплачиваться за вызов конструктора в простых классах, где для инициализации достаточно одного-двух присваиваний. Толчком для включения в С вчГЬ С1аззез встраиваемых Дальнейшую разработку С ъч~Ь С!аззез и С++ можно в значительной мере рассматривать как изучение последствий этих проектных решений, выявление их положительных и отрицательных сторон и устранение проблем, вызванных недостатками.

Многие, но далеко не все следствия принятых решений были понятны уже в то время (работа [Вггоцзггцр,1980] датирована 3 апреля 1980 г.). В данном разделе я попытаюсь объяснить, чту же было ясно уже тогда, и сошлюсь на разделы, где рассматриваются более отдаленные последствия и позднейшие реализации. ИИИИИИВВ Язык С ч)/!Ф С!аззез функций послужил проект, в котором для некоторых классов, связанных с обработкой в реальном времени, накладные расходы на вызов функций оказались неприемлемы.

Чтобы воспользоваться преимушествами классов в такого рода приложениях, необходимо иметь возможность «бесплатно» преодолевать защиту доступа. Этого можно было побиться только сочетанием представления в объявлении класса с встраиванием вызовов открытых функций. В связи с этим возникло следующее правило С++: недостаточно просто предоставить возможность, нужно также, чтобы плата за пользование ей была не слишком велика, то есть «приемлема на том оборудовании, которое есть у пользователей», а не «приемлема для исследователей, имеющих доступ к высокопроизводительному оборудованию» или «приемлема через пару лет, когда аппаратные средства подешевеют».

С ччгЬ С1аавез всегда рассматривался как язык, готовый к применению сейчас или в следующем месяце, а не как исследовательский проект, от которого можно ожидать отдачи через несколько лет. 2.4Л. Встраивание Встраивание было признано важным для удобства работы с классами. Поэтому вопрос заключался не в том, стоит ли его реализовывать, а в том, кбк это сделать. Два аргумента убедили меня, что только программист должен решать, какие функции компилятор попытается встроить в код. Во-первых, у меня был печальный опыт работы с языками, где решение вопроса о встраивании оставлялось на усмотрение компилятора, поскольку он якобы «лучше знает».

Однако на компилятор можно положиться только в том случае, если в него запрограммирована концепция встраивания и его представление об оптимизации по времени и памяти совпадает с моим. Опыт работы с другими языками показал, что встраивание, как правило, «будет реализовано в следующей версии», да и то в соответствии с внутренней логикой языка, которой программист не может эффективно управлять. Кроме того, С (а за ним С тг(Г)) С!аззез, и С++) организует раздельную компиляцию, так что компилятору всегда доступен только небольшой фрагмент всей программы (см.

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

С учетом всего вышесказанного от программиста требуется помощь. Даже сегодня этот выбор кажется мне правильным. В С ч(гЬ С!аззсз допускалось только встраивание функций-членов. Единственным способом заставить компилятор встроить функцию было помещение ее в объявление класса. Например: с1аее есасх ( /* */ сваг РоР() ( !Г (сор <= в!о) еггог("стек пуст" ) ЛИИИИИИИ Модель компоновки гесптп */-сор; ) То, что при этом объявление класса несколько теряет наглядность, не осталось без внимания, но было сочтено правильным, поскольку препятствовало чрезмерному применению встраиваемых функций. Ключевое слово ?п1?пе и возможность встраивать функции, не являющиеся членами, появились позже, уже в С++, Так, в С-(-+ этот пример можно переписать иначе: с1ааа агаси (О Саа // спаг рср(); ) ?п1тпе сваг впаск::рор() // С+а ( ?Г (Сор <= п?п) еггсг["стек пУст"); геспгп *--сор; 2.5.

Модель компоновки Вопрос о том, как скомпоновать раздельно откомпилированные фрагменты программы, важен для любого языка программирования и ло некоторой степени определяет возможности языка. На разработку С ч !?Ь С!аззез и С++ во многом повлияли следующие решения: о раздельная компиляция может осуществляться с использованием стандартных компоновщиков (редакторов связей) для С/'гогггап, применяемых на платформах ?)Х?Х и ООБ; Директива ?п1?пе — лишь совет, который компилятор может игнорировать и часто так и поступает. Это вызвано логической необходимостью, поскольку можно написать рекурсивную встраиваемую функцию, а на этапе компиляции невозможно доказать, что рекурсия не окажется бесконечной. Попытка встраивания такой функции привела бы к зацикливанию компилятора Придание слову ?п1?пе статуса совета имеет и практическую пользу, поскольку позволяет автору компилятора обработать тс случаи, когда встраивание невозможно, и просто отказаться от него.

Для С (в!г?( С!аззез, как и для всех его преемников, было необходимо, чтобы встраиваемая функция имела в программе единственное определение. Определение такой функции, как рор ( ), приведенной выше, в разных единицах компиляции привело бы к хаосу, игнорированию системы контроля типов. Но в условиях раздельной компиляции трудно гарантировать, что в большой системс данное правило не нарушено.

В С ъчгЬ С1аззез это не проверялось, и в большинстве реализаций С++ до сих пор нет гарантий, что встраиваемая функция не определена по-разному в разных единицах компиляции. Однако теоретическая проблема пе переросла в практическую в основном потому, что встраиваемые функции обычно определяют в заголовочных файлах вместе с классами, а объявления классов в программе также должны быть уникальны. ИИИИИИИВ Язык С )д((1)) Оаввез (з компоновка должна быть типобезопасной (не противоречить системе контроля типов); (з компоновка не должна нуждаться в какой бы то ни было базе данных (хотя ее использование в конкретных реализациях для повышения эффективности не запрещается); () компоновка с фрагментами программы, написанными на других языках, например на С, Рогггап или ассемблере, должна быть простой и эффективной.

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

С++ следует этой модели, но только до определенного момента. В объявлении класса в С++ может (хотя и необязательно, см. раздел 13.2) быть описано размещение объекта. Это разрешено для того, чтобы упростить и сделать эффективным объявление истинно локальных переменных. Рассмотрим такую функцию: чово г() ( с1авв вваск в; 1пс су в.рсва('Ь']; с = в.рор(); ) Реагируя на объявление класса в гас)с (см. разделы 2.3 и 2А.1), даже простейшая версия С тч)гЬ С!аваев сможет сгенерировать для этого примера код, где: динамическая память не используется, функция рор () встроена так, что ее вызов не связан с накладными расходами, а при обращении к рив)т ( ) вызывается невстраиваемая, отдельно скомпилированная функция.

В этом отношении С++ напоминает язык А()а. В то время я полагал, что можно найти какой-то компромисс между двумя подходами: л отделение объявления интерфейса от реализации (как в Мог)ц!а-2) в сочетании с подходящим инструментом (редактором связей); (з наличие единого объявления класса в сочетании с инструментом (анализатором зависимостей), который будет рассматривать интерфейс отдельно от деталей реализации с целью определить, в каких случаях нужна повторная компиляция.

Похоже, я недооценил сложность последнего решения, а сторонники первого подхода — его стоимость (с точки зрения переносимости и затрат во время исполнения). Еще больше я осложнил жизнь пользователям С++, не объяснив должным образом, как можно воспользоваться производными классами для отделения ИИИИИИИП Модель компоновки вггцсс й ( 1пг х, у; ); вггцсг в ( гпг х, у; ); определяют два несовместимых типа А и В. Далее, объявления всгпсс С ( 1пс х, у; ); // в файле 1 вггпсг с ( гпг х, у; ); // в файле 2 определяют два разных типа с одним и тем же названием с, и компилятор, способный осуществлять сквозную проверку в разных единицах компиляции, должен был бы выдать ошибку «повторное определением Это правило призвано снять некоторые проблемы при сопровождении программы. Подобные повторяющиеся объявления возникают, по всей вероятности, при копировании текста из одного файла в другой.

Но после атой операции объявление вполне может измениться. И если, изменив его в одном файле, не сделать то же самое в другом, программа просто перестанет работать. На практике С, а за ним и С++ гарантируют, что структуры типа А и в, приведенные выше, одинаково размещаются в памяти, так что их можно приводить друг к другу и использовать очевидным образом: ехсегп Г(всгцсс А*); чоЫ д(всгцсс А* ра, всгцсс В* рЬ) ( г (ра); г (рь); /* правильно */ /* ошибка: ожидается й* */ ра = рЬ! ра = (всгисг А*)рЬ; рЬ->х = 1; (ра->х )= рЬ->х) еггог("плохая реализация") /* ошибка: ожидается А* */ /* правильно: явное преобразование */ Эквивалентность имен — основополагающий принцип системы типов в С++, а правила совместимости размещения в памяти гарантируют возможность явных преобразований, используемых в низкоуровневых операциях.