опять об c++ (программистское)

[avva]

Линус в очередной раз сказал, что думает о 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++. Никаких дешевых парадоксов, просто два разных смысла слова 'лучше'. Об этом как-нибудь в другой раз.

Comments

[dimrub.livejournal.com]

Я всего лишь вышел из функции, что может быть проще, написал }, а в рантайме на самом деле пошли плясать деструкторы всех автоматических объектов в этой функции.

Вот этим, например, и лучше :). Я не знаю, без чего мне тяжелей было бы жить, без, скажем, кофейной машины - или без мьютекса, который автоматически освобождается при выходе из скоупа.

[strangeraven.livejournal.com]

C++ по сути не просто язык программирования, а среда для создания множества диалектов.
Хороший стиль C++ - это программирование на одном из его осознанно выбранных диалектов.
Ну например, отказаться от исключений, виртуальных функций, т.п., и писать на "C с классами". По сути это портативный ассемблер и есть. Вполне себе диалект.

Если известно, на каком диалекте написана программа, то локальность и простота обеспечивается.

Умение выбирать диалект под задачу, не мешать разные диалекты в одну кучу, заставить всех участников проекта писать именно на этом диалекте - собственно в этом и скилл программирования на C++.

[nevsky.livejournal.com]

> ...два разных смысла слова 'лучше'. Об этом как-нибудь в другой раз.

Ах, на самом интересном месте!

[burrru.livejournal.com]

Думаю, важно местоимение. Пока это "я" и даже "мы", С и С++ сравнимы и у каждого есть свои преимущества. Но когда появляются "они", С++ выглядит более уместным.

[kohomologie.livejournal.com]

+1

[avva.livejournal.com]

Хорошо сказано. А почему - выглядит более уместным?

[chaganazana.livejournal.com]

>> Никаких дешевых парадоксов, просто два разных смысла слова 'лучше'.

Другими словами, все хорошо в своем месте и в свое время.

[rezkiy.livejournal.com]

А вот что писал г-н Торвальдс три года назад:

http://kerneltrap.org/mailarchive/git/2007/9/6/257267

[xsbos.livejournal.com]

Мне кажется, я уже никогда и ничего не смогу написать на Си.
Буду чесаться, пыхтеть и нервно оглядываться по сторонам.
А на плюсах смогу.

[amosk.livejournal.com]

Большинство тех кто ненавидит С++ писали на нем максимум мелкие утилиты.
Т.е. здесь срабатывает инстинкт ненависти ко всему чужому и непонятному (шовинизм).

С другой стороны, мне очень комфортно было на чистом С писать модули для Линукса. И я считаю что это правильное решение - использовать С для ядра.
Но именно работа с оборудованием и прочие задачи ОС и есть та граница, внутри которой С имеет преимущества над С++: полный контроль за ходом выполнения программы.
Весь прикладной (в терминах ОС) софт эффективнее писать на С++, а в большинстве случаев - на языках более высокого уровня (Java, Python, C#...)

А вообще я когда периодически переключаюсь с С на С++ и обратно, переключение на С происходит обычно безболезненно, т.к. разница слишком огромна и понятно что ожидать (вернее чего не надо ожидать :)), а вот при переходе с С на С++, вроде бы тот же язык, а не хватает разных мелочей, типа этих:
struct A {int a; int b;};
struct A a = { .b = 111 };
или
a = (struct A){1, 2};
или
int a[10] = { [5] = 1111};

Касательно перегрузки операторов, то эта фича расширяет контекст не более чем это делают таблицы виртуальных функций, которые повсеместно применяются в ядре линукса.
Так что речь Линуса как обычно не блещет объективностью. Ну просто невзлюбил он С++, вот и находит поводы его не использовать.

[avva.livejournal.com]

Помню, да. Но кстати в этот раз он лучше написал, чем в тот.

[yirmy.livejournal.com]

Вообще-то на любом языке можно писать хороший добротный код и можно писать ОЧЕНЬ гадкий код (write only software :)) - все зависит от того кто пишет. А из двух языков програмирования всегда лучше тот, на котором ТРУДНЕЕ писать гадкий код. Все остальное попадает в категорию "о вкусах не спорят".

[(Anonymous)]

И Линус такой медленный и C безнадежно устарел.

[(Anonymous)]

Для кого интересно лучше?

[yirmy.livejournal.com]

Я думал, что выразился понятно: для пишущего индивидума - на каком больше нравится - тот и лучше. У людей, которые должны чужрй код поддерживать мнение скорее всего будет другое!

[amosk.livejournal.com]

Так что лучше-то (по этому вашему критерию), С или С++? :)

[cryinstone.livejournal.com]

Мой бывший однокурсник, к-рый весьма хороший программист от б-га, в свое время создал монументальный труд по поводу "нехорошести" С++:
http://yosefk.com/c++fqa/ (http://yosefk.com/c++fqa/)
И - по большому счету, с ним трудно поспорить.

[ol [infoserver.ru] (from livejournal.com)]

а вот при переходе с С на С++, вроде бы тот же язык, а не хватает разных мелочей, типа этих:

struct A {int a; int b;};
struct A a = { .b = 111 };

или

a = (struct A){1, 2};

или

int a[10] = { [5] = 1111};

Только все это (за исключением первой строки) — не C, а нестандартное расширение, которое реализовано только в GCC.

[msh.livejournal.com]

Может он и detest, но ведь Linux kernel просто таки набит разным overloaded methods

Да вот прямо из соседнего окна

if (shost->transportt->user_scan)
error = shost->transportt->user_scan(shost, channel, id, lun)

эффект конкретно этой строчки - совершенно неочевиден, например, возвращаемое значение в разных имплементациях - разное.

[amosk.livejournal.com]

Читайте стандарт С ISO/IEC 9899:1999, параграф 6.7.8 Initialization

А насчет "реализовано только в GCC" - это так, но вините в этом компиляторы, которые не полностью реализуют современные стандарты :)

[rezkiy.livejournal.com]

в тот раз у него не было задачи аргументированно высказаться. Ему Какурин сказал что он программировать на С++ не умеет, нужно быот отбиваться:-)

[meshko.livejournal.com]

Точно!
Вообще репутация Линусовских рантов для меня навсегда подмочена его выступлением про дебаггеры.

Кстати читал недавно Google C++ Style Guide, подумалось, что на таком Си++ я, пожалуй, мог бы писать.

[creaturen2.livejournal.com]

+2 :)

[itman.livejournal.com]

And C is a largely context-free language. When you see a C expression, you know what it does.

Ага, три раза. Особенно макросы какие-нибудь завернутые. И так все понятно, что хоть плачь. Или некоторые конструкции, которые на плюсах очень компактные - на Си - страницы кода получаются. Опять-таки, практически полная невозможность автоматизации работы с памятью. Какой замечательный язык, право! Зато есть возможность греппать malloc и free!
PS: Единственное серьезное преимущество Си - простота и портабельность.

[meshko.livejournal.com]

В смысле чужая библиотека на Си++ лучше, чем чужая на Си?
Мне так не кажется, и вот почему: аккуратный Си, он у всех более или менее похож, а вот Си++ он всегда такой разный*. То есть Ваша прекрасня библиотека на Си++ может запросто не вписаться в мой прекрасный проект на Си++. Ну, скажем Вы любите умные указатели, а у меня от них зверская изжога?

__
* Казалось бы: при чем тут Анна Каренина?