Радикальная перемена в подходе к обновлениям и дополнениям в Стандарте C++ случилась на недавней встрече WG21, — или, скорее, это было изменение, которое «висело в воздухе» вот уже в течении нескольких последних встреч, и теперь наконец было обсуждено комитетом и задокументировано. Внимание читателей должны привлечь два ключевых пункта в самом начале документа «С++: планы на стабильность, скорость и реализацию языка» (C++ Stability, Velocity, and Deployment Plans [R2])":
- Является C++ языком, в котором есть новые потрясающие возможности?
- Известен ли C++ как язык, славящийся своей отличной стабильностью в течение долгого периода времени?
За ними следует следующее предложение (которое было согласовано на собрании): «Комитет должен быть готов рассмотреть дизайн/качество предложений даже в том случае, если эти предложения могут стать причиной изменения поведения языка или ошибки компиляции уже существующего кода».
Позади нас — 30 лет совместимости C++/C (ну хорошо, в последние 15 лет были по мелочи небольшие случаи, когда мы упирались в края и «заигрывали» с нею). Это замечательное достижение, за которое мы в течение вот уже более 30 лет благодарим Бьярна Страуструпа и 64 встречи, проведенные комититом по стандартизации (Том Плум и Билл Плагер занимали их место в этом нелегком деле в промежуток между WG14 и WG21).
Надмножество C/C++ имеет давнюю историю.
В конце 1980-ых SC22 (комитет ISO высшего уровня по языкам программирования) задал WG14 (комитету по C) вопрос о том, должен ли быть создан стандарт для C++ — и, если это так, то хотят ли WG14 заняться его созданием. WG14 рассмотрели этот вопрос на собрании в апреле 1989 года и приняли решение о том, что по их мнению создание стандарта C++ стоит внимания, но комитет по C — это не те люди, кому стоило бы этим заняться.
В 1990 году, SC22 учредило учебную группу, которая должна была выяснить, имеет ли смысл создавать рабочую группу по C++, и U.S. X3 (комитет ANSI, отвечающий за системы обработки информации) учредил X3J16. Встреча-противостояние тех, кому предстояло в дальнейшем стать WG21, была проведена в Лондоне в марте 1992 года (и это была единственная встреча ISO C++, на которой я присутствовал).
Участники X3J16 приехали в Лондон для встречи ISO, и время от времени дебаты становились по-настоящему жаркими. Двумя основными публичными мнениями были идеи о том, что:
- нужно начинать работу над стандартом C++;
- C++ еще недостаточно созрел для того, чтобы можно было работать над стандартом.
Причиной, по которой многим хотелось начать работу над стандартом, и о которой не принято было упоминать публично, было стремление остановить, или хотя бы замедлить, появление изменений в языке. Новые релизы Cfront, наряду со слухами о них, были достаточно частыми (настолько, насколько часто это можно было делать по меркам эпохи до Интернета). Разработчики из крупных компаний рвали себе волосы на голове, когда шесть месяцев спустя после старта работы над каким-либо большим приложением версия С++ заменялась новой, слегка измененной.
Может показаться, что производители компиляторов должны были бы радоваться тому, что язык регулярно менялся — ведь изменения давали стимул разработчикам платить за покупку обновлений компилятора. На практике, изменения были настолько значительными, что для требовались те, кто действительно знал то, что они делают — т.е. требовалось платить большую зарплату сильным программистам; производителям компиляторов же было куда привычнее тратится на маркетинг мелких обновлений. Утверждалось, что реализация компилятора С++ требовала в семь раз больше затрат, чем реализация компилятора для С. Понятия не имею, насколько это утверждение было справедливо на практике (возможно, это лишь оценка одного из производителей, основанная на его примерном опыте). В 1980-ых у каждого человека и у его собаки был свой собственный компилятор C, но большая часть тех из них, кто пытался реализовать компилятор С++, уперлись в кирпичную стену.
Наконец, последовало голосование: стоит ли остановить/замедлить скорость принятия изменений в С++ — против того, чтобы позволить C++ «исполнить свое предназначение» (так выразился представитель AT&T в своем призыве к аудитории, вследствие чего вся комната запплодировала). По его итогам, исследовательская группа превратилась в WG (увы, не могу поделиться с вами точными цифрами — никаких данных онлайн об этом событии нет, и я не могу найти бумажной копии — мы пользовались такими до середины/конца 90-ых).
Создание WG21 не имело того эффекта, которого от нее ожидали (замедления внесения изменений в язык), поскольку Страуструп присоединился к комитету, и эволюция С++ продолжалась в быстром темпе. Однако, с точки зрения простых разработчиков, изменения в языке стали происходить медленнее; Cfront перестал обновляться так быстро, поскольку его код стал коллапсировать под грузом предшествующей эволюции — и на свет стали появляться адекватные компиляторы С++, которые можно было использовать на практике (в те ранние годы мощным стимулом роста популярности языка стал компилятор Zortech C++).
Последняя встреча WG21 включала 140 человек в списке посетителей; не все из них были заскучавшими от жизни консультантами, которые ищут творческую отдушину (я про «новые потрясающие возможности») — но я уверен в том, что многие были бы рады избавиться от кандалов, связывающих их по рукам и ногам (более известным как совместимость с C).
Мне кажется, нас ожидает куча предложений, которые поломают совместимость с C тем или иным способом, и некоторые из них попадут в опубликованный стандарт. Это будет подкреплено аргументом о том, что данные изменения сделают жизнь проще будущим разработчикам на C++ (подобное заявление делают сторонники каждого языка, несмотря на то, что эмпирические доказательства этого отсутствуют). Единственным способом выяснить, принесет ли изменение долгосрочную пользу, является долгое ожидание и наблюдение за тем, что случится в итоге.
Интересным вопросом здесь является то, как отреагируют производители компиляторов на серьезные изменения в стандарте языка, «ломающие» его совместимость. В настоящее время активно используемых компиляторов существует не так много, т.е. конкуренция не так велика. Что станет стимулом для производителя компилятора для выпуска его новой версии, которая почти наверняка «сломает» написанный до этого код? Ведь валидация копиляторов относительно стандарта отошла в прошлое.
Если WG21 внесет слишком много серьезных «ломающих» изменений, то вполне возможно, что производители компиляторов для C++ решат их проигнорировать — а разработчики задумаются о том, не вышел ли у комитета ISO по стандартизации C++ срок годности.
Автор: HotWaterMusic
