Помните нападки Линуса на С++ о которых я когда-то писал? Когда он в довольно жесткой форме высказался в отношении того, что он думает о С++?
Ну вот 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
Ну вот 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
Лінус тоді повів себе, як типовий лінуксюгенд. Хоча він часто по-дитячому категоричний.
ReplyDeleteГотові контейнери і алгоритми для роботи з ними як частина стандартної бібліотеки - це безумовне добро. Шаблони - взагалі божественне провидіння :-)
Да ну, это ваще никак не тянет на empire strikes back. У линуса действительно наброс так наброс, тут какое-то невнятное "а я вот тут писал на С++ и все работало", тьфу.
ReplyDeleteКстати, кто этот Стивен вообще? (кроме как автор пары книжек по C++)
Правильно Лінус каже, я взагалі підозрюю що класи з їх віртуальними функціями придумали тільки для того, щоб гарно написати GUI, а шаблони - щоб гарно написати STL
ReplyDelete2nahtigal: ну з божественним провидінням ти мабуть погарячкував :). Згоден - річ безумовно корисна, але ж і дещо складніша за звичайне ООП
ReplyDelete2lrrr: да ну, это ж такой довольно взвешенный 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
Yuriy Volkov:
ReplyDeleteсфера застосування шаблонів та класів не обмежена лише GUI & STL
Згоден, але що таке клас? Клас - це опис конструкції обєкту. Обєкт - це елемент системи що виконує певні функції (має призначення). Конструкція обєктів визначається на етапі розбиття одної складної задачі на багато простих задач. Це розбиття, я думаю, і є обєктно орієнтованим програмуванням, а використання класів чи просто структур даних це є "дизайн" коду програми.
Про шаблони я взагалі мовчу. Ті "концепції", що вони ввели в новому стандарті, самі за себе говорять (шаблони були мутні, стали ще мутніші).
Мій висновок:
Комусь подобається використовувати класи, комусь не подобається, але факт шо без класів можна писати нормальні програми, чого не зробиш наприклад без функцій і модулів, бо класи - це не метод програмування а лише дизайн коду програми.
2Rembo:
ReplyDeleteКонструкція обєктів визначається на етапі розбиття одної складної задачі на багато простих задач. Це розбиття, я думаю, і є обєктно орієнтованим програмуванням, а використання класів чи просто структур даних це є "дизайн" коду програми.
Слідуючи усталеним інженерним нормам я дотримуюсь думки що процесс розробки будь-якої системи складається з декількох етапів:
1) requirements analysis
2) системний аналіз та декомпозиція цілей та задач
3) проектування
4) реалізація
5) .....
Визначення конструкції об'єктів відповідає якраз пункту 3, а все інше відноситься до методів реалізації - реалізувати конструкцію у вигляді класу, який інкапсулює у собі дані та методи роботи з ними и реалізує певну поведінку, чи у вигляді структур данних та алгоритмів їх обробки.
Що ж до того, що без класів можна писати нормальні програми, то тут важко не погодитись, бо маємо досить велику кількість вже написаного коду, котрий і працює добре і супроводжується, здається, непогано =). На мій погляд класи - це лише спосіб вираження своїх, так би мовити, думок у вигляді коду.
Yuriy Volkov:
ReplyDeleteкласи - це лише спосіб вираження своїх, так би мовити, думок у вигляді коду.
Напевно мені цим і не подобаються класи - вони нав"язують спосіб мислення. Іншими словами класи обмежують свободу мислення, напрягають тебе думати якимось high-level, хоча, в принципі, до цих пір не винайдено нічого більш high-level-ого ніж C.
так, можливо. С++ складніший за чистий С, тому код потребує білше уваги під час проектування та реалізації. А з приводу того, що до цих пір не винайдено нічого більш high-level-ого ніж C я мабуть утримаюсь від коментарів, щоб не розпочинати ще одну священну війну ;). Программери з функціонального світу теж мабуть мають що сказати з приводу імперативщини :).
ReplyDeleteПро функціональне програмування згоден, я не точно висловився бо мав на увазі такі нововведення як класи і шаблони С++ в порівнянні з С.
ReplyDelete