Справочник холиворщика по борьбе с C++

[:]||||[:]

любители C++ читать не умеют и доводов не понимают

> please consider this knowledge a kind of martial art - something a real master never uses.

Не катит. Меня вынуждают, ибо написание мегабайтов кода не укладывается в наше расписание.

P.S. Дальше читать не могу. Заплетаются пальцы, мысои и все остальное, что могет заплетаться ввиду превышения конуентрациии C_2H^5OH в крови.

обсудим, эээ... через погодя.. ;-) вот..

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

(Пора (уже (писать (справочник (холиворщика (по (борьбе (с (Лиспом)))))))))

Лиспоненавистники обычно лисп не асилили.

>Лиспоненавистники обычно лисп не асилили. Знакомо. "С++ кривой? Да ты его просто не осилил." (c) Фанатики С++. Что характерно, в отличие от приплюснутых, большинство тру-лисперов ничего сильно крупнее хелловорд на лиспе не писали :) Динамические языки общего общего назначения должны сдохнуть, их популярность сейчас не более чем причуда и понты (Lisp, Python, Ruby).

> перевести бы это все ...

+1. Я уже пытаюсь прогнать его через переводчик Google...

> любители C++ читать не умеют

А ненавистники Си++ не умеют писАть... на Си++ :-P

> (Пора (уже (писать (справочник (холиворщика (по (борьбе (с (Лиспом)))))))))

Ну так напишите. А мы почитаем...

> А ненавистники Си++ не умеют писАть... на Си++ :-P

А ещё они, как правило, не умеют заворачивать шурупы зубочисткой и вязать шарфики для для тараканов из золотой канители. И то, и другое, и третье — весьма занятные, но совершенно бесполезные умения.

>> А ненавистники Си++ не умеют писАть... на Си++ :-P

>А ещё они, как правило, не умеют заворачивать шурупы зубочисткой и вязать шарфики для для тараканов из золотой канители

А что, ненавистники Си++ умудряются ненавидеть еще и шурупы, зубочистки и золотую канитель? o_O Больные люди :D

А ненавидеть язык вообще довольно глупо. Ненавидят, как правило, тех людей, из-за которых приходится писать на этом языке. Начиная с самого Страуструпа, и кончая теми студентами-быдлокодерами, которые уверены, что С++ — венец развития ЯП, и из которых со временем вырастают быдломенеджеры и быдлопреподаватели, которые... и т. д. Если бы в тот же OCaml вбухали хоть 1% тех средств, которые вбухали в плюсы, мы бы давно жили в светлом бущем, блин.

> ненавидеть язык вообще довольно глупо. Ненавидят, как правило, тех людей, из-за которых приходится писать на этом языке.

Ненавидеть людей, которых не можешь убить, тоже глупо... А вот поди ж ты - мы их ненавидим :) Человек не всегда рационален.

> Если бы в тот же OCaml вбухали хоть 1% тех средств, которые вбухали в плюсы, мы бы давно жили в светлом бущем, блин.

Смешно... за Си++ никогда не стояло серьезных денег. Тут уж скорее речь о Яве.

>Если бы в тот же OCaml вбухали хоть 1% тех средств, которые вбухали в плюсы, мы бы давно жили в светлом бущем, блин.

OCaml действительно штука очень интересная. Появление F# от Microsoft Research не может не радовать.

У меня пока устойчивое впечатление, что OCaml-у катастрофически нехватает стабильного, хорошо продуманного и документированного препроцессора. Т.е. есть конечно Camlp4 (и его форк Camlp5), но по крайней мере после поверхностного ознакомления впечатление удручающее. После чтения ocaml-mailing-list, где разработчик camlp4 жалуется на директора, который типа не даёт ему нормально работать, становится совсем грустно.

> Смешно... за Си++ никогда не стояло серьезных денег. Тут уж скорее речь о Яве.

До Явы мы ещё доберёмся. =) А что касается плюсов — мало ли сил Microsoft убил на свой VC++? А g++? А всякие IDE, в каждом из которых свой парсер? А сколько сил потратил Trolltech на доведение плюсов до того состояния, чтоб на них можно было сделать графический тулкит? Они ж половину стандартной библиотеки переписали и половину языка перекроили. А Boost — целая толпа людей решает головоломки на плюсовых шаблонах. Столько человеко-лет, прожитых зря! По мне, так если хочется потрахаться, то и занимайся любовью, а не х.йнёй. =)

Давай whitespace и brainfuck вспомним?

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

Хуже С++ только ява.

> Давай whitespace и brainfuck вспомним?

Создай топик - и вспоминай, не вопрос.

> Люди, писавшие данный фак точно получше твоего разбираются в С++

Возможно. В любом случае, тебе виднее.

> Просто потому, что они подмечают вещи, которые тебе не доступны. Которые для тебя являются должностью.

Так они мне недоступны или являются для меня должностью? (или ты хотел сказать "данностью"?)

> Хуже С++ только ява.

Острое хуже твердого, это несомненно.

> А что касается плюсов — мало ли сил Microsoft убил на свой VC++?

ХЗ. Не думаю, что очень уж много - основные сложности компиляторов находятся в бэкендах, а бэкенд у MS наверняка общий для Си и Си++.

> А g++?

Первая версия написана одним человеком за несколько месяцев, IIRC.

> сколько сил потратил Trolltech на доведение плюсов до того состояния, чтоб на них можно было сделать графический тулкит?

Этой фразы не понял. Вроде бы тролли не занимались компиляторами? А если имеется в виду moc (так называется Qt-препроцессор?), то вряд ли это такая уж сложная штука.

> Столько человеко-лет, прожитых зря!

Во-первых, помни старую мудрость: "Nothing is ever a total loss - at least, it can serve as a bad example". Во-вторых, назови мне статически типизированные ООП-языки середины-конца 80-х?

>А всякие IDE, в каждом из которых свой парсер?

IDE становится необходим в любом достаточно крупном проекте (ибо отлаживать спомощью прогонов становится нереальным)

>А сколько сил потратил Trolltech на доведение плюсов до того состояния, чтоб на них можно было сделать графический тулкит?

а разработчики gtkmm много не трахались =)

>Они ж половину стандартной библиотеки переписали и половину языка перекроили.

зато на любых платформах работает. та же жаба или задротнет по скорости и обжорству ресурсов с qt не сравнимы.

>А Boost — целая толпа людей решает головоломки на плюсовых шаблонах.
>По мне, так если хочется потрахаться, то и занимайся любовью, а не х.йнёй.

(WALL) <--- апстенка здесь
а биореактор здесь ---> (CH_{4})

> Этой фразы не понял. Вроде бы тролли не занимались компиляторами? А если имеется в виду moc (так называется Qt-препроцессор?), то вряд ли это такая уж сложная штука.

Тот язык, на котором написана Qt — это уже не совсем C++. Trolltech сделал свои строки, и свои контейнеры, и свой ввод-вывод, и своё RTTI, и свой механизм управления памятью (подсчёт ссылок), и ещё много всего. Думаю, они бы и GC сделали, будь это возможно для C++. И на все эти вещи, которые нормальные языки предоставляют из коробки, и которые с основной задачей Qt — рисовать кнопочки и окошки — никак не связаны, ушло немало труда хороших программистов.

> Во-вторых, назови мне статически типизированные ООП-языки середины-конца 80-х?

Ада? Да и Objective C есть опциональная статическая типизация. :) Потом, 80-е закончились ещё в конце 80-х, если кто этого не заметил, то ССЗБ.

>и которые с основной задачей Qt — рисовать кнопочки и окошки — никак не связаны

А ты уверен, что это основная задача?

> IDE становится необходим в любом достаточно крупном проекте (ибо отлаживать спомощью прогонов становится нереальным) ЛОС! :D Вместо того, чтоб сказать: «Синтаксис C++ до того полон маразма, что даже компьютер не может в нём разобраться», плюсисты будут отмазываться и говорить, что автодополнение и подсказки для слабаков и неудачников. :)

> а разработчики gtkmm много не трахались =)

И поэтому gtkmm невозможно пользоваться без мата, в отличие от Qt. Ничем не прикрытая убогость C++ прёт там изо всех щелей.

> зато на любых платформах работает. та же жаба или задротнет по скорости и обжорству ресурсов с qt не сравнимы.

Я пока ни слова не сказал в защиту явы с дотнетом. В Трольтехе работают разумные люди, на их месте я бы тоже выбрал плюсы и тоже постарался бы доточить их до вменяемого состояния. Но это не значит, что лучших языков нет и не будет. Потом, от графической библиотеки требуется производительность и быстрая реакция на действия юзера. Отнюдь не всегда бывают такие жёсткие требования к производительности.

>> А Boost — целая толпа людей решает головоломки на плюсовых шаблонах. По мне, так если хочется потрахаться, то и занимайся любовью, а не х.йнёй.

> (WALL) <--- апстенка здесь а биореактор здесь ---> (CH_{4})

O_o Ты тоже из тех, кто предпочитает железную машину живому человеческому сексу? :P

> А ты уверен, что это основная задача?

Qt зародился именно как GUI toolkit. Это потом оброс всякими штуками и стал продаваться как «comprehensive solution for high-performance cross-platform application development». =) А что им ещё оставалось делать, если стандартная библиотека плюсов годится только для потрахаться, а не для программы писать?

Еще Eiffel.

>И на все эти вещи, которые нормальные языки предоставляют из коробки

огласите список "нормальных" языков, компилируемых (т.е. приложения которых сравнимы с плюсовыми в производительности при аналогичной функциональности)

Ada, D, Eiffel, Objective C, OCaml (в алфавитном порядке). :) Всё, кроме D, сегодня здесь уже называли.

>Ada, D, Eiffel, Objective C, OCaml (в алфавитном порядке). :) Всё, кроме D, сегодня здесь уже называли.

SBCL забыл

ADA, D, Eiffel, OCaml - со сборщиками мусора, т.е. медленнее по определению в любой реализации, Objective С - болото

> язык, на котором написана Qt — это уже не совсем C++. Trolltech сделал свои строки, и свои контейнеры, и свой ввод-вывод, и своё RTTI, и свой механизм управления памятью (подсчёт ссылок),

И? Это всё - библиотечные вещи, их маловато, чтобы говорить об изменении _языка_. Например, в Си их тоже нет. Может, APR - это особый диалект Си? ;)

> они бы и GC сделали, будь это возможно для C++.

Это возможно (Страуструп в своей книге говорит, что реализации Си++ с GC существуют). Более того , это входит в новый стандарт.

>> Во-вторых, назови мне статически типизированные ООП-языки середины-конца 80-х?

> Ада?

Нет. ООП - это Ада95, принятый в 1995 году :)

> Objective C

AFAIK, для ООП-фишек там _только_ динамическая типизация. По крайней мере, так было тогда.

> Потом, 80-е закончились ещё в конце 80-х

А некоторые до сих пор еще подходят с современными мерками к языкам, разработанным тогда :D

Vadim_Z

> Еще Eiffel.

ОК (хотя Эйфель, ЕМНИП, определен в 1988 году - т.е. позже Си++).

Итого: имеем первый широко распространенный статически типизированный ООП-язык, который сравнивают с современными аналогичными (и не аналогичными) языками и на этом основании называют дерьмом, забывая одну важную вещь - он был _первым_, благодаря именно ему ООП пошло в массы.

> забывая одну важную вещь - он был _первым_, благодаря именно ему ООП пошло в массы.

может и так, по истории у меня Э. Однако, есть более важная и насущная вещ: а насколько там ООП нужен, в мясах-то.

>со сборщиками мусора, т.е. медленнее по определению в любой реализации

"По определению" -- это научно доказанный факт или твои домыслы?

А ничего, что в С/С++ можно вусмерть зафрагментировать кучу?

>Это возможно (Страуструп в своей книге говорит, что реализации Си++ с GC существуют)

Страуструп выдаёт желаемое за действительное -- все существующие реализации GC для C++ косяковые. Эта тема очень хорошо раскрыта в FQA.

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

> ADA, D, Eiffel, OCaml - со сборщиками мусора, т.е. медленнее по определению в любой реализации

По какому такому определению? http://www.iecc.com/gclist/GC-faq.html#Folk%20myths

Потом, в большинстве языков есть и ручное управление памятью.

>А ничего, что в С/С++ можно вусмерть зафрагментировать кучу?

в этом вините "кошерный" dlmalloc и собственные руки

Вот ещё про GC: http://www.hpl.hp.com/personal/Hans_Boehm/gc/myths.ps

> А ничего, что в С/С++ можно вусмерть зафрагментировать кучу?

Всё нормально - это же почему-то не ставится в вину Си.

А компактифицирующий GC имеет свою кучу проблем (скорость, ага).

> Итого: имеем первый широко распространенный статически типизированный ООП-язык, который сравнивают с современными аналогичными (и не аналогичными) языками и на этом основании называют дерьмом, забывая одну важную вещь - он был _первым_, благодаря именно ему ООП пошло в массы.

И что, из уважения к Страуструпу мы должны ещё сто лет на нём писать? Появились языки лучше => С++ идёт в музей.

> все существующие реализации GC для C++ косяковые. Эта тема очень хорошо раскрыта в FQA.

Если верить FQA, GC для Си тоже невозможен - а он есть и работает. Это всего лишь еще один пункт, где FQA выдает желаемое за действительное.

> И что, из уважения к Страуструпу мы должны ещё сто лет на нём писать?

Ты уважешь Страуструпа? o_O Здесь в таком лучше не признаваться :D

> Появились языки лучше => С++ идёт в музей.

Чтобы отправить Си++ в музей, новые языки должны быть не просто лучше - они должны быть _гораздо_ лучше, причем по многим параметрам - не только чисто языковым но и технологическим (соместимость, инструментальная поддержка). Таких языков пока что нет - надежда на D пока не оправдывается, Cyclone - интересный, но мертвый.

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

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

>Если верить FQA, GC для Си тоже невозможен - а он есть и работает.

Такого вывода из FQA не следует. Напротив, там ясно сказано, что GC для С/С++ существуют, но имеют некоторые принципиально неразрешимые проблемы. Автора FQA можно обвинить в излишнем перфекционизме; в конце концов, тот же Hans-Boehm используется очень много где и как бы даже работает (хоть и является грязным хаком). Но я бы не стал использовать его в приложении с годовым аптаймом :)

Ты бы действительно, почитал бы чего-нибудь хорошего, доброго, светлого про GC. Зачем такой негатив гнать? Если говорить об индусе, у которого ненужные задержки в разных местах, то при ручном распределении памяти у него же будут ненужные сегфолты в разных местах, из-за утечек памяти. Это другая сторона реальности. По твоему она лучше? К производительности оба эти вопроса не имеют никакого отношения впрочем. По простому, у какой проги производительность выше, которая получает зезультат за 100 секунд, из которых 5 работает GC, или которая без GC получает тот же результат за 200 секунд?

> Появились языки лучше => С++ идёт в музей.

Увы, не всё так просто. Факт появления Linux не приведёт автоматически к вендекапецу, хотя Linux во всех отношениях лучше. Появление С++ даже не гарантирует, что не будут появляться языки намного хуже, что мы и наблюдаем.

нет, с ананимусами

>Теория оптимизации - лишь теория

православие головного мозга?

> Динамические языки общего общего назначения должны сдохнуть, их популярность сейчас не более чем причуда и понты (Lisp, Python, Ruby).

Динамические языки полезны там, где хардкодить неэффективно. Например, антиспам бот в Jabber клиенте. Вот взять, поправить ему код, если охота. Или сейчас в linux@ зачастили спамеры, зовут в getz. Поставить бы скрипт, чтоб мат генерил, а нету в Psi скриптов. Перезагружать клиент только ради изменения антиспам бота аляпо. Ну, или даже если это в динамически загружаемой библиотеке, отгрузить, пересобрать, подгрузить -- как-то сложно для такой простой задачи, не кажется? Да и компилятор держать на компе пользователя...

> Ненавидят, как правило, тех людей, из-за которых приходится писать на этом языке. Начиная с самого Страуструпа, и кончая теми студентами-быдлокодерами, которые уверены, что С++ ? венец развития ЯП, и из которых со временем вырастают быдломенеджеры и быдлопреподаватели, которые... и т. д.

Абсолютно согласен.

ero-sennin, как наткнулся на ресурс ?

> А Boost ? целая толпа людей решает головоломки на плюсовых шаблонах.

Есть один весёлый эмпирический закон : http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Я думал, это просто шутка. Пока не увидел эти самые turing-complete шаблоны, гордость C++.