Skip to main content

Empire strikes back: Steven Dewhurst's response to Linus's criticism against C++

Помните нападки Линуса на С++ о которых я когда-то писал? Когда он в довольно жесткой форме высказался в отношении того, что он думает о С++?

Ну вот Steven Dewhurst ему отвечает:

I think it's only fair to point out that Linus' diatribe is more than a year old, and he has spoken in more measured and printable tones elsewhere about the same subject. Less excusable, however, is that he makes the claim that C++ cannot be used in resource-constrained areas with nothing but anecdotal evidence to support his claim. Linus has done good work and has earned his soap box, but he also has a professional obligation to make sense while he’s holding forth. (For those who follow such things, this is an instance of Gotcha #12, “Adolescent Behavior,” from C++ Gotchas.)

The argument that abstraction and efficiency are mutually-exclusive or that they're mutually exclusive in the context of C++ is demonstrably false. Lately, much of my work involves writing embedded code in C++ with heavy use of inheritance and templates, and the results have been more than promising. The resultant code is typically smaller and faster than the equivalent (well-written) C code provided by the board's manufacturer, and has the significant advantage of being usable by a developer who is not expert in the minutia of the board's design. Unlike Linus, I haven't written a commercial OS, but I have written a policy-based, pre-emptive tasker in C++. It occupies just 3k of RAM and is pretty zippy in addition to being easy to understand, customize, and maintain. Just to annoy people like Linus, I've also used typelist meta-algorithms to generate exception handlers with identical efficiency to hand-coded C. In a number of recent talks given at the Embedded Systems conferences, I've shown that commonly-criticized C++ language features can significantly outperform the C analogs. As an old-school, Bell Labs C hacker I've nothing against C. But C++ provides tools and capabilities that are hard to come by in C, and often make it easier for a competent C++ programmer to produce cleaner and typically smaller and faster code than the C equivalent.

Regarding competence, Linus’s implied argument that C++ attracts bad programmers the way other things attract flies is, in spite of the effective metaphor, both unfair and a little over the top. Inexperienced or incompetent programmers have been lured into writing bad code in other languages as well; I've inherited my share of poorly designed and rendered C. There's no question that C++ is a significantly larger and more complex language than C, and a competent C++ programmer should be familiar with many more design styles (including, among others, that "idiotic 'object model' crap") than a competent C programmer. Wider experience with different design approaches and coding idioms is an advantage if the programmer actually has more than a passing understanding of the techniques. Problems typically arise when teams of competent C programmers are thrown onto a C++ project without adequate preparation simply because C++ syntax looks something like C syntax. The results are usually about the same as you’d get by throwing the same team into a COBOL project. But you’re not going to catch me criticizing COBOL. That’s Linus’s job.

via InformIT: C++ Reference Guide > A Response to Linus Torvalds' C++ Diatribe

Comments

  1. Лінус тоді повів себе, як типовий лінуксюгенд. Хоча він часто по-дитячому категоричний.

    Готові контейнери і алгоритми для роботи з ними як частина стандартної бібліотеки - це безумовне добро. Шаблони - взагалі божественне провидіння :-)

    ReplyDelete
  2. Да ну, это ваще никак не тянет на empire strikes back. У линуса действительно наброс так наброс, тут какое-то невнятное "а я вот тут писал на С++ и все работало", тьфу.

    Кстати, кто этот Стивен вообще? (кроме как автор пары книжек по C++)

    ReplyDelete
  3. Правильно Лінус каже, я взагалі підозрюю що класи з їх віртуальними функціями придумали тільки для того, щоб гарно написати GUI, а шаблони - щоб гарно написати STL

    ReplyDelete
  4. 2nahtigal: ну з божественним провидінням ти мабуть погарячкував :). Згоден - річ безумовно корисна, але ж і дещо складніша за звичайне ООП

    2lrrr: да ну, это ж такой довольно взвешенный strike back немного приправленный легкой иронией :). Чего стоит только "Just to annoy people like Linus, I've also used typelist meta-algorithms to generate exception handlers with identical efficiency to hand-coded C", а это - так вообще бесподобно: "But you’re not going to catch me criticizing COBOL. That’s Linus’s job.".
    Ну а ответ на вопрос кто такой Cтивен - можно поискать здесь

    2rembo: я не згоден, бо на мою думку сфера застосування шаблонів та класів з віртуальними функціями не обмежена лише GUI & STL

    ReplyDelete
  5. Yuriy Volkov:
    сфера застосування шаблонів та класів не обмежена лише GUI & STL

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

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

    Мій висновок:
    Комусь подобається використовувати класи, комусь не подобається, але факт шо без класів можна писати нормальні програми, чого не зробиш наприклад без функцій і модулів, бо класи - це не метод програмування а лише дизайн коду програми.

    ReplyDelete
  6. 2Rembo:
    Конструкція обєктів визначається на етапі розбиття одної складної задачі на багато простих задач. Це розбиття, я думаю, і є обєктно орієнтованим програмуванням, а використання класів чи просто структур даних це є "дизайн" коду програми.

    Слідуючи усталеним інженерним нормам я дотримуюсь думки що процесс розробки будь-якої системи складається з декількох етапів:

    1) requirements analysis
    2) системний аналіз та декомпозиція цілей та задач
    3) проектування
    4) реалізація
    5) .....

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

    Що ж до того, що без класів можна писати нормальні програми, то тут важко не погодитись, бо маємо досить велику кількість вже написаного коду, котрий і працює добре і супроводжується, здається, непогано =). На мій погляд класи - це лише спосіб вираження своїх, так би мовити, думок у вигляді коду.

    ReplyDelete
  7. Yuriy Volkov:
    класи - це лише спосіб вираження своїх, так би мовити, думок у вигляді коду.

    Напевно мені цим і не подобаються класи - вони нав"язують спосіб мислення. Іншими словами класи обмежують свободу мислення, напрягають тебе думати якимось high-level, хоча, в принципі, до цих пір не винайдено нічого більш high-level-ого ніж C.

    ReplyDelete
  8. так, можливо. С++ складніший за чистий С, тому код потребує білше уваги під час проектування та реалізації. А з приводу того, що до цих пір не винайдено нічого більш high-level-ого ніж C я мабуть утримаюсь від коментарів, щоб не розпочинати ще одну священну війну ;). Программери з функціонального світу теж мабуть мають що сказати з приводу імперативщини :).

    ReplyDelete
  9. Про функціональне програмування згоден, я не точно висловився бо мав на увазі такі нововведення як класи і шаблони С++ в порівнянні з С.

    ReplyDelete

Post a Comment

СООБЩЕНИЕ СПАМЕРАМ: прежде чем пытаться оставить ссылку на свой ресурс в комментарии, прошу обратить внимание на тег nofollow, которым они помечены и зря не терять ни свое ни мое время. А будете упорствовать еще и noindex поставлю