Интервью Bjarne Stroustrup

Забавно конечно, но мало вероятно. Года полтора-два назад я читал, что то подобное но про чистый С. К сожалению исходной доки у меня не сохранилось. :( Речь там шла о том, что С был разработан как первоапрельская шутка и названия получил как продолжение извращеных диалектов языка Pascal(назывались они A, B). :)) Оформлено это было, как заявление Ричи, Томсона и Кернигана на некой конференции. Вот так вот...

уважаемый Бьярн Страуструп судя по всему был весьмяа пьян...(если он это говорил) или фраза "прошу извинения за возможные ошибки в переводе" оставляет надежду что Блузман просто бредит...

Это все грязные происки паскалисов. :)

Приятно, конечно, что данный опус вызвал эмоции,
но не кажется ли почтенной публике что проблемы
M$Windows описаны очень узнаваемо? А насчет
немеренного размера конечного продукта вроде тоже
звучит убедительно (вроде очевидно?, что чистый С будет
давать запускаемые файлы много меньших размеров, так
как жестче привязан к конечному представлению программы
в машине. а С++ программа может иметь совершенно не
машинную логику. Иначе говоря, чтобы написать эффективную
программу нужно все-равно думать о том как это будет
затем работать с имеющимися библиотеками). Насколько
я слышал, сопровождение больших программ на С++ и их
переносимость --- весьма нетривиальная задача.

Ну а насчет достоверности текста, разве это серьезный
вопрос для мыслящих людей?

Понятно что это интервью шутка, тем более что это выясняется за 30 сек не принужденного поиска по сети: http://www.research.att.com/~bs/bs_faq.html#IEEE Тому кто говорил, чтo у С++ результируюший код будет обязательно больше http://www.research.att.com/~bs/bs_faq.html#Hello world PS Читайте источники

http://www.haha.ru/index.htm Там есть упомянутая статья-шутка.

Между тем в каждой шутке есть доля шутки...
Узнаваемы проблемы не только M$, но и Mozillы,
на сайте которой можно как раз почитать про переносимость C++
( http://www.mozilla.org/hacking/portable-cpp.html ), загибая
пальцы по don't use.
Правильного в этой пародии довольно много, как в применении к
большим, так и средним проектам. 

Плохонькая издевка недоучки, а не шутка. Вот, кстати, ответ B.S. "Did you really give an interview to IEEE in which you confessed that C++ was deliberately created as an awful language for writing unmaintainable code to increase programmers' salaries? Of course not. Read the real IEEE interview. http://www.research.att.com/~bs/ieee_interview.html " P.S. Классная фразочка из интервью с B.S., для тех, кто не научившись граматному ООП, начинает гнать пургу про С++: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off." :)) Вот отсюда ноги и растут, а точнее, у некоторых, уже не... :)))

Я как-то не рассмотрел недоучек - по "ихонней статье про ихоннюю индустрию" судить об этом трудно. А интервью для АйЯйЯй высьма и весьма выдержанное. И вряд ли вообще стоит начинать такие (С vs. С++) треды - пустая трата времени. Вероятно от безделья - никто не обсуждает PHP vs. Zope (или perl vs. python ) - просто зарабатывают на жизнь. Может быть какой-то смысл имело бы обсуждение "С++ в проекте GNU", но похоже что предмет спора отсутствует.

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

В конце-концов новичков в С++ волнуют и философские проблемы языка.

Здесь - пустая трата времени. В самом верху недвусмысленно написано - "для поднятия тонуса". Нужно идти на сайты живых полезных проектов, лезть в их CVS, смотреть багрепорты и читать мэйлинг-листы (которые тоже относятся к ресурсам, но игнорируются). Есть style и developers гайды - это более подходит под "философию". Причем практическую и инструментальную, в отличие от учебников. Которые тоже надо не манкировать, а перечитать как-нить по второму разу.

Кто ясно мыслит - тот ясно излагает. логика и математика науки точные. формализация языка - до абсурда - Вот истина !!! с уважением Виктор

Так грамотно написано, что я чуть было не поверил в это :(( Статья придумана, судя по всему, профессионалом в области программирования и в ней здравого смысла больше, чем может показаться на первый взгляд. А как ловко человек воспользовался именем B. Strоustrup'а??

Видимо товаришч поучаствовал в проекте на 100 модулей, остался жив, подлечился, переквалифицировался в журналисты и пишет теперь такие пародии. Бодриться с С++ можно только после небольших шабашек (в основном на Qt и/или других ГОТОВЫХ библиотек классов ПРМЫШЛЕННОГО качества, с документацией и др.). А вот "С++ в GNU", точнее его редкое применение - это тема...

Интервью абсолютно правдивое :)
Пусть с ехидством, пусть не Страуструпа но чистая правда.
Объектно-ориентированное програмивование извращение ума
и когда нужно делать дело не подходит абсолютно.
(кстати абсурд сравнивать perl и python это все равно
что сравнивать гиганта с карликом).

Если кому надо style-guide - можно использовать CoreLinux++ (искать на freshmeat)- там правда все по-английски, но достаточно скурпулезно изложены концепции строго об[ектно-ориентированного программирования на C++ (да и для любых других языков сойдет). Доки расчитаны на профессионалов и больше похожи на набор заповедей или правил какой-либо софтверной компании (там нет слов о пончиках тещи одного из авторов). Там все очень отполировано. Я бы не сказал, что я согласен полностью со всем этим (слишком там все строго). А так - приведенное "интервью" - очень глупо. Я лично торчу от C++ (последнего стандарта августа 1998го и STL в частности). Те, кто говорит, что С++ это дерьмо - посмотрите на код Mozilla и попробйте представить, какой бы он был, если бы он был написан на С (и как геморойно его было бы изменять). Большинство из тех, кто ненавидит С++ либо вообще не на чем ни программировал (чисто юзер/админ), либо ему не хватило времени/ума освоить С++ и написать на нем чего-нибудь длиннее чем 1000 строк. И не надо путать недовольство реализацией С++ с недовольством к С++. Ну а величайшим достоинством ООП яв-ся абстракция (то есть ассоциация структуры данных и методов, связанными с этими данными) - то есть вызвать метод FOO у об[екта по имени BAR - записывается BAR.FOO(), а не BAR_foo(). Абстракция свойственна человеческому мозгу - поэтому она облегчает разработку софта. Полиморфизм (наличие у некоторых классов метода с одинаковым названием) еще более облегчает программирование (по крайне мере запоминание названий функций). Инкапсуляция тоже полезна. Наследование - тоже ничего. В целом использование ООП позволяет переложить часть рутинной работы на компилятор.

Код Мозилы я видел и видел как она работает. Немного лучше Оперы
ИМХО. Код Нетскапе я тоже видел на C между прочим и видел как он
работает - конкурентов не имеет несмотря на то что далеко не все
гладко.
Абстракция и полиморфизм для тех кто действително в жизни не написал
еше пары десятков тысяч строк кода это кажется самым гениальным и
заманчивым. Hardcore программеры наоборот кривятся от слов OOP
особенно когда речь идет о времени, отвечают как правило "только
за большие деньги". (Сталкивался с этим не раз уже).
Наивно думать что абстракция свойственна человеческому мозгу поэтому
давайте ее везде использовать. Абстракция и вообше надуманность и
мудренность вредят. Вредят дико работе. Это я могу заявит как
окончивший МехМат если кто знает что это такое было.
Статья перечисляет в шутку все серезные минусы OOP
memory leaks, long learning curve, long project development,
non optimized code ... etc etc etc
Все это чистейшая правда.
В обшем можно говорить и говорить на эту тему.
На моем опыте никогда не удавалось завершить C++ проект так как
хотелось бы. А подбирать чужой проект уже написанный, чтобы его
содержать я уже не буду ни за какие коврижки. предложу переписать
на C сначала.
(Да для того чтобы определится с квалифицированностью...
2 года назад у меня был 4х летний опыт работы на OOP, C++
проектами то есть к теперешнему моменту он бы был 6 летний
если бы я не подвел 2 года назад для себя черту под занятием OOP)

Первый раз слышу словосочетание "hardcore программеры" (скорее всего это те, которые пишут ядра и демоны). Мне кажется, что по крайней мере демоны - софт требования (приводящие к измененени внутренних структур данных) к которому увеличиваются намного реже, чем для пользовательского софта. Поэтому писать их на С не намного сложнее чем на С++ (раз нахрапом написал - можно потом забывать, как там все устроено). А к пользовательскому софту требования меняются гораздо чаще. Поэтому выгоднее его писать на С++. Наверное наибольшая проблема ООП - то что трудно правильно спорэктировать архитекуру классов (может просто некогда думать), да и не все области хорошо подходят для вписывания их в ООП рамки. По крайне мере писать с использованием чужих С++ библиотек, которые умно спроектированы, гораздо легче, чем с использованием С-шных (также умно спроектированных). Насчет абстракции: ядро линуха и unix API использует эту абстракцию (например - функции read, write работает и с сокетами, и с дескрипторами файла) (иначе было бы как в винде - одна функция для чтения из файла, одна - из сокета (по-моему там так)). Само дерево каталогов файловой системы - тоже можно в большой степени считать абстракцией (/usr/bin/login вместо /the-login-program). Даже то, что ты покупаешь пиво в магазине, а не делаешь его сам - тоже абстракция (ты знаешь, какими свойствами обладает об[ект, и поэтому его используешь). То, что если на бутылке написано пиво и неизвестная тебе марка - дает тебе право надеется, что там что-то похожее на пиво по вкусу (это наследование или полиморфизм). Было бы хуже, если бы на бутылке было написано "балтика" и не было бы написано "пиво". При ООП пространство имен тоже меньше загрязняется и дает возможность использовать более осмысленные имена для методов и членов, не содержащие префиксы и суффиксы. ЗЫ: "Стаж" у меня такой же.

Прочитайте сначала мое сообщение ниже. Вот еще примеры элементов ООП в повседневной жизни, но менее пищевые. То, что все gnu'шные программы имеют опцию командной строки --help, --version можно считатть полиморфизмом (у разных классов имеются методы с одним именем) (и это удобно!). То, что вместо /usr/bin/make можно написать make это удобно! (примерно та же экономия при реализации методов класса или при использовании пространств имен и глобальных функций в С++). То, что можно делать "cp file1 file2" и "cp file dir" можно считать перегрузкой имен (несколько функций имеют одно имя но параметры различных типов) - иначе бы пришлось писать "cp file1 file2" и "cp-to-dir file dir". Программу 'tar' можно разценивать как об[ект, имеющий несколько методов - 'c', 'x', 't' и др. - это абстракция (иначе пришлось бы писать tar-c ..., tar-x ...). Итого: принципы ООП облегчают работу (человеку). Можно писать ООП код на С (например - ядро linux'a), но на С++ ООП код писать легче, так как помогает компилятор (не надо . инициализировать вручную таблицы указателей на функции). Мне кажется, что софт, предметная область которого трудно вписывается в ООП рамки, можно писать в полуфункциональном стиле, но все равно IMO удобнее использовать ООП библиотеки, чем не-ООП. А, блин, еще один пример: параметры функций со значениями по умолчанию (тоже есть в С++): если бы такого не было в команде echo, пришлось бы явно указвать, что нужно присоединять \n к строке, не надо интерпретировать \-последовательности (то есть явно указывать то, что мы подавляем флаги -n и -e). Все это освобождает человека от нудной машинистской работы и потенциальных опечаток). И при программировании на С++ не обязательно использовать все концепции ООП - можно использовать его как С (с сильной проверкой типов), но также вовлечь шаблоны, пространства имен, аргументы функций по умолчанию, перегрузку имен, инлайн-функции. Я люблю говорить так: лопатой научиться работать намного проще, чем экскаватором, но и производительность труда тоже сильно различается.

2hvv-1: Как можно так чудовищно саморазоблачаться?
> величайшим достоинством ООП яв-ся абстракция
У Страуструпа в интервью из Айяйяй: So what is OO? ... I tend to
equate OOP with heavy use of class hierarchies and virtual functions
> абстракция (то есть ассоциация структуры данных и методов,
> связанными с этими данными)
Связывание данных и методов - это модульное программирование,
известный принцип Парнаса 1972 года, но не более. Этого мало даже
для создания абстрактного типа - нужно еще уметь экспортировать его
определение и создавать его экземпляры.
> Полиморфизм (наличие у некоторых классов метода с одинаковым
> названием
Это перегрузка, а не полиморфизм. Полиморфны переменные, и функции с
полиморфными аргументами.
> Наследование - тоже ничего.
Все, а не ничего - смотри выше "...heavy use..." Иначе просто не стоит
огород городить. Работа без наследования в С++ (класс==тип) есть
просто работа с типами пользователя (например с векторами, матрицами,
тензорами), а не ООП. 

2hvv-2:
> Наверное наибольшая проблема ООП - то что трудно правильно
> спорэктировать архитекуру классов (может просто некогда думать)
ГЕНИАЛЬНО!!! (== ПОЛНЫЙ П@#$%Ц!!!, простите за такое слово).
После этого обсуждение ООП можно сразу закрывать.
> да и не все области хорошо подходят для вписывания их в ООП рамки.
Страуструп тоже так думает: ... not every problem is best approached
with a primary focus on objects.
> То, что все gnu'шные программы имеют опцию командной строки --help,
> --version можно считать полиморфизмом (у разных классов имеются
> методы с одним именем)
С 4..6-летним стажем принять функцию (даже не шаблон)
main (int argc, char **argv) за класс с методами? Нет слов!..
Наличие --version у GNU-программ нужно считать не полиморфизмом,
а уважением к autoconfу. Если КАЧЕСТВЕННО писать для GNU, а не для
"Линукса-only", им необходимо пользоваться и либо ограничиваться
portable-cpp с Мозиллы, либо честно предоставлять альтернативы для
всех HAVE_feature. Посмотрите The official GNU autoconf macro archive.
Вряд ли туда заглядывали те, кто от С++ тащится взахлеб. 

!!!
Браво anonymous!
Ответ твой без сумления солиден.
Мне нечего добавить :)
Даже сторонники C++ с огромным опытом ошибаются в идеалогии,
что тут можно говорить.
P.S. hardcore програмеры это маньяки програмирования, не удивительно
что не слышал потому что в России их мало.
Пример разработчики Quake или Myth2 (3-4 програмера по сути дела).
Я вот недавно познакомился с людьми которые в Sun спортировали
Solaris на x86 - тоже 3 человека, они сейчас архитекторы в фирме
(ведут проект на Java/C ругаясь на Java матом и все настоятельно
клонят в сторону C. Стонут от Java но пишут... Такой архитектор
делает bugfix в течении 2-3 часов... Вот это hardcore)

От чего же вы пришли в восторг, Tima ?
>> величайшим достоинством ООП яв-ся абстракция
>У Страуструпа в интервью из Айяйяй: So what is OO? ... I tend to
>equate OOP with heavy use of class hierarchies and virtual functions
Разве это не одно и то же ? Что же тогда по вашему виртуальная функция, как не абстрактный метод ?
>> Полиморфизм (наличие у некоторых классов метода с одинаковым
>> названием
>Это перегрузка, а не полиморфизм. Полиморфны переменные, и функции с
>полиморфными аргументами.
Ошибаетесь, дорогой анонимус - перегрузка, это несколько методов с одинаковым именем. Конечно определение hvv тоже не сахар, но оно ближе к полиморфизму.
>> Наследование - тоже ничего.
>Все, а не ничего - смотри выше "...heavy use..." Иначе просто не стоит
>огород городить. Работа без наследования в С++ (класс==тип) есть
>просто работа с типами пользователя (например с векторами, матрицами,
>тензорами), а не ООП.
Ну здесь вообще все ясно. У слова "ничего" есть по крайней мере два известных мне значения: ничего - пусто и ничего - хорошо. После хотя бы 10 лет общения на русском языке принять "ничего" в этой фразе за пусто ? Нет слов ! А придираться к словам - глупо и недостойно.
>> Наверное наибольшая проблема ООП - то что трудно правильно
>> спорэктировать архитекуру классов (может просто некогда думать)
>ГЕНИАЛЬНО!!! (== ПОЛНЫЙ П@#$%Ц!!!, простите за такое слово).
>После этого обсуждение ООП можно сразу закрывать.
Все правильно, трудно спроектировать -> нужна высокая квалификация -> не всем доступно. Почему надо закрывать обсуждение ООП ?
>> То, что все gnu'шные программы имеют опцию командной строки --help,
>> --version можно считать полиморфизмом (у разных классов имеются
>> методы с одним именем)
>С 4..6-летним стажем принять функцию (даже не шаблон)
>main (int argc, char **argv) за класс с методами? Нет слов!..
Я надеюсь, что это не придирка к словам, а либо неправильное понимание, либо неумение абстрагироваться. Вам не говорят об использовании класса в программах GNU, но говорят об иерархии вида 'программа GNU, от которой наследуются программы cp,rm etc., у которых один и тот-же метод ( ради бога не понимайте это буквально ) работает по разному (--help выводит разные сообщения у разных программ).
Tima: Статья перечисляет в шутку все серезные минусы OOP
>memory leaks,
Даже не хочется комментировать этот бред. Исходя из презумпции невиновности обвините C++ по всем правилам пожалуйста.
>long learning curve,
Правда.
>long project development,
Лукавство. На больших проектах дает выйгрыш в основном счет быстрой отладки. Ну а сопровождение быстрее на любых проектах.
>non optimized code
Ерунда. Посмотрите на выходы компилятора. Все механизмы в C++ это compiletime механизмы. Только прежде чем смотреть на выходы, включите пожалуйста оптимизацию.(В С++ компиляторах она тоже встречается).

Timur, C++ виновно :) обсуждать тут нечего.
1) Memory leaks плодятся как вши даже в неплохо разрабатываемом
проекте. Вылавливать их -- шило в заднице, особенно когда они
сделаны не тобой.
Если не сталкивался то это значит что либо не искал либо в больших
проектах не учавствовал.
От чего memory leaks? Все от этой сраной абстракции, полиморфизма
и наследования -- то есть от всего того что отличает C++ от C.
Так что действительно коментировать нечего.
2) "Быстрой отладки" не бывает как класса. Вообше. Счастлив тот
кто гробит на отладки 70% времени, в основном это 90%, тем более
на проектах с OOP.
3) Доводилось ли уважаемый наблюдать что делает стандартный C++
компилятор с проектом иерархией на 30 классов? Со всей оптимизацией?
Размеры бинарника не мерянные. C++ компиляторы делают более
медленный и более большой код чем C компиляторы. Это факт. Точно
так же C компиляторы делают более большой и более медленный код
чем Assembler. Это тоже факт.
Кстати на Unix free C++ компиляторов приличных нет в принципе.
g++ далеко не фонтан хотя поднатужившись прорваться можно. Об оптимизации
речь даже не заходит. Лишь бы собирало как надо.

Далее
> Разве это не одно и то же ? Что же тогда по вашему виртуальная функция, как не абстрактный метод?
Мне как то с трудом верится что ты понимаешь о чем говоришь если такие
вопросы задаешь. IMHO рекомендую почитать двухтомник B. Strustrup. Не
прилично тут как то на такие вопросы отвечать.
Чтобы не идти по списку дальше скажу просто:
У anonymous замечания все справедливы. "Не используйте слово abstract
i polymorf в суе. Вам этого не простят."

P.S.
>программа GNU, от которой
>наследуются программы cp,rm etc., у которых один и тот-же метод ( ради бога не понимайте это буквально )
>работает по разному (--help выводит разные сообщения у разных программ).
Не путайте грешное с праведным, божий дар с яишницей а интерфейс с полиморфизмом,
Пожалуйста.

Не надо считать собеседника за полного барана и придираться к словам. Честнее будет принимать гипотезу, согласно которой собеседник умнее чем ты думаешь.
>> Полиморфизм (наличие у некоторых классов метода с одинаковым
>> названием
>Это перегрузка, а не полиморфизм. Полиморфны переменные, и функции с
>полиморфными аргументами.
Ну, блин, оговорился: Полиморфизм (наличие у нескольких классов метода ...
То, что я сказал "классов", а не "класса", должно было привести к
мысли, что именно я имел ввиду.
>> Наследование - тоже ничего.
Я сказал "ничего", а не "ничто" (и правильно сказал - но кого-то это
могло сбить с толку).
Tima: ты сказал, что полиморфизм, наследование и абстракция - для
баранов (то есть что это не нужно). Я привел контрпримеры, приводя в
меру терпения комментарии. 

Спасибо, timur - ты правильно понял мои мысли. Со всеми твоими мыслям
я согласен.
to anonymous: насчет --help -= ну ты вообще сморозил. Напомню, я
доказывал, что абстракция, наследование и полиморфизм - вещи с которыми
мы часто сталкиваемся в нашей бытовой жизни и которые ее облегчают.
Ну ладно, к делу.
>1) Memory leaks плодятся как вши даже в неплохо разрабатываемом
   проекте. Вылавливать их -- шило в заднице, особенно когда они
   сделаны не тобой.
   Если не сталкивался то это значит что либо не искал либо в больших
   проектах не учавствовал.
   От чего memory leaks? Все от этой сраной абстракции, полиморфизма
   и наследования -- то есть от всего того что отличает C++ от C.
   Так что действительно коментировать нечего.
Полный бред. В C-шном коде memory leaks намного чаще встречаются. А
логичная организация классов и их методов (а также написание
деструкторов, которые правильно все удаляют) решают все проблемы. С++
позволяет сделать такой деструктор inline, что сэкономит вызов функции
(но сделает код больше). Правда, gcc позволяет использовать inline
функции и в С. Есть дохрена tools, которые отслеживают memory leaks.
>3) Про оптимизацию. Во первых - код, сгенеренный С++ не настолько
увеличивается, как ты рассказываешь. Большая часть дополненного кода -
из-за того что многие вещи inline (то есть работают быстрее, чем C
аналоги). Также само ООП заставляет грамотно писать код (в некоторых
ситуациях он может показаться лишним, но при длительном сопровождении
проекта только правильно написанный избыточный код, написанный "впрок",
спасает от постоянного переписывания ядра проекта). В третих, глядя
на участок С++ кода (исходника) можно сказать, какой будет
ассемблерный код. Следовательно, критические ко времени выполнения
участки можно написать так оптимально, как будет тебе нужно. (Не хуже С).
Еще про оптимальность: посмотри многие programming guide и style-guide
, везде написано, что человеческое (программистское) время дороже
машинного - что лучше написать логически более стройный (и более
гибкий), но менее оптимальный код. Идеализация - борьба за каждую
наносекунду - это пережиток советских времен. (Или чисто user'овский
подход - хочу быстрее и все). Надо свыкаться с мыслью, что если хочешь
быстрее - плати еще.
Про free C++ compilers (почему-то unix): я кроме g++ ничего не знаю -
может просвятишь? А коммерческих - туча (правдо чаще это очень умные
трансляторы С++ в С, но зато доступные для всех ОС). Так что для
коммерческого использования преград к использованию С++ вообще нет.

Насчет последнего твоего предложения (про яичницу) - см. начало моего ответа.
Чем бы это ни было - это черты ООП, облегчающие нам жизнь. 

По моему слово бараны я не употреблял.
И не хотел.
Я хотел сказать что не смотря на всю красивую теорию OOP
а вместе с ним C++ и Java не являются эфективным и дешовым
решением задач.

hvv еще раз попрошу не путать жизнь с абстракцией так в
сумашедший дом попадают, серьезно.
А про memory leaks до появления C++ никто слыхом не слыхивал
а C старее C++ на 15 лет по хорошему.
>Еще про оптимальность: посмотри многие programming guide и style-guide
>, везде написано, что человеческое (программистское) время дороже
>машинного - что лучше написать логически более стройный (и более
>гибкий), но менее оптимальный код
Мама моя родная!!! Это гдеж такое написано??
Вот после таких гайдов атомный крейсер на буксире ташить приходится.
Ракеты не попадают в цел. Окошки закрываютья с blue screen.
И наступает мир Микро$oft и RAD разработки.
Меня USA научила: делать надо отпимально точно и без глюков, время
которое потратишь не важно главное качество кода во всех отношениях.
>В третих, глядя
>на участок С++ кода (исходника) можно сказать, какой будет
>ассемблерный код.
Ээээ ты со сколькими вообше компайлерами знаком?
По моей практике каждый такое городит свое...
Ладно латер...

> hvv еще раз попрошу не путать жизнь с абстракцией так в
сумашедший дом попадают, серьезно.
Просто такой взгляд на вещи из далека и ИМО очень наглядно все показывает.
А про memory leaks до появления C++ никто слыхом не слыхивал
а C старее C++ на 15 лет по хорошему.
Да ну! Ты меня удивляешь. C - не garbage-collectable язык, позволю себе
заметить (да и С++ тоже) - leaks это проблема любого языка без сборки памяти.
А то, что о них не слышали до появления С++ (это 1990 г) - так просто
компьютеры были слабые, и поэтому не было такого сложного и большого софта, как
например word и corel. Да и машинное время ценилось больше, да и людей было
умных тогда больше в процентном отношении.
>Еще про оптимальность: посмотри многие programming guide и
style-guide
>, везде написано, что человеческое (программистское) время дороже
>машинного - что лучше написать логически более стройный (и более
>гибкий), но менее оптимальный код
Мама моя родная!!! Это гдеж такое написано?!
Во всех guide'ах. Например, в CoreLinux++, в gnumeric/HACKING, во многих
других. А для оценки производительности участков кода есть профайлеры.
И еще - программеры специально ставят tab на 8 пробелов (как в gnumeric,
linux kernel) - специально, чтобы не создавать больших функций (с большим
глубиной nesting) - это помогает писать более гибкий софт. Но менее
оптимальный.
Кстати, С++ со своим гарантированным наличием inline (вообще факт, что любая
inline-функция будет развернута, не гарантируется) позволяет избегать
использования сложных макросов, по крайне мере с очень длинными именами,
заменой на inline функции (можно шаблоные) с полной проверкой типов аргументов.
Вот после таких гайдов атомный крейсер на буксире ташить приходится.
Ракеты не попадают в цел. Окошки закрываютья с blue screen.
Ты путаешь надежность и оптимальность. Эти величины для сложного софта
зависят обратно пропорционально. К счастью, части кода, наиболее критичные
ко времени выполнения, достаточно невелики по размеру и часто не вписываются
в ООП (такие, как декодирование mp3).
И наступает мир Микро$oft и RAD разработки.
Согласен, что иногда дело доходит до маразма. Но рынок тут наказывает
продавца (если есть конкуренция).
Меня USA научила: делать надо отпимально точно и без глюков, время
которое потратишь не важно главное качество кода во всех отношениях.
Она так никого не учит - у них - лишь бы было конкурентноспособно и с
правильным маркетингом (вообще, это и есть оптимально, но с экономической
точки зрения). Но глюков желательно поменьше Ж:-)
>В третих, глядя
>на участок С++ кода (исходника) можно сказать, какой будет
>ассемблерный код.
Ээээ ты со сколькими вообше компайлерами знаком?
По моей практике каждый такое городит свое...
Я не говорю, что смогу сказать, в какой регистр что уйдет.
Для того, чтобы знать примерный алгоритм сгенеренного кода, достаточно
знать С++ и declarations классов, которые принимают участие в участке
кода. Все, что C++ компилер может добавить "от себя" - так это инициализация
указателя на таблицу виртуальных методов, и предков, ну и создание
временных обхектов, а также их уничтожение.. Главное - не использовать
исключения (exceptions) - иначе код будет пухнуть. Но exceptions уже не
классическое ООП, AFAIK.
Ну и практика показывает, что лучше иметь дело с как можно меньшим кол-вом
компилеров/трансляторов (в смысле, от различных поставщиков).

Предыдущее сообщение - от меня. Когда я его запостил, у текста от Tim'ы был отсут пробелов 6, да и было поддписано мной. Сейчас все отступы исчезли, и авторство почему-то изменилось на anonymous. To maxcom: если это сделано вами вручную, не плохо было бы это зафиксировать маленьким сообщеньицем.

>Я не говорю, что смогу сказать, в какой регистр что уйдет.
Еще раз повторяю, мало компайлеров видели.
Не то что про регистр не скажешь как баран на новые ворота
на код ассемблера будешь смотреть и чесать затылок "разве это
можно на ассемблере так сделат???". Примеры компайлеры HP, DEC,
Sun, да и тогоже Micro$oft.
Gcc единственный компайлер который генерирует читаемый ассемблерный код.

>Для того, чтобы знать примерный алгоритм сгенеренного кода, достаточно
>знать С++ и declarations классов, которые принимают участие в участке
>кода. Все, что C++ компилер может добавить "от себя" - так это инициализация
>указателя на таблицу виртуальных методов, и предков, ну и создание
>временных обхектов, а также их уничтожение.. Главное - не использовать
>исключения (exceptions) - иначе код будет пухнуть. Но exceptions уже не
>классическое ООП, AFAIK.
Очень наивная точка зрения.

>Ну и практика показывает, что лучше иметь дело с как можно меньшим кол-вом
>компилеров/трансляторов (в смысле, от различных поставщиков).
Да если бы это было возможно... Gcc замечательная вешь.

>Во всех guide'ах. Например, в CoreLinux++, в gnumeric/HACKING, во многих
>других. А для оценки производительности участков кода есть профайлеры.
>И еще - программеры специально ставят tab на 8 пробелов (как в gnumeric,
>linux kernel) - специально, чтобы не создавать больших функций (с большим
>глубиной nesting) - это помогает писать более гибкий софт. Но менее
>оптимальный
В этих гайдах написано что програмист не должен уделять временя
на ускорение работы программы и всяческого рода оптимизации?
Что время програмиста дороже???
Кстати разговор о проекте gnumeric отдельный и о его качестве.
У меня в vi таб стоит 8 пробелов по умолчанию.

>Да ну! Ты меня удивляешь. C - не garbage-collectable язык, позволю себе
>заметить (да и С++ тоже) - leaks это проблема любого языка без сборки памяти.
>А то, что о них не слышали до появления С++ (это 1990 г) - так просто
>компьютеры были слабые, и поэтому не было такого сложного и большого софта, как
>например word и corel. Да и машинное время ценилось больше, да и людей было
>умных тогда больше в процентном отношении.
Не было мошьных компьютеров???
Не было мошьных програм???
ИМХО вообще не представляешь о чем говоришь.
Windows и M$ Office шедеврами програмирования _не_ являются они
являются его позором. Как DOS как Xenix как SCO.
Люди писали код грамотней и думали о коде а не о class inheritance
virtual/abstract methods или полиморфизме потому и memory leaks
не было и garbidge collection вообще никому не нужна была.
Garbidge collection это друг и брат OOP -- признание OOP в импотентности
в борьбе с memory leaks. Типа пишите что хотите за вас все сделает дядя.
Маразм.
Кухарки за клавиатурой короче.

Насчет компилеров: ну и хрен с этим кодом. Главное чтоб работал. Если
качество оптимизации не удовлетворяет, берешь транслятор от KAI (он
С++ в С перегоняет с дикой оптимизацией) и компилишь полученый С-шный
код. Но я не думаю, что если копилер криво генерит код для С++, то он
будет генерить хороший код из С.
Насчет style-guides: именно так и рекомендуют. См. любую уважаемую
всеми книжку, там то же написано это.
Насчет gnumeric: как раз это хороший пример очень большого проекта
(правда он на С). Очень показательный пример.
Про memory leaks: раньше компьютеры с мощностью PII не были доступны
рядовым гражданам. Соотвественно не было сложного ширпотребного (
коммерческого софта). Поэтому проблема memory leaks так остро не стояла
(т.к. коммерческий софт был проще и менее сложен).
Я не называл msoffice шедевром - я привел его в качестве примера
большого и сложного (для написания) софта. К счастью, memory leaks
в нем не заметно, так как все писали на С++.

Насчет ООП подхода в С - можешь посмотреть код gtk. Так вот, там
своя система об[ектов, но так как это реализовано на С, программерам
приходится вручную писать код для инициализации виртуальных таблиц
"класса" и тд - геморой! Посмотри Motif, corba - это ООП на С.
Ну ладно, у меня времени нет этот чат разводить...

Супер - просто обалденно! Смело можно давать первую премию за сочинение в стиле киберпанка :) А еще, я бы сказал, очень похоже на Станислава Лема с его великими конструкторами. COOOOOL!!!!

Интересная картина - те кто не разбираются, обычно больше всего и критикуют. Так юникс, и в частности линукс, чаще всего критикуют те, кто не разу в глаза не видел. Также уважаемый Тима не разбираясь в ООП (он сам так сказал: "На моем опыте никогда не удавалось завершить C++ проект так как хотелось бы.") Так может проблема не в ООП? Так конечно проще - у меня не получается, значит это плохо и у всех не получится. > "Быстрой отладки" не бывает как класса. Вообше. Счастлив тот кто гробит на отладки 70% времени, в основном это 90%, тем более на проектах с OOP. Опять таже история, если "Быстрой отладки" не бывает как класса у Вас уважаемый Тима, это не значит, что всех так не бывает. У меня при хорошо обдуманном ОО проекте отладка занимает процентов 20-30 (точно не замерял) >Абстракция и полиморфизм для тех кто действително в жизни не написал еше пары десятков тысяч строк кода это кажется самым гениальным и заманчивым. Ну не правда. Написал я большой проект и полностью использовал наследование, полиморфизм и исключения (чтобы там не говорили про набухание кода). И работает. И не написал бы на Си за такой срок, и изменять так быстро на Си не получилось бы. >Hardcore программеры наоборот кривятся от слов OOP особенно когда речь идет о времени, отвечают как правило "только за большие деньги". Почитайте "двухтомник" Страуструпа. (Последняя редакция вышла в одном томе) Он там так и пишет, что опытные программисты на Си скорее всего встретят внедрение ООП в штыки. Это же их ставит наравне с начинающими, слишком многому нужно переучиваться. А вообще ООП нужно учиться. Как нужно учиться правильно писать программы. Не кидаться сразу программировать, а потом 90 процентов времени тратить на отладку. А сначала на бумаге выразить свои мысли, потом еще подумать, а потом уже приступать к кодированию. И по моему глубокому мнению ООП стимулирует к этому. Конечно написать плохую программу можно на любом языке, но когда язык и идеология программирования стимулирует к хорошему стилю - это хорошо. А насчет скорости выполнения программ, если у Вас действительно такой опыт написания программ уважаемый Тима, то Вы должны знать, что на скорость на несколько порядков больше влияет выбранный алгоритм и продуманность программы, а не эффективность оптимизации компилятора. Никакой компилятор не сделает медленный алгоритм быстрым. Есть такая поговорка - плохая жена, еще не повод говорить плохо о женщинах вообще, и о женах в частности. Поэтому Ваш плохой опыт в ООП уважаемый Тима, еще не значит, что ООП плох в корне.

Уважаемый rGlory, прошу заметить что мой опыт ООП это далеко не написание
не один год и не в университете для зачета по информатике.
Я ставлю жирный крест на ООП и утверждаю что не возможно закончит ни
один проект так чтобы быть им воплне довольным не по причине плохого
опыта, неумения и не знания что я делаю, а именно изза более чем полного
понимания что происходит. Высшая матеметика учит простой истине:
"В абстракции нет границ". Поскольку ключем ООП остается все таки
абсолютная абстракция (как уже многие ниже заметили) то не удивительно
что я когда возвращаюсь к ООП проектам частенько хватаюсь за голову
и говорю что все надо переделать потому что каждый раз появляется
представление на качественно новом уровне. Тот кто не сталкивался с
этим не может утверждать что он понимает ООП, не правда ли? ООП это
тоже самое что получается когда инженеры прикладного профиля лезут
в высокую красивую и глубокую науку математику из-за которой иногда
можно вполне здраво сойти с ума.
Смысл?
Никакого. Ведь цель прикладного инженера, в частности програмиста,
это конечный продукт, а не раскрашивание кода.
ООП приносит только ненужные проблеммы и именно раскрашивание кода
совершенно ненужными высокими материями которые вредят процессу
компиляции.
Применить "чуть-чуть" ООП в проекте а потом бросить и удовлетворится?
Написать один класс и сказать что написал объектно-ориентированную
программу? Уже звучит глупо не правдали?
Не менее глупо для меня звучит трата нескольких месяцев на разработку
дерева классов и спецификации каждого в отдельности а потом лишь начинать
писать код. А ведь именно это является настояшим ООП.
Очень интересный у вас опыт с отладкой уважаемый rGlory. Надо понимать
что я пишу код быстрее вас скорее всего, либо проекты у меня посложнее
потому что большенство програмистов тратят именно 70% времени именно
на отладки, прошу не путать отладку и исправление грамотических и т.п.
ошибок.
Предложение применять более быстрые алгоритмы интересно но не практично.
После университета я почти не использовал уже написанных алгоритмов,
потому что мне не собирались платить деньги за написание быстрой
сортировки, или метода Гаусса.
К сожалению все простые задачи уже решены, на наш век остались лишь
сложные.
Скажу более я еше не разу не учавствовал в проекте в которым уже сначала
было известна конечная цель. Все проекты вырастали из 0 потому что
были рожденны сушествованием проблеммы которую надо было решать. Как
ее решать сначала никто не имел понятия.
Так как же такие практические задачи можно решать на ООП? Как возможно
сначала разработать дерево классов если не ясно решение?
Начать с чего то, потом прилепить еще что-то, потом еще чуть чуть и еще...
В какой-то момент понимаешь что все надо было делать абсолютно по
другому и преходится переписывать весь проект.
Кто нибуть здесь переписывал C++ проект?
Ладно, думаю я уже достаточно обяснил причины непригодности ООП
для проектов "реального времени".
Надеюсь до всех дошло что я хотел сказать.

>Поскольку ключем ООП остается все таки абсолютная абстракция (как уже многие ниже заметили) то не удивительно что я когда возвращаюсь к ООП проектам частенько хватаюсь за голову и говорю что все надо переделать потому что каждый раз появляется представление на качественно новом уровне. Проблема черезмерной абстракции - это не новость. "Паралич анализа" достаточно закономерная вещь, и она не привязана к ООП как таковому. Искусство именно в том и состоит, чтобы вовремя остановиться. А переписать по новому можно практически любую программу. "В конце работы становится ясно, с чего ее нужно было начинать" Эта истина применима не только к ООП и не только к программированию. Но анализ и выявление абстракций позволяют доскональнее вникнуть в проблему и многие проблемы, которые при быстром кодировании становятся видны только на этапе отладки, выявляются на раннем этапе анализа. >Не менее глупо для меня звучит трата нескольких месяцев на разработку дерева классов и спецификации каждого в отдельности а потом лишь начинать писать код. А ведь именно это является настояшим ООП. Начинать писать код без ясной картины в голове еще глупее звучит. >Очень интересный у вас опыт с отладкой уважаемый rGlory. Надо понимать что я пишу код быстрее вас скорее всего, либо проекты у меня посложнее потому что большенство програмистов тратят именно 70% времени именно на отладки, прошу не путать отладку и исправление грамотических и т.п. ошибок. Я знаю что такое отладка и я не сказал, что пишу код медленнее. Но продуманность позволяет мне не писать лишний или неправильный код. >Скажу более я еше не разу не учавствовал в проекте в которым уже сначала было известна конечная цель. Все проекты вырастали из 0 потому что были рожденны сушествованием проблеммы которую надо было решать. Как ее решать сначала никто не имел понятия. Так как же такие практические задачи можно решать на ООП? Как возможно сначала разработать дерево классов если не ясно решение? Извините не верю. Написать программу, когда неизвестно, как она должна работать невозможно в принципе. Не важно используется при этом ООП, или нет. >Кто нибуть здесь переписывал C++ проект? Я переписывал. Начинал писать, останавливался и начинал сначала. Останавливался на той или иной стадии. При готов поспорить, что при использование функционального подхода не ускорило бы проект. Если вообще смог бы его завершить.

Pisat' kod bez idei v golove eto rabota sejchas y programistov takaja. (c)
Kod pishetsja potomy chto nado reshat' problemy a ne ot xoroshej guzni i jasnogo soznanija ili ydovol'stvija esli ygodno.
Izvestno chto programma dolgna sdelat', kak etogo dobitsja ni malejshego ponjatija ne sushetvuet.
Vot isxodnaja tochka. Vremennue ramki kak pravilo sgatu do ypora. V smusle rogu kruvit' budut mnogie esli poprosish bolshe
vremeni, xotja vremja dadut. Vpered.
Perepisuvat' Procedurno Orientirovannuju programmu gorazdo proshe chem obektono. Sporit' zdes' nechego.

Хорошо, давай посмотрим на проекты KDE и GNOME для Linux. Какой из них наиболее динамично развивается ? Правильно, KDE. А теперь задайся вопросом "ПОЧЕМУ ?" Я объясню тебе - KDE пишется на C++ и соответственно производительность во много раз выше. C++ и ООП являются ключами к эффективному программированию. Безоглядное отрицание ООП показывает лишь НЕУМЕНИЕ пользоваться инструментом. ООП - это прежде всего проектирование. Умно спроектированный ОО проект нет надобности переписывать, иначе проектировщиков гнать в зашей.

А ты конечно же "кульхацкер" ? Задолбали крикуны... :((

Melted Brain KDE развивается более динамично Gnome/GTK???
Ха Ха Ха Ха :)
Ну насмешил ты меня уважаемый.
Ты вообше в курсе современного Open Source Development?
Какие проекты идут, и какой рейтинг у проектов, ну и такое?
Или знаешь OSD по пиратским CD "Красная Шапочка 6.2" :))
В общем рекомендация: разобратся в том что говоришь
а потом приходить и выдавать заявления и в беседе учавствовать.
Пожалуйста, welcome как говорится.

И все таки спорщики меня так и не переубедили! C - язык подходящий для написания OS, утилит, драйверов но никак не для сложных графических интерфейсов и больших проектов. Пример тому gtk-шные исходники которые никак нельзя назвать удобочитаемыми расширяемыми и логичными. А про сам Gnome я вообще молчу...

Зря ты Артем с этим уродом MeltedBrain,
вообще как с человеком разговариваешь.
Имя его уже нарицательное, переводится
как особо вредный и злобный ламер.
Пусть сначала что-нибудь путное сделает
и под GNU GPL выложит. Ну аналог FineRider
например. И не забудет кликуху сменить :-)
Трудно с человеком под матерной фамилией
общаться.
 

То Tima & others: не наезжайте на MeltedBrain по поводу его сообщения в этом форуме - оно содержит хоть какие-то аргументы, а ты, Тима, приводишь лишь свои впечатления и ничего более. Да, ООП - сложно. Да, не всякая предметная область ложится на ООП-рельсы. Но gui - прекрасно ложиться. Или ты что-то имеешь против (правда С-шных, но сделанных с ООП подходом) Xt, Motif, gtk+, groff (man formatter)? И еще - KDE пишут большей частью студенты, изучающие С++ - поэтому такое низкое качество. И еще: если человек не шлет постоянно сообщения в ответ на вновь появляющиеся - это не значет, что ты его переубедил - просто это культурный человек, не собирающийся разводть спор типа "Моя машина лучше" - "Нет моя!" - "Нет, моя лучше".

hvv да я тоже устал уже от этого спора, каждый все равно останется при своем. Опятьже могу снова с пеной у рта доказывать что GTK,Motif,groff(GNU nroff если об этом) объектного подхода не содержат а являються просто грамотно написанными программи на простом C, даже не на Object C вместе с CORBA. С КДЕ мне было все ясно с начала ее появления. Да, насчет аргументов, кроме собственных впечатлений и опыта тут аргументов не найдешь ведь именно про них и идет речь. По моему опыту интерьвью в шутку рассказывает именно те серезные вещи к которым приходят многие люди. Студентам это естественно кажется чушью, поэтому они берут QT и пишут KDE, смотрите что получается.

Я одни из скромных anonymous, кому Ваш спор
весьма интересен.  Если попытаться найти общий
знаменатель, то вроде получается так:

C++ --- способ экономить время программиста
более лаконичной формой записи программ (предположим,
что новое мировоззрение тоже "форма")
Реальная суть (и основной труд) лежит в библиотеках, 
используемых программистом.
Если все было хорошо продумано заранее (иерархия классов), 
 то результат может быть приличным.
Проблемы начинаются при попытках реализации
идей не зашитых (хорошо бы понять как такие
идеи сразу отличать) в исходную библиотеку.
При этом добавить в уже готовую библиотеку
способность хорошо работать с новыми идеями
практически невозможно.
Возможно, примером будет попытка реализации
на KDE какого-нибудь драйвера?
Мне не совсем ясно --- как понять какие "идеи"
уже зашиты в библиотеку, а какие все испортят 
 (и начнутся падения, утечки памяти и прочие глюки). 
 Да, если можно, при ответе, нельзя ли само
это представление описывать профессиональными
терминами (а не моими, ламерскими).

 

ну ребята и поорали ..... Ничерта не понимаю , причем тут ООП , причем GNOME , причем KDE ..... Hу нравится человеку cpp , пусть пишет , нравится c , флаг ему в руки. Хочет эфективно , пусть asm юзает . Хочет динамично - forth -;). Лишь бы человек был хороший . А проблема cpp не в этой мурне (leaks ....) , а в том что UNIX и С родились вместе , а cpp не повезло. И ось на cpp написать можно , но как .... (писать то можно и стихи девушке). Круто перейти к template базовому классу ? Я к тому , что быть умным это классно , но еще K&R советовали - будьте проще , и все будет работать . (кстати cpp родился в году этак ~80) --- вопрос на засыпку : как сделать entry simbol'ом в бинарнике , метод класса ? ;)

>C++ --- способ экономить время программиста более лаконичной формой записи программ (предположим, что новое мировоззрение тоже "форма") Реальная суть (и основной труд) лежит в библиотеках, используемых программистом. Я не уверен, будет ли ООП программа короче (она может быть короче и может длинее). Чистая С программа теоретически работает быстрее, чем ООП на С++. Например процентов на 5. Дело не в этом. Проблема функционального подхода в том, что при росте программы существует тенденция к выталкиванию данных наверх (от локальных переменных к глобальным на уровне файла, затем глобальным на уровне проекта) При этом отслеживание зависимостей в большом проекте становится проблемой отнюдь не тривиальной. Что происходит при необходимости смены структуры данных? Нужно проверить не один десяток функций, которые с этими данными работают. При ООП больше времени уходит на дизайн (я думаю и в функ. подходе стоило бы тратить больше времени на продумывание). Но, если при объектном дизайне просто не получиться создать что либо путное, без досконального продумывания, то в функ. подходе очень велик соблазн сесть и начать писать программу сразу. При этом приводят такие аргументы: 1. у меня нет времени на обдумывание. Самообман. 5 минут потраченных на предварительный дизайн и продумывание обернется в несколько часов, потраченных на отладку и доводку. 2. Эта программа пишется на один раз, зачем мне тратить лишнее время? Таже история. Если программу не попросят доделать (или переделать) - скорее всего вообще не было смысла в написании этой программы. 3. у меня нет представления, как эта программа должна работать вообще - как я могу впроектировать иерархию классов? (Тима (c) ) Почитайте литературу по объектному моделированию. Разрабатываете макет программы. Вставляете заглушки в неважных местах. Проверяете. Выбрасываете макет (это принципиально) Разрабатываете снова. Зря потраченное время? Как бы не так. С помощью макета вы уже получите представление о том, как должна работать программа. В общем нет смысла пересказывать здесь литературу, вы можете прочитать сами (например Буч или тот же Страуструп) В общем ООП это не краткая форма записи, а форма записи более понятная и легче модифицируемая. Как бы с этим не спорили. Проверено на личном опыте. Мин нет.

Если проблема C++ в том, что родился поздно,
то почему тогда считается, что проекты на С++
сложнее переносить на другие архитектуры?
И насчет идей плохо релизуемых на С++.
Может это касается программ внутри которых
нет больших иерархий? Типа, зачем городить
огород с проектированием умных классов, если
все-равно не будет нужды устраивать цепочку
вложенных друг в друга понятий.
Но ведь, если это правда, то переносимость
должна быть прекрасная --- Вы определили самые
низшие понятия (машинно-зависимые), а дальше
идет иерархия.

Извините за сумбурность, просто когда общий
смысл неясен тут и Буч не поможет...
 

С++ появился в 91 году AFAIR. Метод класса нельзя сделать entry symbol'ом. Даже если бы и можно было, во-первых, его имя будет mangled каждым компилятором по-разному (то есть проблема с переносимостью между компилерами), да и во-вторых - стандарт C++ не предоставляет возможности его вызвать (если метод не статический). Указатели на члены для этого, но их entry symbol'ом не сделаешь. Выход: пишешь extern C void call_method(void* object) который вызвает метоl класса, и делаешь call_method entry symbol'ом (его имя не будет mangled).

С++ появился в 91 году AFAIR. Метод класса нельзя сделать entry symbol'ом. Даже если бы и можно было, во-первых, его имя будет mangled каждым компилятором по-разному (то есть проблема с переносимостью между компилерами), да и во-вторых - стандарт C++ не предоставляет возможности его вызвать (если метод не статический). Указатели на члены для этого, но их entry symbol'ом не сделаешь. Выход: пишешь extern C void call_method(void* object) который вызвает метоl класса, и делаешь call_method entry symbol'ом (его имя не будет mangled).