C або C + +?, Різне, Програмування, статті

Існують два діаметрально протилежних, але однаково поширених думки, які можна виразити як “C + + це C з класами” і “C + + і C — різні мови програмування”. Загалом-то, не важливо, якої думки дотримуватися, але цікаво інше — у яких випадках який з цих мов (або варіантів мови) переважно.

При цьому я не хочу починати порівняння об’єктно-орієнтованого та структурного підходів до створення програмного забезпечення, тому що дуже часто в подібних дискусіях можна почути фразу виду “недостатня об’єктно-орієнтованість мови програмування “, а вона, на мій погляд, невірна: при проектуванні системи” об’єктно-орієнтованість мови програмування “важливої ​​ролі не грає —” об’єктно-орієнтовано ” програмувати можна практично на будь-якій мові програмування. Інша справа, що додаткові засоби мови, які підтримують створення і використання об’єктів, скорочують кількість відповідних рядків коду і зменшують вірогідність помилок, але в ідеалі це не важливо.

Кардинальна різниця між C і C + + не в класах або шаблонах окремо, а в загальній ідеології: C дозволяє програмістам максимально контролювати (для мови програмування високого рівня) програму, а C + + йде по шляху ускладнення компілятора, щоб дозволити програмістові писати програму як йому буде “зручно”. При цьому, знову ж таки, в ідеальному випадку, компілятор мови зрозуміє бажання програміста і отриманий код буде все одно максимально ефективним (або близьким до ефективного). З одного боку, підхід C + +, не може не викликати інтересу і схвалення, так як дає можливість створення ефективних програм не знижуючи при цьому їх читабельність або зручність нарощування. Але з іншого боку — підвищення складності компілятора зв’язане з різними труднощами, багато з яких до цих пір не подолані.

Коли я тільки починав вивчати C + + (це було, напевно, років 6-7 тому), я був здивований великій кількості різко негативних думок про нього у професійних програмістів. Тоді мені це було незрозуміло, що, загалом, не дивно: Бьерн Страуструп не тільки пішов по шляху ускладнення компілятора, а й по шляху ускладнення мови програмування, так що вивчення C + + це дуже довгостроковий процес і, напевно, на сьогоднішній день це самий складний мова програмування. А так як протиставити що-небудь мови програмування можна тільки після того, як прийде розуміння основних ідей і більшості конструкцій мови, а так само після виконання великих проектів на ньому, то і час дитячого наснаги та радості при вигляді потужного інструменту (яким є C + +) значно більше, ніж у інших мов програмування.

Незважаючи на те, що за ці 7 років C + + пройшов чималий шлях і сильно змінився, мені здається що джерело тих нарікань, які мають сенс, залишився. Хочеться відзначити, що є велика кількість нарікань щодо безглуздих, на мій погляд, таких як уже згаданий дивний термін “мала об’єктно-орієнтованість”. Дуже часто можна почути, що “C + + це не Smalltalk”. Дивне судження: якщо програмісту більше подобається Smalltalk, то на ньому і треба програмувати.

Корінь же більшості бід, пов’язаних з C + +, криється якраз в ускладненні компілятора (не дивлячись на те, що вище це ускладнення підносилося як переваги): чим складніше програма (в даному випадку, компілятор), тим більша ймовірність того, що в ній буде помилка.

Насправді, звичайно ж, якщо програма перестає працювати, то скаржитися на інструмент розробки треба в останню чергу, а спочатку слід спробувати знайти помилку в своєму початковому коді. Але чим більше стає програма, чим сильніше вона розростається, тим все більше і більше вірогідність того, що помилка в компіляторі позначиться на роботі вашої програми. Це було б ще півбіди і особливості “свого” компілятора програмістові слід знати, але компіляторів C + + досить багато і кожен з них має свої власні достоїнствами і недоліками, результатом яких може стати неможливість збірки проекту під будь-середовищем програмування, відмінній від початкової. Я не маю на увазі складність написання універсально переносних програм, що працюють під будь операційною системою, зовсім ні. Просто так як написати компілятор C простіше, ніж C + +, і так як сама мова програмування C має меншу кількість слизьких місць, ніж C + +, то два різних компілятора C (різних виробників) будуть більше схожі один на одного по поведінці, ніж два компілятора C + +.

Крім компілятора, велику складність при програмуванні на C + + викликає використання STL. Безсумнівно, бібліотека шаблонів дуже зручна і корисна, але це в ідеалі. Приміром, дуже часті випадки, коли зміна поставляється з компілятором STL на STLport, призводить до того, що програма починає працювати стабільніше.

Звичайно ж, проблеми, пов’язані з помилками в компіляторах, виявляються дуже рідко. Власне тому можна вже зараз оцінити коло завдань, які краще вирішувати за допомогою C + +, ніж C (при наявності, звичайно ж, хороших навичок програмування в обох мовах): це практично всі програми, від яких не потрібно безперервна робота 24 години на добу. Дуже неприємно виявити, що програма, яка писалася і відладжувалася на якихось тестових прикладах, не може витримати реального навантаження і проблема криється саме в тому, що десь глибоко всередині бібліотеки, яка поставляється з компілятором, не був реалізований механізм блокування доступу до ресурсу. Крім того, зазвичай переносимість програми з одного компілятора на іншій зменшує кількість використовуваних можливостей мови програмування, тому що різні компілятори, як це не смішно звучить, по різному “відповідають стандарту”. Або, точніше, не відповідають йому. А подібне обмеження на конструкції мови (одне з найбільш образливих поневірянь, звичайно ж, обмеження на використання шаблонів) зводить нанівець більшість переваг C + +.

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

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

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

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


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*