LINUX.ORG.RU

Кто там кукарекал про С++?


1

8

Задача: разработать кроссплатформенное клиент-серверное приложение под Windows/Linux на С++ (boost, ace, etc.), клиент построчно считывает с консольки введёные числа, отправляет на сервер, сервер в ответ плюёт разложением чисел на простые множители. Стандартное тестовое задание, ничего интересного.

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

К слову, скелет сервера получился не сильно отличающимся от того, что написано в доках буста.
Что это за вырвиглазие??

class server
{
public:
  server(boost::asio::io_service& io_service, short port)
    : io_service_(io_service),
      acceptor_(io_service, tcp::endpoint(tcp::v4(), port))
  {
    session* new_session = new session(io_service_);
    acceptor_.async_accept(new_session->socket(),
        boost::bind(&server::handle_accept, this, new_session,
          boost::asio::placeholders::error));
  }
  .......

Смеха ради, да и чтоб не вырвало от такого кода, накидал за полчаса решение на Haskell.
Что получилось:

  • Разбор параметров командной строки
  • Клиент-серверная архитектура
  • Полностью асинхронный многопоточный tcp-сервер
  • Поддержка unicode, IPv6 и BigInteger из коробки
  • Мемоизация (благодаря ленивости) из коробки
  • Полная кроссплатформенность (*nix, Mac OS, Windows etc.)
  • Правильность тривиально доказывается мат. индукцией по коду
  • Исходник чуть больше 60 строк (в 8 раз меньше, чем на крестах)

Если поднатужиться (я не стал) и заменить алгоритм нахождения простых чисел/простых множителей на более оптимальный, то ко всему прочему получаем автоматическую распараллелизацию алгоритмов из коробки (см. Data Parallel Haskell) и произодительность на уровне чистого Си/Фортрана.

Кто там пищал, что хаскель сугубо академический язык, что ничего реальго на нём написать невозможно? Кто там кукарекал про С++? Как вы с ним вообще работаете? Это же мазохизм в чистом виде (см. мыши и кактус)

★★★★★

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

anonymous ()

c/с++ - по новым меркам довольно низкоуровневые языки. Задачи на них решать можно, работают решения хорошо (ну то есть как написать, конечно). То, что строк кода получается больше - это не обязательно показатель того, что объем кода пропорционально вырос, потому что такие вещи как, например, обозначение структурных блоков ('{','}'), которые в современных языках вроде питона делаются мночисленными и многообразными whitespace-символами, занимают отдельные строки. Это едва ли может служить аргументом против вашего тезиса, но сравнивать лучше байты, а не строки.

Ну, а «сложность» восприятия и написания кода на c/c++ - это плата за гибкость и универсальность, думаю.

pianolender ★★★ ()
Ответ на: комментарий от pianolender

Ну, а «сложность» восприятия и написания кода на c/c++ - это плата за гибкость и универсальность, думаю

Употребление таких слов как «гибкость» в одном предложении с C++ следует приравнивать к грамматическим ошибкам.

encyrtid ★★★★★ ()

А производительность сравнил?

Kosyak ★★★★ ()

накидал за полчаса решение на Haskell

Читер ;) Иш какой умный. На хаскеле-то любой сможет! А ты на C++ смоги!

Основная проблема GHC, это наверное динамическая линковка. Поддерживать он ее поддерживает... Но как-то странно: развертывание она не упрощает, размер не снижает, и DLL-hell'у способствует.

Macil ★★★★★ ()

Всё правильно. Вот как раз недавнее обсуждение аналогичного вопроса: http://users.livejournal.com/_winnie/335669.html (в комментах там и аналог того же кода на хаскеле дан)

Сейчас пилят такой язык как OCC, возможно это будет наконец-то статически типизированный ООП язык с человеческим лицом.

geekless ★★ ()
Ответ на: комментарий от geekless

Сейчас пилят такой язык как OCC

Опять пытаются запилить глючную реализацию System F в смысле Хиндли-Милнера?

Macil ★★★★★ ()

Кто там пищал, что хаскель сугубо академический язык, что ничего реальго
на нём написать невозможно? Кто там кукарекал про С++?
Как вы с ним вообще работаете?
Это же мазохизм в чистом виде (см. мыши и кактус)

Г. вопрос, давай аналог skype на вашем убогом хаскеле
со всем функционалом как в skype

anonymous ()
Ответ на: комментарий от pianolender

в современных языках вроде питона

Окстись, какой [нецензурно] питон? Идея была предложена Питером Ландиным, отцом внедрения лямбда-исчисления в языки программирования. А именно в его языке ISWIM (прямой предок ML) в 1966-м (!!!!!) году.

Macil ★★★★★ ()
Ответ на: комментарий от Macil

Окстись, какой [нецензурно] питон? Идея была предложена Питером Ландиным, отцом внедрения лямбда-исчисления в языки программирования. А именно в его языке ISWIM (прямой предок ML) в 1966-м (!!!!!) году.

Ну питон это современный язык — факт. А кто там когда что придумал, никого не волнует. Все современные идеи IT растут из 60-х, это вполне очевидно. Просто некоторым идеям потребовалось полвека, чтобы «обычные программисты» до них доросли.

geekless ★★ ()

Выложи свое решение, поржем вместе.

Вроде бы, написано 5 строк, а на деле почти не фига не делают,

вынеси в метод и не будет

код раздут

Сдается у кого-то просто руки из жопы...

PiPi ()
Ответ на: комментарий от PiPi

вынеси в метод и не будет

Так вот у кого ООП головного мозга, теперь понятно.

Сдается у кого-то просто руки из жопы...

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

код раздут

Основная проблема, в том, что С++-фанатики ничего другого, кроме этого высера мертвого страуса, и не знают. Поэтому вношу поправку: код оче сильно раздут, по сравнению с нормальными языками.

mix_mix ★★★★★ ()
Ответ на: комментарий от mix_mix

То есть и код в бустовской доке уже не в счёт

Ты бы свой показал, а не из доки бустовской, кто тебя знает, чё ты там понаписал.

Reaper ★★ ()
Ответ на: комментарий от PiPi

Вроде бы, написано 5 строк, а на деле почти не фига не делают,

вынеси в метод и не будет

Гениально! Теперь я тоже знаю.

qaqa ()
Ответ на: комментарий от mix_mix

если надо писать серьезный софт - берется ace, если поделку вроде твоей - Qt, и строк кода там будет столько же, хватит уже ныть по поводу буста

anonymous ()
Ответ на: комментарий от geekless

статически типизированный ООП язык с человеческим лицом

по ссылке: разбить строку в список, отсортировать и отбросить повторяющиеся значения [...] Функция написана на страшной смеси Си и Си++ (кстати, а что, в STL не предусмотрен алгоритм split для строк? что за каменный век?) и занимает добрую экранную страницу

Ох лол, и то правда. Разбить строку?

istringstream iss(str);
vector<string> tokens;
copy(istream_iterator<string>(iss),
         istream_iterator<string>(),
         back_inserter<vector<string> >(tokens));
или
typedef vector< string > split_vector_type;
split_vector_type SplitVec;
boost::split( SplitVec, str1, boost::is_any_of("\t ") );

О боже, как же это красиво и элегантно!

mix_mix ★★★★★ ()
Ответ на: комментарий от anonymous

кстати у крестоненавистников почти всегда один и тот же метод - вытащить код на бусте, помахать им и заявить, что С++ - говно, так как они писали на бусте и им не понравилось; то ли им ума не хватает найти действительно подходящую библиотеку, то ли одно из двух

anonymous ()
Ответ на: комментарий от mix_mix

О боже, как же это красиво и элегантно!

QStringList tokens = str1.split( «\t » );

С++ - это ЯП, гибкий ЯП, как бы там не думали себе некоторые идиоты, если тебе надо удобство - берешь нужную библиотеку и не ноешь, если надо производительность - пиши хоть в стиле С

anonymous ()

Кто-то должен был это запостить

Почему я не люблю С++

1) Не может в управление памятью 2) Не может в LALR грамматику 3) Как следствие, не может в человеческий синтаксис 4) Не может в денотационную семантику 5) Не может в настоящие макросы (с темплейтами отсос - не могут в квазицитирование) 6) Следствие - не может в человеческий полиморфизм (не говоря про higher-order), только убогое кодовысерание. 7) Не может в referential transparency 8) Linear typing ... и остальные миллиарды отсосов

Зато может в: 1) Нетипизированный секс с указателями 2) Аппликативный порядок 3) УТЕЧКИ УТЕЧКИ УТЕЧКИ 4) Зловонную кучу Стандартов не реализованных в полном объеме ни одним компилятором 5) Стандарты наполовину состоят из undefined behavior и implementation-defined 6) Следовательно, миллиард практически не диагностируемых «приятных» неожиданностей. etc.

anonymous ()
Ответ на: Кто-то должен был это запостить от anonymous

Re: Кто-то должен был это запостить

Почему я не люблю С++

1) Не может в управление памятью
2) Не может в LALR грамматику
3) Как следствие, не может в человеческий синтаксис
4) Не может в денотационную семантику
5) Не может в настоящие макросы (с темплейтами отсос - не могут в квазицитирование)
6) Следствие - не может в человеческий полиморфизм (не говоря про higher-order), только убогое кодовысерание.
7) Не может в referential transparency
8) Linear typing
... и остальные миллиарды отсосов

Зато может в:
1) Нетипизированный секс с указателями
2) Аппликативный порядок
3) УТЕЧКИ УТЕЧКИ УТЕЧКИ
4) Зловонную кучу Стандартов не реализованных в полном объеме ни одним компилятором
5) Стандарты наполовину состоят из undefined behavior и implementation-defined
6) Следовательно, миллиард практически не диагностируемых «приятных» неожиданностей.
etc.

anonymous ()
Ответ на: комментарий от anonymous

QStringList tokens = str1.split( «\t » );

Ага, и сразу возникает вопрос, почему QStringList, а не абстрактный Iterable<String> или Iterator<String>. Он хотя бы унаследован соответствующим образом?

берешь нужную библиотеку и

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

geekless ★★ ()
Ответ на: комментарий от geekless

Он хотя бы унаследован соответствующим образом?

он не должен наследоваться, все необходимое для совместимости с STL есть

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

предлагаешь все засунуть в ЯП, чтоб обеспечить единообразие? вместо этого есть «комбайны» вроде Qt/wxWidgets, которые минимизируют надобность в сторонних библиотеках, но надобность эта все равно остается, вне зависимости от ЯП

anonymous ()
Ответ на: комментарий от anonymous

предлагаешь все засунуть в ЯП, чтоб обеспечить единообразие?

Намекаю, что всю историю выросших из Си языков можно описать как историю попыток реализовать тип String.

geekless ★★ ()
Ответ на: комментарий от geekless

Намекаю, что всю историю выросших из Си языков можно описать как историю попыток реализовать тип String.

В хаскеле с этим тоже не фонтан: Есть String, ByteString и Text. Причем, два последних в lazy и eager вариантах.

Macil ★★★★★ ()

Где код и результаты тестов производительности? Без этого это всё похоже на пустой треп.

Reset ★★★★★ ()

У меня к тебе большая просьба: сделай вменяемую IDE для Хаскелля и я с удовольствием буду на нем писать.

LongLiveUbuntu ★★★★★ ()
Ответ на: комментарий от geekless

Намекаю, что всю историю выросших из Си языков можно описать как историю попыток реализовать тип String.

так а причем тут «долго плюешься, когда приходится совмещать код», свой «публичный» класс для строк не так часто встречается, а если и встречается, то, как в случае с тем же Qt, умеет конвертироваться из/в стандартных строк, utf и т.д., т.е. особых проблем не возникает

anonymous ()
Ответ на: комментарий от LongLiveUbuntu

У меня к тебе большая просьба: сделай вменяемую IDE для Хаскелля и я с удовольствием буду на нем писать.

Emacs же. Нужно только правильно научиться его готовить.

mix_mix ★★★★★ ()
Ответ на: комментарий от mix_mix

А Vim не сгодится? Я как раз сейчас овладеваю техникой работы с ним. Можно годный рецепт?

LongLiveUbuntu ★★★★★ ()
Ответ на: комментарий от LongLiveUbuntu

У меня к тебе большая просьба: сделай вменяемую IDE для Хаскелля и я с удовольствием буду на нем писать.

Emacs.

Deleted ()

Похоже, что автор на кого-то сильно в обиде) только в этом вижу смысл темы))

Agathodaimon ()
Ответ на: комментарий от anonymous

Блин, всё, выключаю сарказмогенератор.

Речь шла не только о строках, но и вообще о стандартных типах языка: контейнерах, классах для IO и т.п. Количество велосипедов, разработанных в этой области, просто выходит за все разумные пределы. А виной тому во многом, в числе прочего, бедность выразительных средств языка. Системы типов, в частности.

Ну и отдельно не удержусь и пну, какими средствами в C++ реализуется «модульность». Заголовчные файлы — это модно и прогрессивно, чо.

geekless ★★ ()

а где там закрытие сокетов и т.д.? (не знаю как в бусте, но в вышеприведённом коде уж совсем скелет сервера)

qnikst ★★★★★ ()
Ответ на: комментарий от LongLiveUbuntu

Только он?

Может еще есть, не знаю. Но emacs при всех плюсах еще и универсален, а значит must have.

Deleted ()
Ответ на: комментарий от geekless

Ага, и сразу возникает вопрос, почему QStringList, а не абстрактный Iterable<String> или Iterator<String>. Он хотя бы унаследован соответствующим образом?

Ты не поверишь, да, QStringList это и есть наследованный QList<QString>, но с небольшими плюшками, типа фильтрации по регэкспу и тд. :)

zJes ★★ ()
Ответ на: комментарий от geekless

Речь шла не только о строках, но и вообще о стандартных типах языка: контейнерах, классах для IO и т.п. Количество велосипедов, разработанных в этой области, просто выходит за все разумные пределы.

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

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

для хаскеля, например, есть такой же набор велосипедов, хоть и поменьше конечно - т.к. ЯП менее распространен, особенно среди «нубов»

какими средствами в C++ реализуется «модульность». Заголовчные файлы — это модно и прогрессивно, чо.

зато есть и плюс - совместимость с С

anonymous ()

Мы ведь таки говорим о High Performance и Heavy Load, иначе к чему понты с асинхронностью, производительностью?

Часто проблема построения High Performance систем в том, что вы верите что имплементация платформы работает быстро. Вот есть актеры, которые позволяют упрощать паралельные вычисления путем эфективного использования ядер процесора и распределении работы актеров среди них. Есть обычные актеры Scala и актеры Akka - известные решения. Проблема в том, что часто решение на базе актеров на Scala, которое использует 8 ядер будет медленнее однопоточного кода на С++. Тут нужно все бенчмаркать и говорить о конкретных числах.

Насколько ваше волшебное решение на хаскелле быстрее кода на С++ в реальном бенчмарке? Ведь там же асинхронность, мемоизация... )

vertexua ★★★★☆ ()
Ответ на: комментарий от Macil

Динамическая линковка нафиг не нужна. Сделали динамическую загрузку - ок. Но длл-хелл плодить нафиг не надо.

Waterlaz ★★★★★ ()

А хаскеллевский точно асинхронный? Скоро загнется если я буду подключаться и ничего не делать?

vertexua ★★★★☆ ()
Ответ на: комментарий от Waterlaz

Динамическая линковка нафиг не нужна.

Динамическая линковка ой как нужна. Хотя бы потому что некоторые хаскельные приложения вынуждены тащить за собой сторонние либы. А раз так, то почему бы не тащить и свои собственные.

Кроме того, динамическая линковка теоретически должна упрощать развертывание (при наличии стабильного ABI). Ну и разделяемая память - не пустой звук вообще-то.

Macil ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.