Мне кажется, вы это не тому человеку объясняете. У меня, например, нет проблем с пониманием, зачем встраивать http-сервер в С++приложение.

Ну так ответ будет?

на каждый транспорт - свои заморочки. ну и не каждый транспорт дружит с каждым «фронтом».

на каждый транспорт - свои заморочки.

Спасибо, Кэп. В том числе и у http.

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

Alexander Zaitsev:

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

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

шаблоны потому-что. stl - намного легче.

Вы не ответили на вопрос, зачем дебажить буст?

все библиотеки, при наличии аналогов на c - работают медленнее.

Пример можете привести? а не абстрактное заявление. Пример с названием либ и бенчмарками (или ссылкой на них).

использование буста замедляет компиляцию в десятки раз. даже boost-test и тот пришлось выпилить, потому-что дико раздражало.

Неправда. Смотря какую либу использовать из буста. Если про спирит, то да. Если про тот же Boost.Algorithm, то нет. Всё зависит от используемой либы.

ну вот помножьте это на медитирование на многоэтажными шаблонами. даже с умным автокомплитом и то гиморой.

А зачем медитировать над шаблонами? Право, ни разу что-то не приходилось медитировать над шаблонами при использовании буста. Пример можно из повседневного использования?

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

s390

Я думал оно умерло.

скопипащенный stdlib

Шта?

веб-енжин

Опциональный.

тащит с собой всё своё что можно

Открою страшную тайну - в Qt обязательны только QtCore и QtGui. Но хейтерам не до этого.

зачем дебажить буст?

Когда хочешь что-то его использующее собрать - невольно приходится. Иногда в итоге оказывается проще выпилить boost.

В Qt даже QtGui необязателен. Я на Qt писал и консольные клиенты, и сервера-демоны без графики вообще.

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

бред какой... во-первых, нет ничего что нельзя сделать без шаблонов. посмотрите хотя бы на linux kernel. во-вторых, если вы не понимаете реальные проблемы использования шаблонов в реально больших проектах то вот вам:

1. время компиляции. никогда не видели проект который компилируется 5-10 часов? как вы думаете, как это влияет на эффективность труда?

2. никогда не видели много километровые call traces от C++ программы которые не помещаются даже на 10 экранов, а один вызов это 10 строчек среди которых найти имя функции даже не просто бывает?... не жалко свое время?

3. а вы видели какого объема debug info / symbols у C++?...

4. а есть ли у C++ ABI? пробовали когда-нибудь собрать что-нибудь кросс платформенное и разными компиляторами? или не дай бог обновить компилятор / библиотеку типа boost?...

5. я уж молчу о С++ гениях которые запутываются в своих auto_ptr'ах, shared_ptr'ах и прочей херне, потому что считают что думать не надо, или C++ программистах, которые никогда не знают где у них память аллоцируется и сколько и т.д. и т.п.

Ты конечно молодец

Если тебе не нужна функциональность из буста. А если нужна, то в 99% лучше буст, чем свой велосипед из говна и палок.

В каком-то плане - да.

Я собирал. И дебажить не приходилось. Возможно, что я только один такой везунчик

Что им помешало пользовать asio с корутинами?

То, что это сильно нервирует valgrind. При этом официальная позиция разрабочиков: «УМВР, чхал я на ваши валгринды».

Пусть совершенствуют/фиксят valgrind.

5. я уж молчу о С++ гениях которые запутываются в своих auto_ptr'ах, shared_ptr'ах и прочей херне, потому что считают что думать не надо, или C++ программистах, которые никогда не знают где у них память аллоцируется и сколько и т.д. и т.п.

А разве квалификация программиста является проблемой языка?

То, что это сильно нервирует valgrind. При этом официальная позиция разрабочиков: «УМВР, чхал я на ваши валгринды».

А что тут такого? glib тоже сильно нервирует валгринд.

А разве квалификация программиста является проблемой языка?

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

так как это про компиляцию, а не про написание кода.

мсье, теоретик?

Неправда

мсье - теоретик.

Ядро линукса вот ничерта не показатель. там и своей лапши хватает. Попробуйте, например, реализовать контейнер (тот же стек) без шаблонов. Мне интересно, что же это такое получится (вангую использование void*)

время компиляции. никогда не видели проект который компилируется 5-10 часов? как вы думаете, как это влияет на эффективность труда?

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

никогда не видели много километровые call traces от C++ программы которые не помещаются даже на 10 экранов, а один вызов это 10 строчек среди которых найти имя функции даже не просто бывает?... не жалко свое время?

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

а вы видели какого объема debug info / symbols у C++?...

Видел. Здоровые. А это является проблемой?

а есть ли у C++ ABI? пробовали когда-нибудь собрать что-нибудь кросс платформенное и разными компиляторами? или не дай бог обновить компилятор / библиотеку типа boost?...

Да, ABI не стандартизировано. Но это проблема не буста, а C++. Программист должен контролировать такие вещи на данный момент. Не хотите? Тогда используйте тулзы аля Conan, он будет контролировать такие случаи, чтбы ноги не отрывало от несовместимостей ABI.

я уж молчу о С++ гениях которые запутываются в своих auto_ptr'ах, shared_ptr'ах и прочей херне, потому что считают что думать не надо, или C++ программистах, которые никогда не знают где у них память аллоцируется и сколько и т.д. и т.п.

Это не относится к бусту, а относится к банальнйо некомпетентности разработчиков.

Можете раздавать лейблы какие хотите.

А если нужна, то в 99% лучше буст, чем свой велосипед из говна и палок.

я бы сказал наоборот. в 99% свой велосипед из говна и палок лучше, чем буст.

буст хорош для абстрактных форумных тёрок

я бы сказал наоборот. в 99% свой велосипед из говна и палок лучше, чем буст.

Диагноз выявлен - велосипедист.

Диагноз выявлен - велосипедист.

вы так говорите, как будто это что-то плохое!
для больших подсистем, как правило, есть шикарные решения (обычно они на c). велосипеды прекрасно их комбинируют и дополняют. а буст - тупо не нужен. точнее не так - он был-бы нужен, если-бы не мешал.

А почему велосипедостроение это хорошо? Это хорошо разве что для всяких PVSников, которые на этом бабки колотят.

Почему Вы всё упиратесь в Си? Чем Вам так С++ не угодил? Или примерно по тем же принципам, что и у Линуса? Вы там где-то выше говорили про скорость решений на Си и С++. Можете показать бенчи либ на Си и С++?

почему велосипедостроение это хорошо?

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

Почему Вы всё упиратесь в Си? Чем Вам так С++ не угодил? Или

не пытайтесь съехать на тему c|c++, тормозит именно boost. и не в силу языка, а в силу оверхеда. оптимизация шаблонов не помогает.

и да - при корректном разбиении на подсистемы - c-интерфейс получается более лаконичным и понятным. а следовательно - лучше модифицируемым.

Можете показать бенчи либ на Си и С++?

как вы себе представляете это сравнение?

про нужность

[faust@archlinux ~]$ yaourt -R boost
Пароль: 
ошибка: не найдена цель: boost
[faust@archlinux ~]$ 

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

И Вы готовы что-то написать с нуля, потратить на это кучу времени? И Вы можете гарантировать, что Ваш код будет быстрым, удобочитаемым и далее по списку? И сколько на это времени уйдёт?

не пытайтесь съехать на тему c|c++, тормозит именно boost. и не в силу языка, а в силу оверхеда. оптимизация шаблонов не помогает.

и да - при корректном разбиении на подсистемы - c-интерфейс получается более лаконичным и понятным. а следовательно - лучше модифицируемым.

А я и не пытаюсь. Вы сами завели речь про библиотеки на Си. Я всег лишь попросил пруфов, не более.

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

как вы себе представляете это сравнение?

Ну Вы же утверждали, что либы на Си будут быстрее, чем буст. Вот и мне интересно, как Вы подкрепите своё утверждение какими-либо бенчмарками.

И Вы готовы что-то написать с нуля, потратить на это кучу времени? И Вы можете гарантировать, что Ваш код будет быстрым, удобочитаемым и далее по списку? И сколько на это времени уйдёт?

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

Ну Вы же утверждали, что либы на Си будут быстрее, чем буст. Вот и мне интересно, как Вы подкрепите своё утверждение какими-либо бенчмарками.

она быстрее не потому-что «на C», а потому-что
1. проектирование на С помогает писать быстрые программы
2. компиляция и отладка на С настолько быстра, что высвобождает время на проектирование и оптимизацию см. п1

https://habrastorage.org/getpro/habr/post_images/369/674/ea7/369674ea7572a75e...

Хорошо, что odeint также отдельно поставляется.

1. проектирование на С помогает писать быстрые программы

«Проектирование на C» — это вообще что за зверь такой? Имеется в виду проектирование в рамках только процедурного подхода?

2. компиляция и отладка на С настолько быстра

Компиляция и отладка — это в принципе две разные вещи. То, что вы их смешиваете в одном предложении — это показательный звоночек.

Интересно было бы посмотреть на ваш код.

https://habrastorage.org/getpro/habr/post_images/369/674/ea7/369674ea7572a75e...

А это что вообще? Где первоисточник?

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

Что-то: Boost.Algorithm, Boost.Filesystem, Boost.Spirit, Boost.Regex, Boost.Math, Boost.Geometry. Что из этого готовы написать с нуля?

она быстрее не потому-что «на C», а потому-что 1. проектирование на С помогает писать быстрые программы 2. компиляция и отладка на С настолько быстра, что высвобождает время на проектирование и оптимизацию см. п1

1. Быстрые программы - это программы, которые быстро работают? Если да, то что Вам на C++ мешает писать такие программы. Если нет, то я не совсем понял, что значит «писать быстрые программы» в данном контексте.

2.Мне действительно интересно, как Вы так проектируете, что на Си у Вас всё моментально собиарается и работает правильно, а на крестах компилируется оооооочень долго и мешает процессу проектирования. Может Вы просто не умеете в C++ или умеете плохо? Иной причины я найти не могу.

Подскажите, пожалуйста, ссылку на источник. А там продолжим разговор.

а что с boost::serialization?

Хорошая библиотека, но такое впечатление что заброшена и не развивается. Я пару раз писал в список рассылки boost.user, но ни ответа, ни привета. Это вообще возможно, что эта или другая библиотека буста будет заброшена?

Попробуйте написать в Boost.dev . Также можно спросить в слаке, в IRC, на гитхабе.

Boost.Pool тоже немного огорчает. В целом работает, но есть что улучшать, а в доках - и исправлять. И юзеры явно есть... А движения нет.

Это вообще возможно, что эта или другая библиотека буста будет заброшена?

А что этому может помешать? Где-то обещалось, что если библиотека включена в Boost, то она теперь будет постоянно развиваться до тех пор, пока существует сам Boost?

Не... Это мы умрем раньше. :)

Ответ на эти вопросы и интересует. Какова политика Буста в случае ухода разработчика? Что будет с библиотекой? Были ли прецеденты?

Политика такова. Если либа бросается мейнтейнером и/или разработчиками, то она переходит под мейнтейнерство CMT (группа людей, которая занимается мейнтейнигом брошенных либ). CMT обычно сосредоточена на фиксе каких-то багов. Если остаётся время, то пилят что-то в либы дальше (но времени обычно нет). Если найдётся доброволец, который захочет мейнтейнить либу, то из-под CMT она переходит под нового мейнтейнера.

Прецеденты были и есть. Можно глянуть на сайте буста.

C++17 как не поддерживала, так и не поддерживает. Неужели так сложно выпилить std::unary_function и std:auto_ptr?

1) Нельзя так просто взять и дропнуть старые стандарты 2) Они просто оборачиваются в простые дефайны.

это в принципе две разные вещи.

эпоха теоретиков

Иной причины я найти не могу.

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

Boost.Pool тоже немного огорчает. В целом работает, но есть что улучшать,

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

эпоха теоретиков

Где можно увидеть ваш код, практик вы наш, непревзойденный?

Ну и тут у вас ссылку на источник картинки просили. Где она? Или вы сами кроме картинки ничего не видели?

А там так: пока С++ собирают typesafe код, который просто работает, на С надо написать в 4 раза больше кода, который быстро компилируется, а потом быстро дебажить приколы с void*, double free и разного рода stack overflow.

А там так: пока С++ собирают typesafe код, который просто работает, на С надо написать в 4 раза больше кода, который быстро компилируется, а потом быстро дебажить приколы с void*, double free и разного рода stack overflow.

это не относится к С, а относится к «банальной некомпетентности разработчиков» (с) выше

Чем замените в Си RAII. Я пример привёл выше - напишите на Си, пожалуйста, обычный контейнер - стек. Хочу посмотреть на компетентный Си код.