• C++ programming Существует замечательный сайт C++ FQA Lite, в котором подробно и обстоятельно объясняются недостатки C++.
    yosefk.com

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

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

    love5an.livejournal.com

    По причинам 3, 4, 5, 9 и 10 C++ совершенно неприменим для системного и низкоуровневого программирования.
    А по причинами 1, 2, 5, 6, 7, 8, и, опять же, 9 и 10 — и для прикладного.

    У C++ нет области применения. C++ протух и умер. Хватит насиловать труп!
  • на чём предлагаешь переписать MongoDB?
  • @kb, на коммонлисп же. ну или си.
  • Дык. Я недавно разосрался со своим усердным коллегой — Он заявил, что кресты — язык системного программирования. Ну и чуть до рубки тексталем не дошло, да.
  • традиционный фейл в попытке обосрать плюсы.. посмеялся с пунктов 5 и 10 в контексте системного погроммирования..
  • @neFormal, Плюсолюбитель в треде, все в автобус. А по делу че сказать есть?
  • Местами согласен, но местами такие бредовые аргументы, что отбивают всякое желание спорить.
  • П. 8.2. вытекает как раз из того, что C++ задумывался как «мета-C», чтобы объекты могли повторять поведение классических сишных типов вроде всяких int. Отсюда и огород с возможностью передачи по значению и конструкторами копирования
  • @lovesan, там бред через пункт.. опять же "частые "internal error" в компиляторах" умиляют..
  • @asphyx, Ну да, но это бредовая фича. В итоге — ни Си, ни ООП.
  • @neFormal, Ну короче, у тебя бугурт, а сказать ничего толком не можешь. Понятно.
  • @lovesan, так я на плюсах не пишу.. так шта это у тебя.. +)
  • @lovesan, Тебя бьют плёткой и заставляют писать на "С с классами"?
  • @O01eg, :3
  • @neFormal, Судя по претензиям, он тоже на С++ не пишет.
  • @lovesan, а что можно сказать на "код плохо читается и его сложно поддерживать " тому, кто предлагает лисп использовать? Очевидно, ты неправильно его читаешь.
  • @lovesan, Человек, говорящий «короче, у тебя бугурт» в ответ на разумные аргументы, вообще не заслуживает того, чтобы с ним общались.
  • @O01eg, судя по слухам, пишет, но недавно.. тем более после лиспа очевидное отторжение..
  • Ну, С++ можно использовать для прикладного проргаммирования.
    Но совершенно непонятно, зачем.
  • @0xd34df00d, Да какие аргументы бредовые? Нихуя не вижу, вижу только "да там бред, ололо".

    Сейчас наверное еще кто-нибудь набежит и скажет "да ты не осилил". Ну а что на это отвечать?
  • @neFormal,
    Не пишу.
  • @lovesan, Ну вот, ч.т.д.
  • @0xd34df00d, строго говоря, аргументов пока не было. умиляют и бред — не аргументы
  • @kb, Лисп читается отлично, особенно с макрологией.
    Посмотри у меня проекты на гитхабе.

    А вот лес из треугольных скобок и двоеточий — вот это вот не читается.
  • Зато из плюсов плюсов: прямая компиляция в нативный код и относительно компактная стандартная библиотека (libstdc++ у меня весит меньше мегабайта, а libc не считаем, поскольку она есть всегда).
  • @lovesan, 1. Ты последний раз плюсы что ли видел в эпоху VC6, с internal compiler error'ами?
    2. Свои счетчики ссылок и все такое — ЛПП. boost::shared_ptr стандарт де-факто, std::tr1::shared_ptr почти стандарт де-юро.
    3. Городить классы с деструкторами ради выполнения кода при выходе из скоупа — ты идиот чтоле? Осиль идиому с boost::shared_ptr'ом и кастомным делитером.
    4. «Код плохо читается», «отладка затруднена» — а мне лисп не нравится, там скобочек много, напоминает тупых пезд со смайликами )))))))) Нутыпонел сарказм, я надеюсь? ;)
    5. Если тебе нужна ссылка, умеющая быть null — используй указатели. Ссылки не могут быть null by design.
    6. Дублирование си-функциональности — да, тебя прям заставляют юзать и то, и то. Это преимущество в известном смысле, чувак.
    7. Ты ниасилил vector<vector...> > и std::string? А в 0x и уникод есть.
    8. Проблема ромба не решается, ЩИТО.
    9. Отсутствие свойств — темплейтная обертка пишется на коленке за 2 минуты и реюзается всю жизнь.
    10. Магическое НАРУШАЮТ ИНКАПСУЛЯЦИЮ как мантра, фу.

    Это что сходу вспомнилось из твоего пста. Вот прям off the top of my head.

    С чем я согласен — отсутствие стандартов на ABI, хуеватенький RTTI, если не сказать больше,
  • @lovesan, А мне скобочки не читаются.
    Ты серьезно такие субъективные впечатления возводишь в объективность?
  • @lovesan, ты не понял моего комментария. Для тебя лисп читается отлично, для меня — это лес из скобочек. Это очень субъективно.

    У плюсов есть своя ниша, где нужна большая скорость и совсем непростая логика работы (ну, как пример — базы данных те же). И ручное управление памятью в этой нише является плюсом, а не минусом. В этой нише не обязательно пользоваться только стандартной библиотекой, тоже отпадает. Объектная система развита до той степени, которая позволяет все еще иметь высокую скорость (да да, попробуй вместо ООП на плюсах делать гномовский glib на Си, будет сильно медленнее, зато с интроспекцией).

    Шаблоны — тоже в минус засунуты, первая причина — замедляют компиляцию. Ну да, а ноги человеку весу добавляют, так что, в минус их тоже запихивать?
  • профессионал с++ сказал, что статья не рулет
  • Часть аргументов обоснованна (например про ооп), часть нельзя называть недостатками языка (например управление памятью), часть просто смешна (мифические частые internal errors, и пятый пункт, например). Хотел написать длинную простыню об этом, но потом решил, что это бессмысленно.
    Воспринимайте на правах баттхёрта — вам так проще.
  • @AKa, Логично, что человек, пишуший на лиспе под Win API, не может грамотно критиковать C++.
  • А если по делу:
    медленная компиляция
    А не похуй ли? Опять же, можно в го поиграть или там кофе попить, пока код коноплится.

    частые "internal error" в компиляторах
    Ни разу не видел, клянусь Императором.

    код плохо читается и его сложно поддерживать
    Легче чем тот же барсик, да и годных программистов на крестах найти просто.

    разбор кода различными инструментами, вроде IDE, и его генерация — сильно затруднены
    И, тем не менее, везде все работает.

    неудобства при работе с динамической памятью
    У тебя просто профиль рук не подходит.

    утечки памяти
    висячие ссылки
    сегфолты
    Сначала по рукам, а потом в еблище, пока думать не научатся.

    стандартные средства, как то malloc/new, работают медленно
    Используй системные. Ну там VirtualAlloc всякий и прочую поебень. Или не крути new в циклах.

    фрагментация кучи
    Мешает? Напиши свой аллокатор.

    отладка затруднена
    Но возможна. Чего еще надо?

    написание GC, по факту, невозможно,
    И не нужно. Я лучше компилятора/рантайма знаю, где мне что освобождать.

    Никакого ABI
    Нестандартизированный и непредсказумый name mangling
    Ага. So what? Пользуйся одним компилятором, и будет тебе счастье.

    Дублирование функционала Си
    Legacy код. У лиспа его нет, что говорит не в пользу лиспа.

    Стандартная библиотека убога
    Отсутствует даже такой функционал, как вменяемая работа со строками
    std::string, нет?

    и многомерные массивы
    Тебе не нравится int foo[100][500]; ? Тогда пиши сам.

    Юникод?
    wchar_t

    Слабая типизация
    Применение молотка для забивания гвоздей способствует травмам, забивай гвозди лбом.

    const не дает абсолютно никаких гарантий
    const_cast в коде? в еблище, в еблище, а потом по монитору рожей повозить.

    при этом система типов невероятно переусложенена
    хацкиль видел? вот там переусложнена. а тут просто сложная.


    практически никакой интроспекции
    а зачем?

    передача объектов по значению
    множественное наследование неудобно в использовании
    Наймите себе в контору штатного уебывателя за говнокод уже, чтоб ходил и В ЕБЛИЩЕ!

    исключения в конструкторах гарантированно влекут утечку памяти
    исключения в деструкторах тоже, и просто утечку — еще в лучшем случае
    деструктор можно вызывать до выхода из блока кода, или до delete
    Ну ты понял, кому куда надо уебать.

    одиночная диспетчеризация
    виртуальные методы в конструкторах не работают
    pure virtual function call
    сложности в случае с множественным наследованием
    деструкторы обязаны быть виртуальными
    никаких интерфейсов, только классы
    Ты что, личкрафтов обчитался?

    private, public и protected не дают никаких гарантий сокрытия данных
    Точно, обчитался личкрафтов.

    Да, кресты — это не тот язык, где можно покрыть хуями все тонкости и детали, запрыгнуть на коня и метнуться в атаку. Тут, блядь, думать надо.
  • ок, давай по мелким деталям:
    1. не согласен.. если не злоупотреблять макросами и шаблонами, то всё читабельно
    2. да, но про велосипеды — атмта.. называть язык говном изза великов — скудоумно
    5. эпическая глупость, т.к. это не является недостатком.. я уж не говорю про жалобы на дублирование функционала
    8. проблема ромба разрешается.. интроспекция есть..

    и вообще, частые попытки потребовать от плюсов всех фич современных языков.. странно, что не потребовал функциональщины..
  • попытка пошутить: у сиплюсплюса есть плюсы. целых два!
  • @O01eg, я ваще теряюсь, столько новых слов
  • @0xd34df00d, shared_ptr тоже не шик.. с ним некоторые паттерны нереальны.. >_>
  • @neFormal, Видел на gamedev.ru интроспекцию на макросах (но для плюсовых классов), рвущую по скорости стандартный RTTI.
  • @hagane, Про GC — один существенный момент: некоторые вещи (которых нет в C++) просто невозможно сделать, освобождая память только в предсказуемых местах. А счётчики ссылок не решают проблемы перекрёстных ссылок.
  • @hagane, Про пункты с резолюцией «в еблище», кстати, люто согласен.
    Правда, причем тут личкрафты?
  • @asphyx, Грамотное проектирование решает проблему перекрёстных ссылок.
  • @neFormal, Например?
  • @0xd34df00d, ну, стандартная тема с хранением указателей на базовый класс..
  • @asphyx, мне в этом смысле нравится Vala. Из коробки — подсчёт ссылок. А при создании ссылки надо думать головой — если объект не обязан существовать пока существует ссылка — писать слово weak (ну или о зацикливаниях думать). Золотая середина) Хотя на себе не опробовал еще.
  • @0xd34df00d, Ни при чем, просто к слову пришлись.
  • @kb, Внутри тормозной GObject и нет нормальных исключений (есть только обёртка поверх проверки возвращаемого функцией значения).
  • тут подсказывают, про мощь языковых конструкций.
    #define private public
  • @asphyx, да, о тормозном GObject я и выше говорил, но GC еще тормознее (в теории). Потому если хватает тормозов GObject — самое оно.
  • @0xd34df00d,

    1. Ты последний раз плюсы что ли видел в эпоху VC6, с internal compiler error'ами?
    да нет, и в GCC 4.x натыкался

    2. Свои счетчики ссылок и все такое — ЛПП. boost::shared_ptr стандарт де-факто, std::tr1::shared_ptr почти стандарт де-юро.
    Счетчики ссылок это говно, просто нереальное говно. Если бы среднестатистический плюсовод, трясущийся за производительность и хаящий GC, вообще понимал бы какой оверхед вносят счетчики ссылок, он бы давно использовал нормальный язык со сборщиком мусора. Ну и циклы они не разруливают, да.


    3. Городить классы с деструкторами ради выполнения кода при выходе из скоупа — ты идиот чтоле? Осиль идиому с boost::shared_ptr'ом и кастомным делитером.
    Пиздец, а вот это как называется? Это оно и есть.


    4. «Код плохо читается», «отладка затруднена» — а мне лисп не нравится, там скобочек много, напоминает тупых пезд со смайликами )))))))) Нутыпонел сарказм, я надеюсь? ;)
    Код на лиспе нормально читается привыкшими к лиспу. C++ хуево читается даже старыми плюсовиками. bloated синтаксис.
    Нутро STL когда-нибудь смотрел?

    5. Если тебе нужна ссылка, умеющая быть null — используй указатели. Ссылки не могут быть null by design.
    Спасибо за совет!
    Я ссылками вообще стараюсь не пользоваться.

    6. Дублирование си-функциональности — да, тебя прям заставляют юзать и то, и то. Это преимущество в известном смысле, чувак.
    Это не преимущество, это говно. Для высокоуровневого языка для интерфейса к Си должен быть FFI.
    Немалая доля говна в плюсах(в т.ч. в синтаксисе, типа необходимость расставления пробелов между треугольными скобками в шаблонах, она как раз из-за того, что в язык впихнули C90)

    7. Ты ниасилил vector<vector...> > и std::string?
    Блять, ну вот пиздец. vector<vector> это что, многомерный массив? Ну смешно, да.
    string убоги.

    А в 0x и уникод есть.
    Не прошло и ста лет.

    8. Проблема ромба не решается, ЩИТО.
    en.wikipedia.org

    9. Отсутствие свойств — темплейтная обертка пишется на коленке за 2 минуты и реюзается всю жизнь.
    Это будут не свойства, а кривой и неудобный костыль.
    На темплейтах свойства не сделать, максимум на макросах.

    10. Магическое НАРУШАЮТ ИНКАПСУЛЯЦИЮ как мантра, фу.
    Ну дак если нарушают.
  • @neFormal, А что с ним? Расскажи про этот паттерн, я не шарю.
  • @asphyx, Кстати, GObject сильно тормозной или его интроспекцию обойти можно?
  • @O01eg, Отрываясь от C++: без GC, разруливающего перекрёстные ссылки, ты не сделаешь честных замыканий
  • @O01eg, можно быстрые вещи писать без GObject)
  • @0xd34df00d, иерархия объектов, которые делают что то одно, но по разному.. все хранятся в одном контейнере в качестве указателей на базовый класс.. контейнер обходят и дёргают виртуальный метод.. ты должен знать, это стандартный паттер.. я только название постоянно забываю.. >_>
    при использовании shared_ptr код превращается в лютое месиво из кастов..
  • @asphyx, 1. Зачем?
  • @O01eg, Интроспекция там не внутри живёт, это не страшно. Там динамическая регистрация типов и RTTI сделаны через 33 хэш-таблицы.
  • @O01eg, Ну, во-первых, это красиво :)
  • @neFormal, Бустовый shared_ptr не осиливает виртуальные вызовы?
  • @asphyx, Если я правильно понимаю, это влияет только на время инициализации и финализации программы.
  • @O01eg, осиливает.. просто часто надо получить объект дочернего типа.. а в бусте очень стрёмный кастинг *_ptr-ов.. ну очень..
  • Предположим, что это не троллизм. И даже готов вместо криков "Бред, ерунда" расписать первый пункт
    * Медленная компиляция — согласен. Но С тоже медленней Паскаля собирается. И?
    * Internal error — на моей практике internal errorы выдают только малораспространённые компиляторы, как, например, winscw. Думаю, дело в компиляторах, а не в языке
    * Код плохо читается — только в том случае, когда он плохо пишется.
    * разбор кода и генерация — согласен, хотя считаю это минорным дефектом
    Дальше продолжать? Там дальше куда более веселые забросы
  • @asphyx, Я про зачем там счётчик ссылок с перекрёстными ссылками.
  • @lovesan, 1. Не юзай компиляторы из транка.
    2. Кто циклы не разруливает? Там должен быть ИИ на, прости г-споди, лиспе? boost::intrusive_ptr для хитрой логики, олсо, пересмотри дизайн.
    3. А что это есть? Ты создаешь класс и явно пишешь его деструктор? Тогда пошел нахуй из моих жуйков, ты не осилил базовые понятия языка, а уже метанируешь лужи, его критикуя.
    4. Мной С++ отлично читается, нутро STL смотрел, кончал в среднем два раза в минуту.
    5. Once again, ты нихуя не понял, но везде лезешь. Вспоминается картинка с пионерами и конем.
    6. «это говно» — аргумент с невообразимой поражающей силой. Не берусь спорить. И да, ты идиот? Как, по-твоему, обошли проблему с >> в темплейтах в 0x?
    7. А что это, как не многомерный массив? А чем string убоги?
    Олсо, про юникод — потому что это не очередной недоязычок на поиграться для гиков типа Go, io или хз чего, это, блять, промышленный стандарт.
    8. Не могу ходить по ссылкам, пишу в формочке ответ (((
    9. Чем кривой и неудобный? Геттер есть, сеттер есть, семантика выполняется. С макросами съеби пзязя, на них только енумами и упарываться.
    10. Ну так ты бы обосновал что ли хоть.
  • Кстати, ссылка может указывать на NULL, никто не запретит Class &ref = (Class)0;
  • @neFormal, А, е-мое, я думал, хранить в наследнике указатель на базовый.
    А зачем там делать касты?
  • прекрасно, великолепно! ржал аки конь, тот чувак жгет напалмом.
  • @0xd34df00d, На макросах строки можно ковырять.
  • @neFormal, Если ты пишешь код, где в этом случае надо делать даункасты — нахуй, нааааахуй, пересматривай дизайн.
  • @O01eg, На макросах много чего можно делать, но зачем?
  • @0xd34df00d, это так только кажется, что проблема в дизайне.. на практике это случается.. альтернатива — повысить сложность проекта, вводя доп.абстракции..
  • @0xd34df00d, Затем, что этого нельзя делать шаблонами.
  • @neFormal, Значит, на практике ВНЕЗАПНО проблема в дизайне.
    А у тебя «.» что ли западает?
  • @0xd34df00d, ты всегда повышаешь сложность проекта?.
  • @neFormal,
    Счетчики ссылок это говно, просто нереальное говно. Если бы среднестатистический плюсовод, трясущийся за производительность и хаящий GC, вообще понимал бы какой оверхед вносят счетчики ссылок, он бы давно использовал нормальный язык со сборщиком мусора.
    Раз уж начал, так объясняй, почему счетчики ссылок дороже сборки мусора (которая, внезапно, в частности занимается подсчетом ссылок)

    Ну и циклы они не разруливают, да.
    В ЕБЛИЩЕ

    Пиздец, а вот это как называется? Это оно и есть.
    Это называется "Сначала подумать".

    Код на лиспе нормально читается привыкшими к лиспу. C++ хуево читается даже старыми плюсовиками. bloated синтаксис.
    Любой чужой код хуево читается. И что теперь?

    Нутро STL когда-нибудь смотрел?
    Да, нормально. У меня и хуже бывало.

    Я ссылками вообще стараюсь не пользоваться.
    Ну так нет проблем же, так?

    Это не преимущество, это говно. Для высокоуровневого языка для интерфейса к Си должен быть FFI.
    Хватит натягивать лисп на плюсовые реалии. Это совсем другой язык, бро.

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

    Блять, ну вот пиздец. vector<vector> это что, многомерный массив? Ну смешно, да.
    string убоги.
    Охуеть аргументация.

    Не прошло и ста лет.
    Он везде есть. Просто он вендор-специфик.

    http://en.wikipedia.org/wiki/Diamond_problem
    Ромбики? В ЕБЛИЩЕ!

    Это будут не свойства, а кривой и неудобный костыль.
    На темплейтах свойства не сделать, максимум на макросах.
    Ну на макросах, говно вопрос. Где проблема то?

    Ну дак если нарушают.
    Ну и хуй с ней, пусть нарушают. Или ты прямо спать не можешь, когда у тебя что-то где-то недоинкапсулировано?
  • @hagane, — Проебал номер сообщения, ответил на последнее.
  • @neFormal, Сложность? Нет, избавляя код от косяков, я понижаю сложность проекта.
  • @0xd34df00d, ладно, чего спорить, я подожду пока ты столкнёшься с такой проблемой..
  • А вообще, тс вызвал у меня приступ ностальгии. Вспомнился я лет 5 назад — я любил набижать на уютненький форум каких-то шарпистов, и бросаться в них подобными аргументами. "В вашем языке я не могу вставить кусок кода на ассемблере — утерян контроль над машиной", "вы не можете нормально защитить свой код от декомпиляции", "и ваще он медленный шопездец".
    Хотя аргумент "$1 есть кривое говно, которое я не осилил — этого достаточно" я не применял даже тогда )
  • @Cthulhu, это победа..
  • Да и, к тому же, на английском
    Дальше не читал.
  • @L29Ah-banned, А зря, там такой кошерный бред написан.
  • @0xd34df00d,
    1. Не юзай компиляторы из транка.
    Не из транка. вполне релиз.
    Вроде какую-то шнягу из буста помнится пытался сконпилить

    2. Кто циклы не разруливает? Там должен быть ИИ на, прости г-споди, лиспе? boost::intrusive_ptr для хитрой логики, олсо, пересмотри дизайн.
    GC разруливает. Без этого замыкания невозможны.

    3. А что это есть? Ты создаешь класс и явно пишешь его деструктор? Тогда пошел нахуй из моих жуйков, ты не осилил базовые понятия языка, а уже метанируешь лужи, его критикуя.
    Вместо того чтобы просто написать "unwind-protect" в нужном месте, мы городим кастомный вариант умного указателя.

    4. Мной С++ отлично читается, нутро STL смотрел, кончал в среднем два раза в минуту.
    Да пиздец.

    5. Once again, ты нихуя не понял, но везде лезешь. Вспоминается картинка с пионерами и конем.


    6. «это говно» — аргумент с невообразимой поражающей силой. Не берусь спорить. И да, ты идиот? Как, по-твоему, обошли проблему с >> в темплейтах в 0x?


    7. А что это, как не многомерный массив? А чем string убоги?
    Многомерный массив это данные лежащие плотным куском в памяти. Бывает по row-major, бывает по column-major.
    А это максимум jagged array, а вообще — вектор из векторов.
    Какие накладные расходы у этого говна по удобству использования и по производительности думаю говорить не надо.

    Олсо, про юникод — потому что это не очередной недоязычок на поиграться для гиков типа Go, io или хз чего, это, блять, промышленный стандарт.
    Юникод в CL предусмотрен уже с самой его стандартизации. Хотя он сам стандартизировался когда юникод только появлялся.
    CL тоже недоязычок для гиков? Да нет, CL это как раз промышленный стандарт, стандартизированный на деньги американских военных, кстати. А вот хуйня для "гиков" это как раз C++
    Особенно в современных реалиях.

    9. Чем кривой и неудобный? Геттер есть, сеттер есть, семантика выполняется. С макросами съеби пзязя, на них только енумами и упарываться.
    Кривой тем что кривой и неудобный тем что неудобный. Сравни этот кривой костыль со свойствами в C# или хотя бы в дельфях.

    10. Ну так ты бы обосновал что ли хоть.
    Инкапсуляция это отделение интерфейса от реализации. Когда кишки реализации у нас в интерфейсе это называется "нарушать инкапсуляцию"
  • ПИЗДЕЦ ТУТ ДЕДФУД ВСЕ U
  • @lovesan,
    Вроде какую-то шнягу из буста помнится пытался сконпилить
    Где ссылка на багрепорт?
  • @lovesan,
    Без этого замыкания невозможны.

    Возможны
  • @OCTAGRAM, нет
  • @O01eg, я его не писал, поигрался и забил
  • @O01eg, RTTI там глубоко зарыто, и используется постоянно. Видел километровые ворнинги типа «жопа is not палец» в рантайме от gobject-приложений? это его rtti так работает.
  • @asphyx, Спасибо, я опять блеванул.
  • @lovesan, В последних версиях Delphi и восходящие, и нисходящие есть. GC там как не было, так и нет и нахрен не надо.
  • @O01eg, Можно как угодно, но надо GC
  • @lovesan, 1. Ололо, друг друга друга сказал про другого друга, который работал в комитете по стандартизации в компании на аутсорсе, которые пытались собрать какую-то штуку из потерянной ревизии буста из SVN, ок.

    2. Ты что, даже как твой лисп работает, не понимаешь?

    3. Что такое «кастомный вариант», чем он кастомный?

    4. Щито?

    5. Щито?

    6. Щито?

    7. Ну сделай тогда, чего .Пишется на коленке за 3 минуты, обкладывается полным набором нужных матанных операций еще за 7. Более того, я уверен, в каком-нибудь Blitz++ или подобных либах это есть.

    9. Ты идиот, потому что идиот. Пиздуй на лор, тамошние оналитеги будут смотреть тебе в рот, а здешних не пытайся этим феерическим бредом развести.

    10. Определи критерии принадлежности кишок интерфейсу.
  • @asphyx, Зачем?
  • @O01eg, Потому что это красиво! :)
  • В целом здраво, но есть достаточно серьёзные неточности, попунктно:
    1) (-) Пункт (1) состоит из какого-то субъективизма. Код плохо читается, если его плохо пишут.
    2) (+-) Ручное управление памятью можно отнести как к +, так и к — языка. Всё зависит, что ты на нём пишешь. Если тебе нужно иметь доступ к видеопамяти или скажем замапить страчку бивиса, то это куда гемморойнее прокидывать через FFI, чем обернуть в ++нутый класс.
    4) (+)
    5) (+-): Стоит сказать о new/delete и их преимуществе над malloc'ом: чтобы в C заменить аллокатор одной программы, не переписывая программу, придётся сильно помучиться, чтобы это сделать в C++ достаточно сделать базовый класс с перегруженными new/delete, отнаследовав от него остальные классы.
    Ещё момент, который напрягает — goto out_of_scope не вызывает деструктор :)
    6) (+)
    7) (-) В языке с ручным управлением памятью строгую типизацию сделать весьма затруднительно. 7 вытекает из 2. Если не нужно ручное управление памятью, зачем брать C++?
    8) (+-) Согласен с большинством пунктов, но лично мне особого неудобства это не доставляло. Единственное, что меня сильно напрягает в плюсовом OOP — отсутвие java-like интерфейсов, это отсутствие приходится обходить множественным наследованием. Ещё не согласен с private/public/protected, они не обязаны давать убер-жёсткую защиту, это больше декларативные элементы, в виртуальных деструкторах не вижу ничего плохого, как и getter'ах/setter'ах(это уже из области синтаксического сахара)
    9) (+)
    10) (-) finally/unwind-protect — минорный функционал, конфликта никакого нет, нужно просто учитывать особенности языка(так же, как ты учитываешь особенности реализации лисповых макров и тот факт, что плохо написанный макр может «течь»), «работет медленно» по сравнению с чем?
  • @asphyx, GC?
  • @O01eg, замыкания. или о чём мы там говорили?
  • @asphyx, Зачем замыканиями GC?
  • @dk, Про виртуальные деструкторы имелось в виду, что при наличии виртуальных методов они должны быть виртуальными, но по умолчанию остаются невиртуальными.
  • @O01eg, Чтобы контекст во время уничтожать. А если на этот контекст ссылается жругое замыкание — то не уничтожать, а сделать это когда-нибудь потом. Как ты это руками сделаешь?
  • @O01eg, спасибо за поправку, в таком случае согласен и с этим пунктом.
  • @0xd34df00d,
    1. Блядь, я столкнулся с фактом. И читал, что я не один такой.
    В SBCL я вообще только 1 раз за все время с ошибкой внутри компилятора сталкивался. И то, это потому что порт недопиленный был под винду. Это при том, что SBCL пилится энтузиастами на коленке.
    А GCC и MSVC — продакшн-квалити конпилеры. И VC6 кстати тоже был(а каким был g++ в его время? вот-вот). И в них при компиляции ошибки, ну это ли не пиздец.

    2) Я охуеть как понимаю, как он работает, и советую разобраться другим, ага. Замыкания без GC невозможны.

    3) Это значит нестандартый.

    7) Ага, пиздец. Ну как всегда, в плюсах "все можно сделать". И GC и массивы. Да только никто нихуя не делает — ленивые наверное.

    9) Блядь, посмотри на нормальную реализацию свойств, придурок.

    10) Таки идиот это ты.
  • @asphyx, Для нисходящих замыканий не требуется ни GC, ни RC. Для восходящих достаточно RC, как в Delphi 2009
  • @OCTAGRAM, Зато с GC можно не думать разрабам компилятора.
  • @dk, Тащем-та, не буду спорить с твоей оценкой, разве что, сократил бы одну из твоих фраз до «Еще момент, который напрягает — goto» :3

    Ну и да, finally таки полезная штука, но и в плюсах это можно юзать.
  • @OCTAGRAM, Примеры? Тут я уже не очень понимаю, о чём ты.
  • @OCTAGRAM, нисходящие — это как?
  • @asphyx, Блин, ну посмотрите, как замыкания в Delphi 2009 устроены. Там банальный счётчик ссылок на контексты
  • Да, и можно лично для меня раскрыть вопрос, как "исключения в конструкторах гарантированно влекут утечку памяти " ? Я даже переподписался, чтобы задать его
  • @0xd34df00d, goto правда напрягает, когда нужно по работе перевести сишную программу на плюсцы(из-за того, что она должна использовать православные ++ные корпоративные либы), а переписывать её очень лень. Каждый кусок кода с goto приходится ревьювить, а порой и переписывать. Дело это совершенно неблагодатное
  • @lovesan, 1. Пойти что ли тебя потроллить проблемами SBCL под венды x64, товарищ то ли в жуйке, то ли в ЖЖ щас ловит фан.

    2. А они есть.

    3. Чем он нестандартный? Ты сигнатуру ctor'а shared_ptr'а видел?

    7. Ты идиот и не лечишься. В стандартной библиотеке этого нет, но туда и не включают эту хуйню, потому что это тебе не SBCL, пилящийся на коленке кучкой задротов-красноглазиков, обсирающих другие языки, не разобравшись в том, что такое $anotherlang-way. Ну или %anotherlang%-way, раз ты вендоблядок.

    9. Посмотрел. Посмотрел обратно на плюсовый вариант. ЧЯДНТ?

    10. Я все понимаю, что динамическая типизация разжижает мозги, но все же так формулировать критерии надо уметь.
  • @asphyx, Нисходящие передаются как аргумент, из вызывающего в вызываемый
  • @OCTAGRAM, Ну тогда да, но это не интересно. Это даже в Vala есть (выше упоминался).
  • @dk, В Саттере ж было на тему.
  • @OCTAGRAM, Да не ебу я. Я даже не знаю, где смотреть. Если я сделал замыкание, сохранил (по дурости) ссылку в текущем контексте, и её же вернул наверх. Что случиться? Кольцо.
  • @asphyx,
    (по дурости)
    ч.т.д.
  • @lovesan, Читать Саттера, про безопасность исключений и про смарт поинтеры вроде std::auto_ptr и scoped_ptr без оверхедов для обеспечения этой самой безопасности.
  • @tilarids, Ну костыли же
  • @asphyx, Куда меньшие, чем GC.
  • @lovesan, Хм, от исключений в конструкторах можно защититься — не самым изящным путём, но всё же — словив исключение в самом конструкторе, освободив все динамически аллосцированные объекты и пустив исключение выше.
  • @0xd34df00d,
    Ты идиот и не лечишься. В стандартной библиотеке этого нет, но туда и не включают эту хуйню, потому что это тебе не SBCL, пилящийся на коленке кучкой задротов-красноглазиков, обсирающих другие языки, не разобравшись в том, что такое $anotherlang-way. Ну или %anotherlang%-way, раз ты вендоблядок.

    Пиздец. Дурик, многомерные массивы должны быть частью языка. Этого либо нет, либо оно есть. Это не "опциональная фича" "для красноглазиков", которую "можно запилить".
  • @lovesan, oh deer..
  • @lovesan, int** multi_dimensional_array;
  • @tilarids,
    умные указатели это как раз дикий оверхед и костыли.

    да, саттера читал.
    но факт остается фактом, что проблема есть, и она не всегда решаема. Я говорю, если в нашем классе — то исключение можно отловить. А если в родителе? Исходников которого у нас к тому же и нет.
  • @hagane,
    это не многомерный массив.
  • @asphyx, Ну вообще, чтобы в Delphi создать кольцо таким образом, нужно ЯВНО создать кольцо, используя эту переменную в замыкании. Переменные, не используемые ни в одном вложенном замыкании, хранятся на стеке и освобождаются автоматически при выходе
  • @lovesan, Если оно жрет как утка, срет как утка и на вкус как утка, то это, блядь, утка!
  • @lovesan, \begin{lovesan}В лиспе тоже нету многомерных массивов, в нём есть какая-то неведомая ёбанная хуйня, которая иногда делает вид, будто она многомерный массив\end{lovesan}
  • @hagane,
    я где-то выше писал — массив это кучка элементов, лежащая в памяти рядом.
    Это вполне конкретная структура данных, это не АТД
  • @lovesan, Если я напишу тебе шаблонный многомерный массив, ты успокоишься?
  • @lovesan, type[x][y][z]...
  • @O01eg,
    Массивы там полноценные, это даже в стандарте написано.
    Там же, кстати, написано, что данные в них должны лежать по row-major.
  • @lovesan, Эм... scoped_ptr и std::auto_ptr являются compile time overhead, а не runtime overhead. И какая проблема с родителем? Если исключение вылетит в родителе, до конструктора и списка инициализации членов просто не дойдет
  • @lovesan,
    чтобы мы могли отобразить их в последовательность и с ними как с последовательностью работать
  • @OCTAGRAM, А, то есть он проверяет обращение? Ну тогда круто, чо :)
  • @lovesan,
    дикий оверхед
    ЩИТО
    Да ты правда идиот.
  • @lovesan, Ты из тех малолетних идиотов, приходящих в чужой дом и кричащих «сделайте мне сортир как в моем, с кнопочкой смыва слева, иначе это не сортир!!!!1111111111»
  • @tilarids,
    1) не только compile-time, это вообще распространенное заблуждение.
    структура есть? дополнительный уровень косвенности есть?
    есть. Есть и оверхед.

    при исключении в конструкторе родителя в объекте что-то потечет, может и не твои конкретно данные, но те, которыми инициализируется родитель(они кстати вполне могут быть и твои, при определенном старании)
  • @lovesan, :facepalm:
    Ты таки ниасилил плюсцы.
  • @0xd34df00d, О, да очередной тупой плюсист.
    Ну да, иди дрочи дальше на плюсы, свято верь в производительность программ на плюсах, которая якобы магически вытекает из того факта что "плюсы же, у них такие-то конпеляторы!".

    В свободное время, правда, можешь почитать что такое GC, как он работает, и почему все это костыльное говно, которым обмазываются плюсисты чтобы хоть сколько-нибудь автоматики привнести в управление памятью, добавляет столько оверхеда и тормозов.
  • @lovesan, Т.е. ты слил как обычно?
  • @lovesan, пости пруфлинки
  • @O01eg, Блядь.
    Я еще раз повторяю — что я должен на это долбоебическое ололоканье, которое гонит вот этот вот дедфуд, отвечать?

    — "Умные указатели это оверхед, причем гораздо больший оверхед чем GC"
    — "ОЛОЛОЛО да ты не асилили, оллоло, да ты идиот! Плюсы божественны и не тормозят, ололо!"
    — "..."
  • @lovesan, Ну да, ты так ни одного аргумента так и не привёл.
  • @neFormal,
    относительно чего?
    могу предложить для начала вот эту книжечку:
    ftp.cs.utexas.edu
  • @lovesan, относительно оверхеда и тормозов, очевидно.. странно, что ты не понимаешь таких простых вещей..
  • @lovesan, Так ты еще и читать не умеешь, или Божественные Скобки затмевают твои глазенки?
  • @0xd34df00d,
    ты меня заебал, съеби отсюда.
    можешь, кстати, почитать вот ту книжку, ага
  • @lovesan, Я и на хаскель пофапываю, УМВР. Просто я open-minded, а не closed-minded быдло тебя, нуждающееся в том, чтобы быть нон-конформистом.
  • @lovesan, Зачем её читать, если там не написано, чем GC лучше грамотной работы с памятью?
  • @O01eg, какой грамотной?
    ну, кстати, да, вполне себе стандартный аргумент плюсистов "да ты просто не асилил, просто надо УМЕТЬ, так то".

    Я думаю, не надо объяснять почему это бредовый аргумент, да? Несмотря на то, что на хелловордах прокатывает.

    я вполне на конкретный вопрос отвечаю — вот там описано, почему счетчики ссылок и прочие плюсовые костыли это тормозное и кривое говно.
  • @lovesan, номер страницы, строка?.
  • @neFormal,
    Ты тупой?
  • @lovesan, слив засчитан, клоун повержен..
  • @lovesan, Ты даже не можешь сознаться, что сам её не открывал?
  • @neFormal,
    Да это ты тут клоун, который походу даже читать не умеет.
    Съеби нахуй
  • @O01eg,
    я ее всю прочитал.
    Там где-то в начале, в самом самом, подробно объясняется почему именно reference counting — говно.

    по мере продвижения по книжке приходит осознание того, что таки GC сейчас пишутся такие продвинутые, что велосипедами и костылями в плюсах их никак не переплюнуть.

    советую почитать, так что.

    и больше не скакать тут ебанашками в комментах, потому что я уже начинаю уставать.
  • @lovesan, Я специально написал две функции, одна из которых — умный указатель, вторая — голый Сшный. Так вот, найдешь оверхед? codepad.org
    Да, определенный оверхед умные указатели накладывают. Но этот оверхед обычно идет на обеспечение безопасности. И правильные GC по оверхеду всё-равно обойдут ручное управление памятью.
    И да, я не говорю, что GC плох. В определенных ситуациях GC великолепен при минимальных затратах. И для прикладных задач лучше использовать языки с GC, но лишь потому, что 80% программистов — обезьянки.

  • Пацаны, я тут короче сидел за монитором и попытался скомпилить какую-то шнягу из буста, не помню какую, но внезапно компилятор сказал мне "интернал еррор" много раз. И тут я вдруг задумался — какое же говно c++! <[ апплодисменты в зале ]>

    Представляете, пацаны, он дает мне stdio и iostream, и я должен выбирать. А как я выберу, это же так сложно, прямо глаза разбегаются! А вдруг я использую и первое, и второе? Совсем беспредел же получится, пацаны, видите какой говно-язык? <[ зал продолжает рукоплескать ]>

    А стандартная библиотека? Она же просто ужасна! Там даже строки кривые — не спрашивайте почему, я не знаю^W^W^Wэто же очевидно! И знаете, скажу вам по секрету, я открыл ее исходник... Да, исходник самой stl! Вот вы когда-то смотрели туда? Вижу по глазам, что не смотрели. А я вот посмотрел, и ничего там не понял!!! <[ Бурное проявление недовольства в зале, апплодисменты, крики "Страуструпа на мыло!" ]>

    Вот смотрите сюда, пацаны. Я нашел кусок кода, в котором используются макросы с шаблонами, конструкторы бросают исключения, написана куча велосипедных аллокаторов, память течет как из ведра. Я читал его и ужасался, на каком же говно-языке все вокруг пишут! <[ Одинокий голос из зала "а может ты сам написал этот код?", раздается несколько ударов, несогласного выносят ]>

    И инкапсуляция у них нарушается всегда!!! В только представьте, пацаны — они спят и видят, как бы ее нарушить! Просыпаются, и сразу же бегут ее нарушать; засыпают, мечтая о том, как пойдут нарушать ее завтра! <[ Дамы в зале утираются платочками, всхлипывая; мужчины сидят с каменными лицами, сцепив зубы ]>

    И вообще, самое страшное — этот подлый язык заставляет меня думать! Думать над освобождением памяти, думать над нормальной иерархией классов, думать над всем!!! Так дальше продолжаться не может — пора закопать его! За-ко-пать!!! Такое говно не должно оскорблять своим существованием наш священный мирок! Кто со мной?!

    <[ Все, сидящие в зале, вскакивают, словно распрямившаяся пружина, и выбегают в дверь следом за лидером. Кажется, старому язычку пришел пиздец. Армия скрывается в тумане, некоторое время оттуда слышатся крики "Батт-хёрт! Батт-хёрт! Батт-хёрт!", под которые марширует этот карательный отряд, потом и они затихают вдали ]>

    Из потайной дверцы в опустевший зал входит Александреску, вертя в руках блокнот. "2011 год, реактивное говно-нашествие школоты номер 9681", записывает он туда; выходит из зала, запирая дверь на ключ. На крыльце его поджидает Страуструп, они заходят в соседний паб, заказывают по кружке темного пива, и с улыбкой смотрят на экран на стене.

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

    "больше двадцати лет прошло, и все повторяется", — со вздохом говорит Бьёрн, потягивая пиво.

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

    "Пацаны...", — начинает свою проповедь очередной мессия.
  • @Cthulhu, в отдельный пост вынеси со ссылкой на этот..
  • @neFormal, Инкрементирую
  • @tilarids, вырожденный пример. всем известно что хелловорды компиляторами плюсов отлично оптимизируются. GC по оверхеду ручное управление обходят только на хелловордах. Я настоятельно рекомендую почитать ту книжку. И да, не обезъянки, а умные люди, которые умеют свое время ценить, в отличие от плюсовиков, которые его тратят на бессмысленное выдрачивание.
  • @Cthulhu,
    съеби нахуй отсюда со своим петросянством
  • @tilarids, Какой компелятор кстати? На x86_64 выдаётся слабый overhead в 1 callq: codepad.org
  • @dk, x86, gcc -O3
  • @tilarids, ok, с O3 на x86_64 оверхедный callq элиминейтнулся
  • @lovesan, В качестве аргумента разумно было бы показать objdump плюсокода, где скопед-поинтеры дают сильный оверхед.
  • @lovesan, а так это не более, чем пустые слова
  • И ещё момент, который меня смущает в этом треде — помимо перехода на личности и потери собеседниками самообладания — тут было высказано, что современные GC дают меньший оверхед, чем ручное управление памятью(прошу меня поправить, если я что-то выраваю из контекста, очень много комментариев и очень мало времени, чтобы все их читать). Мне бы хотелось услышать название проекта, где можно посмотреть сорцы такого GC. Вроде всё.
  • @dk, ну зачем scoped_pointer.
    это действительно плохой пример. вот я обосрусь с ним показать оверхед(ну потому что это надо выдумать не хелловорлд, чтобы gcc его не заоптимизировал, а мне лень), и начнется очередной раунд ололоканья от разных долбоебов.

    вот хороший пример это всякое говно типа intrusive_ptr, shared_ptr и т.п., которое в real-world можно наблюдать гораздо чаще.
    попозже напишу.
    постараюсь попозже написать пример.
  • @lovesan, ok, ждём
  • @dk, IMHO оверхед здесь даже в три раза не имел бы большого значения, ибо, ну, по крайней мере, среди задач, которые требуется решить, что–то, требующее работы с вот такими вот структурами с RC, — это нечастые всплески активности по мере поступления данных из сети или другой активности. В таких задачах нужно организовать взаимодействие, а, что касается оверхедов, большую часть времени будет простой. Зубодробительные же задачи типа вычисления TTH и Bloom filters от оверхедов на счётчик ссылок слабо зависят. При нормальных буферах, конечно
  • @OCTAGRAM, Совершенно согласен с точки зрения инженера, но, как задрот со стажем, не согласен. Раз уж начали рыть тонкости топика, давайте разбираться до конца :)
  • @dk, Мне нравится называть идиотов идиотами :(
  • попробую призвать @redchrom в тредик, он вроде много занимался GC, может скажет что-то дельное
  • @0xd34df00d, имхо, когда дискуссии переходят на личности, они автоматом перестают быть дискуссиями.
  • @dk, Just to clarify: я не так уж много занимался GC, просто имею небольшой опыт имплементации. Так вот по поводу памяти, не мог бы кто из здесь присутствующих привести пример управляемого языка/рантайма в котором можно создать массив объектов, а не массив ссылок на объекты? Также о локальности, да, сборщик мусора может дефрагментировать память и этого достаточно для большинства задач, но не зная семантики этих объектов рядышком он их не упакует, а кэша знаете ли мало.
  • и почему я не отписался?
  • жжоте напалмом товарищи. И всё таки что в вас, малолетних (и не очень) гиках, заебывает, что у вас 90% желания доебаться до оппонента, вместо того, что бы докопаться до истины. @lovesan — я рад, что ты определился для себя, что C++ говно, остается вопрос — какие будут предложения? Где конструктив? Радует @dk — единственный адекватный тут... Эх, срачи, срачи...
  • @redchrom, no way, если объекты переменной длины
  • @asmer, А если одинаковой?
  • @O01eg, а если одинаковой то имеет смысл делать массив объектов, но я хз, есть ли такие рантаймы, тут-то статические языки и рулят
  • @dk, первый нормальный ответ за 94 комментария. право, я уже не уверен, что стоит читать оставшиеся 89
  • @asmer, ну а что можно в плане "конструктива"?
    не писать на плюсах программы, например
  • @jtootf,
    не стоит
  • @lovesan, конструктив — это НЕ неделать что-то, а предложить альтернативу. В данном тредике — на ЧЕМ писать предлагаешь ты быстрые и портабельные программы? Если ВСЕ перестанут писать на плюсах — потеряют все в итоге, не так ли?
  • @asmer, 1)мой лично вариант — Common Lisp. по обоим критериям подходит.

    2) потеряют то потеряют, но это только потому что некому будет поддерживать весь тот говнокод который уже написан на них.
  • @lovesan, т. е. ты хочешь сказать, что на lisp можно написать лучше, быстрее и прямее чем на плюсах всё то, что уже написано на плюсах? В таком случае почему ты не написал сравнения по пунктам C++ с Common Lisp и не привел все за и против? Возможно с твоего сравнения больше народа перешло бы на lisp и светлое будущее бы приблизилось. А так — ты высрал вброс, который не принес ничего, кроме срача на 200 комментов. Ты тролль? Объясни мне, человеку с опытом в assembler, c, c++ (малым опытом, можно считать что нет его), php, python, javascript и прочем быдлокоде, чем lisp так крут. /me честно пытался осилить lisp, но пока не осилил, и рулезов сразу не почуствовал
  • @asmer, Сравнение было бы написано в стиле "мои круглые скобочки лучше ваших треугольных". Итоговая ценность была бы такая же.
  • @Cthulhu, К слову, Александреску уже угорел по D, что кагбе намекает
  • @Cthulhu, подождем ответа @lovesan.
  • @Cthulhu, ну хватит писать чушь уже. @lovesan пусть и фанатик своего дела, но вот чем-чем, а отсутствием аргументации не страдает
  • @asmer,
    т. е. ты хочешь сказать, что на lisp можно написать лучше, быстрее и прямее чем на плюсах всё то, что уже написано на плюсах?
    в принципе, да.

    В таком случае почему ты не написал сравнения по пунктам C++ с Common Lisp и не привел все за и против? Возможно с твоего сравнения больше народа перешло бы на lisp и светлое будущее бы приблизилось.
    Да фига с три, еще бы только больше долбоебов набежало бы и еще больше бы срач развели бы.

    А так — ты высрал вброс, который не принес ничего, кроме срача на 200 комментов. Ты тролль? Объясни мне, человеку с опытом в assembler, c, c++ (малым опытом, можно считать что нет его), php, python, javascript и прочем быдлокоде, чем lisp так крут. /me честно пытался осилить lisp, но пока не осилил, и рулезов сразу не почуствовал

    макросы — полностью меняемый синтаксис и даже семантика
    компилятор в стандартной библиотеке
    крутая объектная система
    крутая система обработки исключений
    крутые FFI
    у ведущих реализаций производительность на приличном уровне(на уровне жабысервер где-то, в среднем, но можно оптимизировать и более того)

    Вся его крутость, правда, на хелловордах плохо видна.

    ну кстати, я как-то сравнивал, правда с питоном — там тоже тот еще срач:
    love5an.livejournal.com
  • @lovesan,
    ну кстати, я как-то сравнивал, правда с питоном — там тоже тот еще срач:
    love5an.livejournal.com
    заебись. Как раз с этой мыслью я и писал #1277911.

    жаба канешна быстрее всего что есть, но блджад, до компилируемых в нативный код проца всей динамике по скорости срать и срать.. а если не по скорости — то по потреблению памяти так точно...
  • @asmer,
    блять, жаба быстрая таки довольно.
    на базовом уровне.
    Но код на ней пишут тормозной, таки да.

    В лиспах все лучше, вот еще постинг, см. там в конце пример машкода который генерирует тот же SBCL
    love5an.livejournal.com

    ну память — голому SBCL да, для старта надо 30 мегабайт где-то.
    но во-первых, что такое 30 мегабайт сегодня, а во-вторых, это потому что компилятор большой и сложный, и прямо в стандартной библиотеке.
    по мере потребления кода и по мере работы потребление памяти в нем не особо сильно растет.
  • @jtootf, Конечно. Сказать "c++ хреновый язык, потому что в нем нету gc", и описать десяток потенциальных ошибок, к которым может привести его отсутствие; привести десяток кривых архитектурных решений, которые позволяет язык; и, встав на горке из такой аргументации, кричать "посмотрите, какое говно" (кстати, ради интереса можно подсчитать, сколько раз это слово и синонимы были употреблены тс в обсуждении) — это хорошее, годное, объективное описание яп.
  • @asmer, есть достаточно быстрые (зачастую) и компилируемые в нативный код ocaml и haskell. Да даже для CL есть компиляторы в нативный код.
  • @a13, а при чем тут это? на эти языки никто в треде пока не жаловался) и они — определенно, лучший выбор чем плюсы.
    а CL и так в большинтве случаев компилируется в native code (SBCL, например. причем вполне прилично. поправьте, если не вру;)
  • @Cthulhu, вы не смогли даже этого
  • @jtootf, А зачем? Чтобы доказать тс очевидную истину "каждый язык имеет плюсы, минусы и свою область применения"?
  • @Cthulhu, чтобы не выглядеть толпой крикливых детей, например
  • @jtootf, сколько угодно подобных "разборов" было выше..
    а вот лично ты отпишешься на 20-30 пунктов про какой нибудь хацкель, если кто-нибудь напишет аналогичный список с кучей таких же глупостей?.
    безапелляционность всегда глупо выглядит, поэтому над лавсаном глумятся..
  • @jtootf, Я предпочитаю другие способы доказательства "взрослости". Пытаться аргументированно обсуждать что-то с фанатиками — заведомо бессмысленное дело.
  • @neFormal, кто глумится? да вы тут просто скачете ебанашками в комментах. глумильщики блять.

    еще никто кроме @dk, так и не написал ни одной конкретной претензии, одно долбоебское ололоканье вокруг.

    как школьники, блядь.
    хотя почему "как"?
  • @lovesan, "ебанашками", "долбоебское ололоканье", "как школьники".. вот она какая — аргументация, о которой говорил jtootf.. я-то думал..
    @dk написал обычный сдержанный пост.. но примечательно, что ты с ним не стал спорить.. ведь вброса там нет(как у дедфуда), а, чтобы спорить аргументированно, нужны мозги и опыт дальше хелловорлда.. собсна, ты и спорил только с дедфудом.. остальные посты просто заигнорил..
    ты очень напоминаешь iorlas-а.. разница только в том, что тот сливается сразу же после вброса, ты же ещё держишься некоторое время..
  • @neFormal, в постинге @dk не с чем спорить, в принице

    а дедфуда да, надо было сразу нахуй слать

    иди-ка и ты с ним
  • @lovesan, аргументации ноль, знаний тоже.. грустная тенденция..
  • @neFormal, у тебя — да
  • @lovesan, хехе.. в жеже тоже весело:
    — После прочтения поста появился вопрос: а Вы когда-нибудь писали на C++?
    — да
    — А более подробно можно?
    + какой срок
    + с чем работал/что было реализовано
    + какие задачи решал, в которых сказалась "хуевость" языка
    — я не хочу на этот вопрос отвечать

    бугага..
    "здравствуйте, меня зовут лавсан, я прочитал книжку 'C++ за 24 часа' и утверждаю, что язык говно"
  • @neFormal, ну да, да. Ты заебал. Можешь пойти в бложике написать у себя про это, я заебался уже пиликание psi выслушивать.
  • @neFormal, отпишусь. более того, время от времени этим занимаюсь. ссылку на пример дать?
  • @Cthulhu, и поэтому вы лезете обсуждать неаргументировано, да? ну это, конечно, намного более осмысленное занятие. недетское
  • ладно. извиняюсь за флуд
  • @lovesan, Поразительная реакция.
    Процитирую тебя же, ололо у тебя бугурт.
  • @jtootf, Есть такая штука как "тон вброса". Если человек, приведя пачку аргументов (часть из которых явно высосана из пальца), резюмирует это оборотами вроде "совершенно нет области применимости", "говно говном", "да закопайте уже" — это говорит об одном из двух: либо он правда так считает (тогда остается только подождать, пока вырастет и начнет различать другие цвета, кроме черного и белого), либо он просто взялся потроллить. В обоих случаях пытаться спорить аргументированно — бесполезное занятие, ибо тс уже все для себя решил. Потому я написал /30 .

    Каков стиль подачи вброса, таков и стиль ответов, потому комментарии Дедфуда были написаны в соответствующем тоне. Дальнейшее развитие дискуссии ("частые внутренние ошибки" превратились в "я там что-то из буста когда-то компилировал, и компилятор сказал internal error, и еще мне кто-то рассказывал, что у него тоже такое было", например), подтвердило мои первоначальные выводы. Потому я написал /77 и /160 .

    Когда хотят аргументированно обсудить что-то — вбрасывают не с таких полярных позиций, и не в таком стиле подачи материала. Вот и все.
  • @lovesan, респект. По-крайней мере по делу.