опять об c++ (программистское)
Jun. 23rd, 2010 11:50 pmЛинус в очередной раз сказал, что думает о C++. Вот длинная цитата, но вообще-то стоит все прочитать.
Тогда я хорошо понимал, почему C лучше C++. Прошло четыре года, и теперь я хорошо понимаю, почему C++ лучше, чем C (сомневаюсь, что Линус об этом напишет). При этом я не отказываюсь ни от одного слова, и все еще считаю, что C лучше C++. Никаких дешевых парадоксов, просто два разных смысла слова 'лучше'. Об этом как-нибудь в другой раз.
One of the absolute worst features of C++ is how it makes a lot of things so context-dependent - which just means that when you look at the code, a local view simply seldom gives enough context to know what is going on.А вот что я писал четыре года назад :)
That is a huge problem for communication. It immediately makes it much harder to describe things, because you have to give a much bigger context. It's one big reason why I detest things like overloading - not only can you not grep for things, but it makes it much harder to see what a snippet of code really does.[...]
And C is a largely context-free language. When you see a C expression, you know what it does. A function call does one thing, and one thing only - there will not be some subtle issue about "which version" of a function it calls.
Одна из главных причин, почему C++ плохой язык: для этого надо сначала понять, почему C хороший. В чем состоит то свойство C, из-за которого его называют "портабильным ассемблером"? Дело не в том, что "близко к машине", и всё низкого уровня. Дело в том, что почти всегда в C эффект любой строки кода локален и очевиден. Когда я что-то делаю в C, неважно что, я очень хорошо понимаю, что именно происходит. Если я пишу x=y, я знаю точно, что происходит. Если я пишу f(...), я знаю точно, какая конкретно функция будет вызвана, я могу указать на неё пальцем, и я знаю точно, что произойдёт в момент входа в неё и выхода из неё. Если я выделяю память, я знаю точно, что она не исчезнет, пока я её не освобожу. Итд. итп. [...](это тоже длинная цитата, но не всё - см. по ссылке).
C++ - смесь разных принципов отношения к информации и средствам её прятать или открывать, которые доступны программисту; смесь, кажется, очень плохо продуманная. С одной стороны, полностью сохранён "низкий уровень" C, в том числе отсутствие сборки мусора, т.е. очень важный пример того, что заставляем программиста за всем следить и обо всём помнить. [...] Но, с другой стороны: полностью нарушен (я бы сказал, низвергнут с пьедестала и подвержен особо извращенному поруганию) этот самый принцип локальности поведения системы в ответ на строчку моего кода. Я всего лишь объявил переменную какого-то типа, написав "Typename varname;", но эта строчка может привести к вызову неизвестного мне конструктора, а за ним - кода сколь угодно, вообще говоря, сложности. Я всего лишь применяю известный мне оператор к переменной - а он, оказывает, overloaded у этого класса, и черт знает что на самом деле там произойдет. Я всего лишь вышел из функции, что может быть проще, написал }, а в рантайме на самом деле пошли плясать деструкторы всех автоматических объектов в этой функции. И даже и не буду начинать говорить про copy constructor и прочие подобные прелести.
Тогда я хорошо понимал, почему C лучше C++. Прошло четыре года, и теперь я хорошо понимаю, почему C++ лучше, чем C (сомневаюсь, что Линус об этом напишет). При этом я не отказываюсь ни от одного слова, и все еще считаю, что C лучше C++. Никаких дешевых парадоксов, просто два разных смысла слова 'лучше'. Об этом как-нибудь в другой раз.
no subject
Date: 2010-06-23 09:07 pm (UTC)Вот этим, например, и лучше :). Я не знаю, без чего мне тяжелей было бы жить, без, скажем, кофейной машины - или без мьютекса, который автоматически освобождается при выходе из скоупа.
no subject
Date: 2010-06-24 12:16 pm (UTC)Я просто люблю goto. Хотя и деструкторы на } - тоже люблю.
(no subject)
From:(no subject)
From:no subject
Date: 2010-06-23 09:14 pm (UTC)Хороший стиль C++ - это программирование на одном из его осознанно выбранных диалектов.
Ну например, отказаться от исключений, виртуальных функций, т.п., и писать на "C с классами". По сути это портативный ассемблер и есть. Вполне себе диалект.
Если известно, на каком диалекте написана программа, то локальность и простота обеспечивается.
Умение выбирать диалект под задачу, не мешать разные диалекты в одну кучу, заставить всех участников проекта писать именно на этом диалекте - собственно в этом и скилл программирования на C++.
no subject
Date: 2010-06-23 09:17 pm (UTC)Ах, на самом интересном месте!
no subject
Date: 2010-06-23 10:16 pm (UTC)no subject
Date: 2010-06-24 03:03 am (UTC)no subject
Date: 2010-06-24 07:02 am (UTC)no subject
Date: 2010-06-23 09:31 pm (UTC)no subject
Date: 2010-06-23 10:23 pm (UTC)(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2010-06-23 10:24 pm (UTC)Другими словами, все хорошо в своем месте и в свое время.
no subject
Date: 2010-06-23 10:32 pm (UTC)http://kerneltrap.org/mailarchive/git/2007/9/6/257267
no subject
Date: 2010-06-23 10:54 pm (UTC)(no subject)
From:no subject
Date: 2010-06-23 10:34 pm (UTC)Буду чесаться, пыхтеть и нервно оглядываться по сторонам.
А на плюсах смогу.
no subject
Date: 2010-06-23 10:50 pm (UTC)Т.е. здесь срабатывает инстинкт ненависти ко всему чужому и непонятному (шовинизм).
С другой стороны, мне очень комфортно было на чистом С писать модули для Линукса. И я считаю что это правильное решение - использовать С для ядра.
Но именно работа с оборудованием и прочие задачи ОС и есть та граница, внутри которой С имеет преимущества над С++: полный контроль за ходом выполнения программы.
Весь прикладной (в терминах ОС) софт эффективнее писать на С++, а в большинстве случаев - на языках более высокого уровня (Java, Python, C#...)
А вообще я когда периодически переключаюсь с С на С++ и обратно, переключение на С происходит обычно безболезненно, т.к. разница слишком огромна и понятно что ожидать (вернее чего не надо ожидать :)), а вот при переходе с С на С++, вроде бы тот же язык, а не хватает разных мелочей, типа этих:
struct A {int a; int b;};
struct A a = { .b = 111 };
или
a = (struct A){1, 2};
или
int a[10] = { [5] = 1111};
Касательно перегрузки операторов, то эта фича расширяет контекст не более чем это делают таблицы виртуальных функций, которые повсеместно применяются в ядре линукса.
Так что речь Линуса как обычно не блещет объективностью. Ну просто невзлюбил он С++, вот и находит поводы его не использовать.
no subject
Date: 2010-06-24 12:10 am (UTC)Только все это (за исключением первой строки) — не C, а нестандартное расширение, которое реализовано только в GCC.
(no subject)
From:(no subject)
From:no subject
Date: 2010-06-23 11:01 pm (UTC)no subject
Date: 2010-06-23 11:13 pm (UTC)(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2010-06-23 11:12 pm (UTC)no subject
Date: 2010-06-24 12:09 am (UTC)http://yosefk.com/c++fqa/ (http://yosefk.com/c++fqa/)
И - по большому счету, с ним трудно поспорить.
no subject
Date: 2010-06-24 04:43 am (UTC)(no subject)
From:no subject
Date: 2010-06-24 12:16 am (UTC)Да вот прямо из соседнего окна
if (shost->transportt->user_scan)
error = shost->transportt->user_scan(shost, channel, id, lun)
эффект конкретно этой строчки - совершенно неочевиден, например, возвращаемое значение в разных имплементациях - разное.
no subject
Date: 2010-06-24 02:45 am (UTC)Вообще репутация Линусовских рантов для меня навсегда подмочена его выступлением про дебаггеры.
Кстати читал недавно Google C++ Style Guide, подумалось, что на таком Си++ я, пожалуй, мог бы писать.
(no subject)
From:(no subject)
From:Или вот такое:
From:no subject
Date: 2010-06-24 03:30 am (UTC)Ага, три раза. Особенно макросы какие-нибудь завернутые. И так все понятно, что хоть плачь. Или некоторые конструкции, которые на плюсах очень компактные - на Си - страницы кода получаются. Опять-таки, практически полная невозможность автоматизации работы с памятью. Какой замечательный язык, право! Зато есть возможность греппать malloc и free!
PS: Единственное серьезное преимущество Си - простота и портабельность.
no subject
Date: 2010-06-24 04:48 am (UTC)Достаточно почитать код, например, какого-нибудь ffmpeg. Не поможет никакой grep и никакой ctags; там всё сплошь - косвенные вызовы через таблицы указателей на функции, да ещё и не всегда первого уровня. Да и выше по треду приведён пример ещё лучше - ядро линукса.
В общем, любой более-менее развитой проект на C однажды обязательно начинает использовать виртуальные функции ручного изготовления, а также обязательно заводит внутри себя две-три разновидности veryspecial_my_smart_malloc.
Хотя overloading, действительно, причиняет некоторые неудобства.
(no subject)
From:(no subject)
From:(no subject)
From:(no subject)
From:no subject
Date: 2010-06-24 05:43 am (UTC)no subject
Date: 2010-06-24 12:42 pm (UTC)no subject
Date: 2010-06-24 06:36 pm (UTC)Ха-ха :-)
В сишных исходниках одного очень серьёзного CAD'a в одном из модулей, по крайней мере, у функций отсутствовали прототипы, а для некоторых функций было несколько реализаций с разными сигнатурами.
no subject
Date: 2010-06-24 11:24 pm (UTC)А что Вы думаете о Delphi?? :)
Ответ
Date: 2010-06-27 09:23 am (UTC)no subject
Date: 2010-06-30 10:31 pm (UTC)C++
Date: 2010-07-20 04:42 am (UTC)