Інтерв’ю з Бьорном Страуструпом про мову C

Інтерв'ю з Бьерном Страуструпом про мову C++

Рахований годинник залишився до Нового 2014-го року, в якому серед іншого всім нам був обіцяний новий стандарт C++14. Однак він буде не великим самостійним оновленням, а лише доопрацюванням C++11, багфіксом, який надасть поточній версії завершений вигляд. На цьому фоні Вільям Вонг (англ. William Wong) від ресурсу electronicdesign.com взяв інтерв'ю у Бьорна Страуструпа (дат. Bjarne Stroustrup), творця C++. Бесіда торкнулася кількох тем: від історії розробки C++ та особливостей стандарту C++11 до проблеми навчання цій мові програмування.

Деякі терміни та поняття цього інтерв'ю мені раніше зустрічалися виключно в англійському варіанті (наприклад, слівце embedded в контексті IT), і мені не завжди вдавалося знайти загальноприйнятий переклад, в якому я не був би впевнений сам. У цих та інших неоднозначних випадках я вказував англійський варіант терміна в дужках або залишав його неперекладеним.

Translated from article produced by Electronic Design, October 29, 2013, electronicdesign.com/dev-tools/interview-bjarne-stroustrup-discusses-c

На сьогоднішній день мови програмування C і C++ є найбільш затребуваними в області систем, що вбудовуються (embedded), а також у завданнях побудови платформ для сторонніх додатків. Автором C++ є Бьорн Страуструп. Він і досі бере активну участь у розробці стандартів цієї мови програмування, зокрема останньої — C++11. Багато чого про цю мову він писав у своїх книгах, наприклад, у “Programming: Principles and Practice using C++”. Б'єрн Страуструп люб'язно погодився відповісти на кілька питань про саму мову C++ і про його розробку.

Як ви дійшли розробки C++?

Я працював над проектом, якийдозволив би розділити ядро Unix на кілька частин, що виконуються мультипроцесором або високопродуктивною локальною мережею. І мені знадобився інструмент, який дозволив би працювати з апаратною частиною, забезпечував би хорошу продуктивність для завдань системного програмування, а також міг би використовуватися для роботи над системою зі складною архітектурою. Однак на той момент (1979-1980 рр.) жодна з існуючих мов програмування не задовольняла всі три умови відразу. Тому я вирішив додати до C концепцію класів на кшталт тієї, що була в Simula. Спочатку я реалізував перевірки та перетворення аргументів функцій (згодом вони стали прототипами функцій), конструктори, деструктори, а також найпростіше успадкування. Перша версія мови C++ називалася C with Classes. До речі, цікаво, що з найпростішої підтримки узагальненого програмування (generic programming) у ній використовувалися макроси. Надалі я зрозумів, що такий підхід не забезпечує належної масштабованості і замість макросів додав шаблони.

Я вдосконалював архітектуру та реалізацію мови C++ наступні кілька років, аж до його комерційного релізу у 1985 році. У той час продуктивність і швидкість звернення до апаратної частини були дуже важливими характеристиками, як і сьогодні. Я вважав за необхідне реалізувати в C++ всі можливості мови C, причому зробити їх не менш ефективними. Наприклад, на ранніх етапах я виявив, що структури, що використовуються для реалізації конструктора копіювання, займали на 3% більше пам'яті, ніж у C. Я вирішив, що так не повинно бути, і до кінця тижня все виправив. Щоб програмістам не довелося відмовлятися від класів без будь-якої втрати процесорного часу, були також додані функції, що вбудовуються (inline). Я взагалі був упевненийв тому, що використовувані засоби повинні бути не тільки виразними, а й досить ефективними, щоб їх можна було використовувати у додатках із найвищими вимогами.

Чого ви прагнули розробки мови C++?

До того, щоб C++ міг працювати з апаратною частиною як мінімум настільки ж ефективно, як це робив C. Крім того, мені видалася дуже важливою концепція абстракцій, яка дозволила б програмістам висловлювати свої найсміливіші ідеї без будь-яких тимчасових витрат або витоків пам'яті, з якими вони, швидше за все, зіткнулися б у самостійній реалізації.

Ця вимога тягне за собою використання суворої статичної типізації, на відміну від слабкої типізації C.

ефективна підтримка абстракції даних. Код, який використовує абстракції, не повинен допускати жодних накладних витрат порівняно з кодом без її використання,
принципи взаємодії мови C++ та її компілятора з комп'ютером повинні бути максимально схожими на ті, що були у C,
суттєва гнучкість коду, яку можна досягти за допомогою абстракцій, а також
надійність коду, що досягається за допомогою суворої статичної типізації.

Якщо загалом, C++ покликаний допомогти у написанні якісного програмного коду. Професійні програмісти в реальному житті стикаються зі складними завданнями, і ця мова програмування багато в чому спрощує їхнє життя.

Хоча, звичайно, не вдасться досягти всі ці цілі одразу, і C++ не ідеальний. Однак, незважаючи на незлічені спроби створити мову замість нього, C++ зі своїм строгим дизайном залишається найкращим рішенням для різних практичних завдань.

Ви брали участь у розробці стандарту мови C++ із самого початку. Чи сильно він змінився з часом?Хто розробляє нові стандарти? Важко сказати. Розробка формального стандарту — це дуже непроста і, як правило, нудотна справа. Ним займаються люди з великим досвідом, проте всі вони — фахівці з різних областей програмування, і кожен має своє бачення стандарту. Так що дійти єдиної думки може бути складно і невигідно за часом, але це необхідно: задовольнити всім вимогам відразу не вийде, а примушувати програмістів користуватися принципово новими інструментами не можна. Прогрес відбувається тільки коли до стандарту включаються доповнення, важливість яких є загальновизнаною. Не можна брати участь у комітеті і при цьому постійно зациклюватись на дрібницях. Потрібно вміти бачити всю картину загалом і дійти спільної думки з іншими. За моїми підрахунками, до комітету входить близько сотні організацій і, може, понад триста власне розробників. Це вдвічі-втричі більше, ніж було раніше. Лише на останніх зборах було близько ста чоловік.

У 2014 році ми плануємо випустити новий стандарт C++14. У ньому будуть мінімальні нововведення, а також кілька виправлень, за їхню необхідність уже проголосувала більшість комітету. Я розраховую, що у 2014 році всі вже використовуватимуть C++14, а після цього ми плануємо випустити C++17 у 2017 році. Але це оновлення буде вже набагато суттєвішим, тому тут складно судити про терміни.

Комітет з розробки стандартів ISO C++ сам по собі не має будь-яких ресурсів, будь то гроші або штатні розробники. Він повністю ґрунтується на коштах його учасників. Наприклад, щоби входити до складу комітету, вони платять 1200 доларів щорічно. Кожен може заявити, що, мовляв, у C++ немає нормальної бібліотеки для створення графічних інтерфейсів або нормальної бібліотекипідтримки паралелізму завдань. Так, ми знаємо. Чим скаржитися краще б допомогли довести ці завдання до розуму. У нас дуже мало прикладних програмістів, і часто виходить так, що нововведення створюються для інтересів одного конкретного розробника.

Багато програмістів при створенні вбудованих систем вважають за краще використовувати C, тому що він простіше, ніж C + +, і більше підходить для розробки під апаратне забезпечення. Чи дійсно складність C++ має бути каменем спотикання для розробки вбудованих систем? Зовсім ні. Якщо ви дотримуєтеся C-стилю програмування, то C++ виявиться нітрохи не складнішим за C, причому він теж підходить для розробки під апаратне забезпечення. І вже точно C++ набагато ефективніше, ніж C. Я ніколи не бачив такої програми на C++, яку можна було б так переписати на C, що вона матиме менший обсяг коду, вона буде продуктивнішою, вона краще супроводжуватиметься — загалом, буде ефективнішою . Не вірю, що таке можливе.

Міф про те, що «C краще C++», збиває з пантелику дуже багатьох програмістів-початківців. Так, наприклад, коли вони стикаються з проблемами, вони постійно намагаються щось вигадувати та застосовувати зовсім нетривіальні речі, а не використовувати прості та потужні інструменти. Зрештою, у них виходить дуже складний і заплутаний код, який вони через свої помилки сприймають як еталон. Уся ця ситуація мене просто вражає. Якщо людина береться за щось, а їй постійно твердять, що це дуже складно і марно, то в нього нічого й не вийде. Єдина зрозуміла причина, через яку, як я знаю, використовують чистий C, а не C++, це обмежені можливості конкретної платформи.

Однак студентів та взагалі новачків у вивченні C++ не можна звинувачувати, тому що їхні помилкичасто зароджуються у процесі освоєння університетського курсу програмування. Якось років десять тому мені довелося вести його у першокурсників. Я заглянув у підручники — і просто вразився: замість зрозумілих і простих у використанні конструкцій C++ у книгах спочатку розглядалася купа різних неочевидних дрібниць мови C, а інструменти С++ подавалися як щось дуже складне. Це не відлякувало лише тих, хто хотів серйозно займатися програмуванням.

Ось серйозно, скажіть: невже вектора зі стандартної бібліотеки складніша за масиви з C? Або, наприклад, чому студентів привчають до функції qsort() , хоча sort() і ефективніший, і універсальніший? У C++ більш строга типізація, ніж у C, завдяки цьому об'єктний код обробляється швидше.

Ще в підручниках часто описують C++ як спробу створення чистої об'єктно-орієнтованої мови програмування. Таке твердження як правило ілюструється цілим простирадлом коду, в якій практично вся архітектура розбита на заплутану ієрархію класів, успадкованих один від одного. У результаті виходить не характерна для C++ пов'язаність. Такий код нагадує швидше програму на Java, і, що найсумніше, працює він зазвичай повільно.

У C++ 11 було багато нововведень, у тому числі лямбда-вирази та підтримка багатопотокового програмування. Як ви вважаєте, чи виявилися вони затребуваними? Для роботи з потоками мені постійно доводилося користуватися сторонніми бібліотеками. Вони були хороші, але останні п'ятнадцять років я хотів додати підтримку потоків саме до стандарту, чого ми нарешті досягли. З погляду паралельного програмування ключові нововведення C++11 перебувають у організації пам'яті (яку, до речі, запозичували й мови C), і навіть портируемостибагатопотокових програм. Однак якщо ви програмуєте на рівні потоків і бар'єрів, то найголовнішим для вас може виявитися безпечне перетворення типів (type safety): для поділу та передачі даних між потоками більше не потрібно ніяких макросів або void**. Втім, для когось також важливими є інструменти і для lock-free програмування.

Що стосується лямбда-виразів, то я приблизно років десять працював над такою їхньою реалізацією в мові C++, від якої було б більше користі, ніж шкоди. У сторонніх бібліотек зазвичай страждає продуктивність. Нам вдалося домогтися для лямбда-выражений продуктивності, порівнянної з циклом for . Наведу приклад: