Евгений Охотников
@eao197
Велосипедостроитель, программист-камикадзе
Информация
- В рейтинге
- Не участвует
- Откуда
- Гомель, Гомельская обл., Беларусь
- Зарегистрирован
- Активность
Велосипедостроитель, программист-камикадзе
Ваш аккаунт
А вот Boost с такой целью как раз и создавался. Да это была не единственная цель. Но она декларировалась изначально.
Можно и дальше выносить людям мозг вокруг термина «полигон», а можно принять вещи такими, какие они есть. Из существующих C++ных библиотек только Boost можно назвать полигоном для развития C++.
Простите мне мой французкий, но про то, как развивается C++ столько уже рассказывалось в разных местах, что запомнить это гораздо проще, чем освоить Хаскель. В C++ попадает то, что было оформлено в качестве предложений. И те из предложений, которые были приняты комитетом. И не просто приняты, а доработаны до состояния, позволяющего включить их в стандарт.
Очевидно же, что не все, что попало в Boost, было оформлено в виде предложений. И не все, что было оформлено, прошло через сито комитета. Более того, какие-то вещи тупо устарели. Вот тот же Boost.Lambda. Который не нужен в C++11. Или тот же Boost.Preprocessor, актуальность которого снизилась после появления variadic templates в C++11. И еще больше снизится после добавления рефлексии.
Ну вот элементарные же вещи. Почему их снова и снова приходится объяснять?
Мои слова относились к конкретному примеру. В котором, вынужден повторить еще раз, нет проблем.
Вы уж определитесь, мне вы говорите или «вам нужна публичность». Поскольку мне говорить не нужно, ибо:
1. Я вас об этом не просил.
2. Трюки с ADL и без вас знаю.
И, поскольку до вас в вашей убежденности, все еще не доходит, вынужден еще раз повторить: меня интересовали ответы на вопросы «Почему?» и «Что взамен?». Ответы давно были получены, к счастью, задолго до вашего подключения к разговору.
В конкретном примере могли бы передать только то, для чего определены std::begin/end. Все остальное — это ваши фантазии на тему «что могло бы быть если бы». И на эту тему я вас уже сказал: в мире полно кода, который написан под конкретные условия, и который даже компилироваться не будет, если условия поменяются. Это обыденность.
Статью напишите, публичности будет многократно больше. А так есть ощущение, что вы пытаетесь меня вылечить от того, чем я не болею.
Не носите, кто ж заставляет. У меня ситуация немного другая. Во-первых, я сам довольно старый и недостаточно умный, чтобы таки освоить C++ полностью. Во-вторых, так уж получилось, что мне приходилось иметь дело с реальным кодом, который, так уж получается, пишут люди, которые знают C++ еще хуже меня.
Да, я спросил, мне объяснили. Мотивация комитета меня не впечатлила, но комитету в данном случае виднее. Что предлагается делать взамен я понял. Опять же, лопатить, при случае старый код, корни которого идут в конец 90-х и начало 2000-х, из-за нововведений C++20 не очень приятно, но комитету в данном случае виднее, вероятно. Опять же за приведение говнокода в нормальный вид платят, так что подобные нововведения в этом смысле можно только приветствовать.
Вообще-то речи о том, хорошо это или нет не было. Вас об этом я не спрашивал. И ваше мнение по этому вопросу меня вообще не интересовало. Свои вопросы я задал, ответы получил, почему меня этот момент заинтересовал я пояснил.
У вас, как я понимаю, есть желание донести до меня свою точку зрения. Напрасно.
Плохой это код или хороший — это тема отдельного разговора. Важно то, что легальный код до C++20 перестает таким быть в C++20.
А в C++20 это сделают уже нелегальным. Соответственно, отсюда и вопросы «Почему?» и «Что взамен?». А уж вопрос, что делать с унаследованным кодом «недостаточного качества» обсуждать на Хабре не имеет смысла.
Ну и попутный вопрос: как много C++ников знают, как правильно написать swap для собственного класса? И сколько из них напишут в своем swap-е предварительно using std::swap?
Поэтому любая работающая и широко использующаяся библиотека, особенно если она существует не один год, неизбежно вбирает себя пожелания и замечания большого количества разных людей. И многие решения в библиотеке становятся следствием компромисов, о причинах которых сторонний наблюдатель может вообще не иметь никакого представления.
Вот вам не нравится то, что socket в конструкторе получает io_context. А нам, наоборот, очень удобно, что у любого socket-а можно вызвать get_executor и с его помощью запостить IO-операцию на соответствующий контекст. Если кто-то развяжет socket с io_context-ом, то нам придется вместо работы с одним socket-ом делать работу с парой из socket и io_context.
Может быть это и не страшно. Но проблема в том, как это проверить. Вот существующий Asio есть и удобство работы с ним в тех или иных условиях проверяется элементарно. А модифицированного Asio с вашими предложениями нет. И как проверить, станет ли нам проще и удобнее или не станет?
Обсуждения на Хабре здесь никак не помогут. Отсюда и вот это.
Если сей момент реально представляет проблему, то пока не появится альтернатива Asio или модифицированная версия Asio, проблема не решиться. Поэтому единственный полезный шаг, который могут сделать люди, чем-то недовольные Asio, — это предложить реальную альтернативу Asio.
PS. На всякий случай: ваши комментарии я не минусовал, т.к. вашу точку зрения я понимаю.
Сейчас выбор простой: либо брать что-то из существующего (Asio, ACE, libev, libuv), либо ждать, пока кто-нибудь родит еще более лучший вариант. Как показывает жизнь, ждать можно до второго пришествия. Так что в сложившейся ситуации Asio как база для Networking TS не самый плохой результат. И, главное, вполне себе осязаемый в ближайшем будущем.
В комментариях на Хабре? Так это не борьба, это всего лишь «выпуск пара».
Если не плодить реализации, то реальной альтернативы Asio не будет. И в stdlib пойдет именно Asio. Посему если что-то не нравится, то нужно сделать свою реализацию и предложить ее комитету. В противном случае разговоры в камментах так и останутся разговорами в камментах.
И убеждает меня в этом, во-первых, то, что вы не понимаете того, о чем пытаетесь рассуждать. Например, не понимаете того, как развиваются большие программные проекты. Не понимаете того, как что-то попадает в стандарт. Отсюда у ваши вопросы о том, почему еще не весь Boost в stdlib.
Во-вторых, тот факт, что вы не понимаете и выворачиваете наизнанку то, что вам говорят. Например, из слов «Вообще-то Boost в свое время и создавался для того, чтобы стать полигоном, на котором будут проходить проверку вещи, которые затем войдут в stdlib.» вовсе не следует, что все из Boost-а попадет в stdlib. Как и не следует того, что в stdlib что-то может попасть только из буста.
Так же из слов «Т.е. служат базой, на которой можно строить сторонние библиотеки. Вот появился в stdlib тип std::vector и пропала необходимость иметь его аналог в каждой большой библиотеке.» вовсе не следует то, что с появлением STL все старые библиотек должны были быть переписаны на STL. А только то, что в новых библиотеках уже нет необходимости переизобретать то, что уже есть в STL. Что вы сможете увидеть в библиотеках, появившихся после С++98. Возьмите, к примеру, Boost. Там ведь не делают заново std::string или std::vector. Возьмите Catch2, spdlog, fmtlib. Возможности stdlib там активно применяются.
Опять же, из-за того, что вы не понимаете, как развиваются большие программные проекты, вы не можете увидеть подтверждение моих слов в том факте, что в Qt была добавлена поддержка std::string. Которой раньше в Qt не было. Но появилась, и сделала интеграцию с Qt многократно проще. Про то, чтобы из Qt выбросили QtCore речи не было. И то, что вы переводите разговор именно в такое русло, говорит лишь о том, что цитата Владимира Ильича более чем верна в вашем случае.
Про манифест Boost-а. Там до сих пор есть такая PDF-ка: www.boost.org/users/proposal.pdf
Вот с такими словами: «Secondary goals include encouraging effective programming techniques and providing a focal point for C++ programmers to participate in a wider community. Additionally, such a site might foster C++ standards activity by helping to establish existing practice.»
Вот это — might foster C++ standards activity by helping to establish existing practice — оно и есть.
Во-первых, «это» — это что?
Во-вторых, если «это» в stdlib не нужно, то что нужно?
Не просто, но вы вряд ли понимаете.
Вы не поняли. Речь не про то, чтобы кто-то выкинул Qt или изрядную его часть. Речь про то, что stdlib позволяет взаимодействовать Qt с другими библиотеками. Например, в свое время, уже при наличии C++98, в Qt не было поддержки std::string. Вообще. Потом добавили. Это как раз в тему про vocabulary types.
Что в словах о том, что Boost был сделан для того, чтобы из него копировать в stdlib, вам не понятно?
И да, если вам не понятно, то Boost используют далеко не все C++ники. И нравится он так же не всем, по целому ряду причин.
Когда логов не больше 1GiB, то с ними и Ruby без проблем справляется. А когда многократно больше объема ОП, то не только лишь все захотят бодаться с Хаскелем вообще и ленивостью+GC в частности.
Да куда нам до вас. Вы вот и Хаскель знаете, и как бороться с ним на больших объемах данных так же. Только вы лишний раз подчеркиваете, что множество C++ников с множеством Хаскелистов практически не пересекается. Так далеко не все C++ники для решения задач, связанных с производительностью, будут брать Хаскель в принципе. В чем, собственно и был поинт.
А еще ленивость и GC. И тот прискорбный факт, что на 100 действующих C++ников найдется всего один, кто сможет что-то работающее на Хаскеле написать. Ну может два. Или даже три, если второй и третий говорят об этом на профильном форуме в Интернете.