Чому C ++ все ще є "гібридом"

У відповідному питанні було з’ясовано, чому C ++ у багатьох аспектах не сумісний із C. Однак C ++ все ще є "гібридною" * мовою. І на жаль, багато програмістів все ще розглядають C ++ як "C із потоками та вбудованими рядками". Це призводить до дійсно поганого письмового коду, що це не є ні C ++, ні C. IMHO, було б краще, якби мова / компілятор змусили певною мірою програмістів написати більш елегантний код. Тож чи існує обґрунтування збереження сучасного C ++ (наприклад, C ++ 0x та майбутніх версій) гібридом?

_{* Під гібридом я маю на увазі, що програміст повинен вирішити, чи буде він / вона використовувати: стандартні рядки та потоки, класи, простори імен, крім стандартних, тощо.}

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

IMHO, було б краще, якби мова / компілятор змусили певною мірою програмістів написати більш елегантний код.

Ні, не буде. Зовсім. Як тривіальна демонстрація того, чому, визначте елегантне, і тоді я ставлю на облік, що десять людей прийдуть не погодитися з вами.

Стилі кодування з урахуванням мови - це дуже, дуже погано. Не кажучи вже про всі застарілі коди, які будуть порушені.

Помітно, що класичний рядок та потокові класи насправді смоктають . std::stringне має підтримки Unicode та найгіршого роздутого інтерфейсу, який ви могли собі уявити. Потоки мають жахливі накладні витрати і поганий дизайн, навіть вдаючись до віртуальної спадщини, і функціонують покажчики, і const char*такі угли. Я б нікого не карав за те, щоб повністю замінити обидва ці класи / групи класів на власні.

Не використовувати класи та простори імен - це нормально для коду стилю дошки, і є багато, багато бібліотек, які надають функції не в класі. Примусовий клас - це дійсно погана ідея.

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

IMHO, було б краще, якби мова / компілятор змусили певною мірою програмістів написати більш елегантний код.

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

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

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

IMHO, було б краще, якби мова / компілятор змусили певною мірою програмістів написати більш елегантний код.

Ніхто не змушує нікого в першу чергу використовувати C ++. Якщо мова вам не підходить, то використовуйте іншу - багато мов рахуються як "C ++ без C".

Філософія дизайну C ++ - це дати можливість програмісту прийняти рішення. Якщо вони хочуть застрелити себе в ногу, то нехай вони. Це дозволяє зробити багато поганих речей, але також дозволяє отримати велику гнучкість. Наприклад, навряд чи Boost може бути написаний на такій мові, як Java, оскільки він використовує переваги мовних особливостей і практик, які зазвичай уникають. Також малоймовірно, що C ++ виросте настільки ж великим, як сьогодні - доступ до величезної бібліотеки С - це величезний плюс, взяти його чи залишити

Сумісність C ++ із C, безумовно, є одним із найслабших моментів, але також майте на увазі, що це один із його найбільших.

Я збираюся додати чудову цитату Джона Перді, яку я вважаю надзвичайно актуальною:

Все зводиться до прагматизму проти елегантності, і для мене, незважаючи на мою одержимість точним, красивим кодом, писати некрасиву програму, яка працює краще, ніж писати прекрасну програму, яка нічого не робить.

Видалення гібрида може покращити елегантність, але це перешкоджає можливості.

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

Багато чого з того, що ви виступаєте, - це справді справа про судження, в будь-якому випадку на основі проблемної області. Існує безліч невеликих програм, яким просто не потрібні (на один приклад) простори імен. Спроба змусити мене використовувати простір імен, коли я пишу текстовий фільтр на 30 рядків, було б нерозумно і зарозуміло. Навіть якщо ви вирішили, що він застосовуватиметься лише тоді, коли буде задіяно більше X рядків коду, або Y-функцій, або що б там не було, це все одно буде контрпродуктивним. Простори імен були розроблені з причини, щоб запобігти / вилікувати конкретні проблеми. Спроба насильницького їх використання за відсутності цих проблем нікому не приносить корисного.

У той же час, я думаю, що варто відзначити, що досить багато людей дійсно витрачають багато часу і зусиль, намагаючись не лише додати елегантності в C ++, але навчити і примусити людей використовувати ці можливості для написання кращого коду (наприклад, багато учасників Boost). Таким чином, люди, які продовжують наполягати на написанні коду як "C з класами", ігнорують те, що там все одно. Я думаю, що їм буде так само зручно ігнорувати нові компілятори, як ігнорувати все, що було вивчено про використання C ++ за останнє десятиліття або більше (наприклад, Сучасний дизайн C ++ був опублікований вже 11 років тому - але більшість людей ви про це, мабуть, ще не чули, тим більше читали і не розуміли навіть найпростіші його частини).

Ваша ідея є значною мірою обґрунтуванням дизайну Java. Java змушує використовувати класи, впорядковувати ієрархію файлів відповідно до ієрархії пакетів, виловлювати винятки тощо. Люди все ще встигають записати в неї код, подібний С.

Як програмісти, ми іноді забуваємо, що найкраще рішення може бути не технічним. Експертні оцінки - найкраще відоме рішення в даному випадку.

C ++ не має "жодного справжнього шляху"; кожен підхід має сильні та слабкі сторони. Розв’язання можна записати сто різними способами.

Ви, як розробник програмного забезпечення, повинні вирішити, який підхід найкраще підійде до завдання.

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

Проблеми, які нам потрібно вирішити за допомогою програмування, дуже відрізняються.
Деякі вирішуються добре, використовуючи принципи ОО (наприклад, графічні інтерфейси), деякі краще піддаються чисто функціональній обробці (наприклад, числовий матеріал), а деякі найкраще виражаються на низькому рівні "близької до кремнію" мови.

Багато програмного забезпечення потребує вирішення підпроблем, які найкраще вирішуються будь-яким із цих способів. Примушування рішення до конкретної форми призведе лише до коду, який менш відповідає його призначенню (можна сказати навіть "менш елегантний").

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