Ребята, вот сходу скажу что очень очень нужен репозиторий библиотек и зависимостей, у нас небольшой проект под пять ОС. тратится огромное количество сил на поддежку компиляции и подключение новых бибилиотек. Возможно кто-то скажет это не проблемы языка, да это не проблемы языка, но никто не чешется сделать нечто подобное. Была вялая попытка с conan и vcpkg, но пока у меня не взлетело. Было бы очень круто если бы можно было просто перечислить все зависимости и их версии, запустить bootstrap скрипт это все появилось у разработчика внутри рабочего каталога, не в системе. Сейчас у нас лютая смесь cmake и python, это как-то более менее работает, но периодически бьет по пальцам.
Сняли с языка. Вообще я не программист С++, но вот смотрю на на тулзы по сборке и понимаю что у вас там боль сплошная CMake / Make и еще куча всего. В отличии от рас, где есть cargo и он прям идет в коробке с Rust. Это не в коем случае не реклама другого языка. Просто было бы суперски здорово иметь дефолтный менеджер и стандартный репозиторий с зависимостями который шел бы с компилятором и единый формат описания по сборке проекта.
вы понимаете что для всех платформ держать бинарники это нереально. кроме того даже под одну платформу есть масса вариантов как сбилдить проект. какой glibc, какие флаги оптимизации и пр пр. все варианты бинарников для всего мира хранить и менеджить не удастся. Поэтому мавен или пайпай репо в c++ не получится сделать. Вариантов не много - билдить with cmake/make все third парти проекты из сурсов при билде главного проекта. Или писать бутстрап скрипт и даунлоадить сбилженые конкретно для вас депенденси из клауда. например как делает tensorflow/bazel build from source.
По поводу коммента из зала на тему "упоси и все такое", вот как раз из-за таких людей новые разработчики не приходят, так как сидят вот такие сычи и не поддержки, ничего от них не дождешься, только тупой троллинг.
Не понимаю, чего многие так боятся расширения стандартной либы. С++ это инструмент. Если хотите можете представить швейцарский нож. Но сколько функционала ему не добавляй, он ракетой никогда не станет. Кол-во хотелок к инструменту рано или поздно придет к 0, всё остальное это уже шиза в роде "я хочу чтобы с одной строчки у меня фабрика по производству дронов построилась", от которой спасет комитет. Не сможет разрастись стандартная либа настолько, чтобы её было невозможно портировать. Сейчас С++ развивается в необходимой степени, инструмент обретает удобство и качество, но он не становится чем-то другим. Ну и слава deprecated!
Боль... года 3 назад писал на C++ закачку и обработку большого количества постоянно генерируемых файлов по FTP. Актуальной FTP библиотеки для C++ не нашел. Самому реализовывать FTP клиента как-то не хотелось. В итоге заюзал уже давно неподдерживаемый QFtp, что как бы не очень прикольно. Отсутствие таких нужных готовых прикладных библиотек сильно ограничивает применение языка.
Насчёт embedded можно просто использовать фреймворк который добавит то что нету в free-standing. Например тот же Arduino который портирован от ATtiny (AVR) до Stm на Arm и других архитектур. Вообще говорят что это все для детей но блин, если вам в кайф делать свой софт под каждую платформу то вы наверное assembly developer
Такая фигня с первых минут "нельзя одновременно мигать лампочками и смотреть какую клавишу нажал пользователь" Как тогда все игры были написаны до многопточности? Как Doom работает? А GameLoop слышал понятие? Видимо нет
@13:56 на счет динамической аллокации памяти. Плюсовики на те же грабли что и джависты наступают. Из-за удобства где нужно и где не нужно по умолчанию используют вектор. Хотя во многих случаях можно просто массив в стеке иметь. А вектор вас даже не спрашивает где будет алоцирована пямять. Если вы нашли проблему в опенсурсной библиотеке, то можно открыть пиар и пофиксить проблему. А скорее всего код этой библиотеки и будут использовать в стандарте. Только когда этот код ляжет в стл вы уже так просто этот код не пофиксите.
Ну это начинающие плюсовики. А более продвинутые используют std::array или boost::container::stack_vector А исправлять код не ломая обратную совместимость всегда тяжело - будь то Boost, Stl, Qt, Rust, Java, ...
многие c++ cmake проекты кладут зависимости (другие cmake проекты) в папочку 3rdparty (как git submodule). А потом в главном Cmake файле перечисляются все другие cmake проекты и все вместе билдится. например tvm.ai от китайских товарищей. Хотел спросить. это вообще нормальный подход? Может имеет смысл стандартизировать объявление зависимостей? типа как в go
Что значит нельзя мигать и отслеживать клавиши? Так и мигать не получится, нет такой стандартной библиотеки что бы цветом подкрашивать текст в консоли. Для таких вещей нужно по любому системные вещи использовать под видной WinApi. Т.е. сразу можно использовать таймеры и обрабатывать очередь сообщений. Про файл совсем не понял. Что мешает блин считать файл в "массив байт" (буквально массив char или вектор)
> Что мешает блин считать файл в "массив байт" (буквально массив char или вектор) Ничего не мешает. Однако вместо быстрой и эффективной работы с файлом через mmap (или его аналоги), вы сами выделяете память, сами копируете данные... Намного больше действий и меньшая эффективность.
когда то писал на си и с++, потом перееш на яву и с тех пор там и оставился в JVM стэке. ну вот когда, когда в С++ стандарной библиотеке появятся все необходимые классы, структуры и возможности. вот есть же qt, там писать код одно удовольствие, почему нельзя расширить стандартную библиотеку?
Насколько я знаю qt появился как решение для языка с древним стандартом. Сейчас же сами разрабы qt утверждают, что стоит использовать современный std вместо qt-шной иерархии, которая, на мой взгляд, местами чрезмерно перегружена. Как сказано в видео, над стандартом работают 180+ экспертов, которые решают, что пойдет языку на пользу. Да, стандарт развивается медленно, но, как говориться, семь раз отмерь, один раз отрежь. Дело не только в удобстве для разработчка, дело в качестве решения задачи и у джавы это качество часто не соответствует ожиданиям.
@@ЯсенПень-ф9л Да, примеры хорошие, у меня сложность с gui((( сама библиотека даже проще и удобнее стандартных C++ библиотек, а вот с интерфейсом всё время проблемы(((
вместо вашего engine::sleep можно ли было использовать std::this_thread::sleep_for? или у вашей функции/ корутин есть преемущества перед std::this_thread::sleep_for? работает ли AFIO напрямую через операционную память как у вас в пилорамме?
std::this_thread::sleep_for усыпит поток выполнения (std::thread). engine::Sleep снимает текущую задачу с выпонения на потоке и запускает другую готовую задачу. Тоесть engine::Sleep выгоднее, так как позволяет пользоваться потоком (вычислять на нем готовые задачи), пока мы ожидаем события по таймеру. Как AFIO работает не помню, давно не заглядывал в его исходники.
Антон, спасибо за доклад. Но поясните чуть подробнее про вопрос, который вроде бы трое человек спросили, но ответы смазались. Зачем именно все нужно тащить в стандартную библиотеку? Не лучше ли в стандартной библиотеке иметь возможный минимум, который предоставляет консрукции языка, а все остальное: stl, работа с файлами, работа с сетевыми протоколами и т.д. - это иметь в виде отдельных библиотек (которые будут писаться хоть тем же комитетом и теми, кто сейчас формирует boost), а конечный пользователь под конечный продукт будет лишь сам выбирать необходимые ему компоненты, которые будут задействованы у него. Т.е. самое важное лишь иметь такое место, где будут лежать либы на подобие boost и ему подобных, на которые смотрит комитет и говорит, что да используйте их, а не рыскайте по гитхабам и не пишите свой велосипед, а лучше вносите правки в эти, если реально видите как улучшить. Ну и бонусом официальную систему сборки, которую также будут курировать и развивать, но одну, написанную также на этом же языке, а не сторонних решениях (т.е. С++ или хотя бы С), чтобы это давало гарантию, что это все будет работать на любой новой платформе, где уже есть наш язык, но далеко не факт, что есть какой-то другой.
А зачем тянуть что-то стороннее, пусть тот же Boost, если иметь всё это в стандартной библиотеке удобнее? При этом, мы по прежнему не платим за то, что не используем - не используете вы в проекте ranges/networking, и ок, на размер вашего бинарника и производительность проекта это не влияет
Значит мы получим андефейнед бихевиор и редковоспроизводимые баги, если человек намеренно передаст в функцию int и char8_t* указывающий на этот инт ? Ведь на самом деле нет гарантий что char8_t не указывает на что-то ещё
Любимый анекдот Страуструпа: - Доктор, когда я делаю вот так, то мне больно - Тогда не делайте так! Так вот, char8_t предназначен только для символов. Если вы делаете reinterpret_cast в этот тип, то вам будет больно. Не делайте так
я смотрю тут хейтят джаву, но пописав на одном и другом языке - я за джаву. насколько медленнее - настолько же удобней, проще и приятней разрабатывать.
Послушала лекцию, ничего не поняла кроме одного, что я бездарность, пошла спать с плохим настроением и с чувством, что программирование наверное всё же не для всех, тут уровень Бог нужен
единственный вопрос -- не пойму о чем речь от челов, которые грят про отсутствие СТЛ на новых платформах? ведь енто просто либа, которая использует базовые возможности языка, конструируя удобные инструменты, что бы их не надо было каждый раз каждому сочинять самому... единственная траббла в данном моменте может быть только портирование компилятора на новую платформу, однако, как представляется от большинства новых фитч он не будет портироваться сложнее или дольше, т.к. изменяться будет только низкоуровневая часть, которую в принцыпе енти новые фичи мало когда затрагивают...
Так что, всё-таки c++ рулит? А то смотрю много лекций по СИ плюсам, в коментах его засирают почему-то... Если что, я не программист, только хочу изучать язык
Рулит если понимаешь различия. Универсальных рулящих языков НЕТ ! Каждый язык подходит для своих применений, даже если на нём в принципе можно написать то что пишут на других языках. Например на асме браузер написать можно, но не очень разумно. Скриптовать на C++ можно, но скорей всего - это вызовет разные проблемы.
@@antonmanin3521 ну, так то не на каждой платформе есть несколько ядер для обеспечения работы нескольких потоков. Но справедливости ради, решение с потоками будет работать на большинстве платформ
С++ быстрее java в 100 раз(нет). Во-первых LogStash писали изначально на руби. Затем, чтобы ускорить(дефолтный интерпретатор руби работает на С) - запустили ruby код на java интерпретаторе jruby. Никаких иных сорцов java кода там практически нет. Имеет смысл говорить откуда у докладчика получились лишние блокировки(которыми и дефолтный интерпретатор ruby грешит везде)? Во-вторых некорректно сравнивать язык, когда критерием сравнения является свой код(возможно упрощенная задача) с реализованным опенсорс кодом(напр. на java много неоправданно громоздкого enterprise со своим xml. Всё из-за низкого порога входа разработчиков). Поэтому я и полез разбираться, чтобы опровергнуть докладчика. В-третьих я в своё время писал на java и с++ различные тесты типа перемножения матриц и т.п.. Всё что могу сказать, из-за того что java это платформа - то она чаще будет медленнее плюсов и жрать больше памяти. Быстрее плюсов работать будет очень редко(да, такое бывало). Если усреднить и взять не очень простую программу, то работать красиво написанный java код будет в 3 раза медленнее чем аналогичный на c++ и кушать больше памяти(3-10 раз из-за резервирования)если не прописывать в ключах запуска нужную, что на программах, где в зависимости от ситуации нужно выделить разную - предсказать не выйдет. В-четвертых код в отличие от c++ более читабелен, написан для людей. Также простой синтаксис, и проектировка java как платформы(без undefined behaviour) - делает её надежной. При чтении кода мало мест, где нужно быть внимательным. Т.е. можно прочитать код и быть уверенным в его работоспособности. В отличие от автотестов(черного ящика) - гарантия программистом что код работает как надо - очень важный параметр. Также важно, что когда придёт новый программист - он поймёт что писали до него, и реже будет лезть в ман за изучением редких операторов. Выводы. Выступление интересное, но правда в том, что многое вывернуто наизнанку и неочевидно, почему c++ имеет серьезных конкурентов. Производительность программы vs затраты на разработку. 3 раза больше скорость и меньшее потребление памяти или в 10 раз меньше порог вхождения и/или в 10 раз большая потенциальная надежность написанной программы. Т.е. если стоит задача написать максимально эффективно(чтобы сократить сервера со 100 до 30) и на это выделено время - имеет смысл переписывать на c++. Если же у вас готовый проект java(без рубей), то можно также заоптимизировать код почти как на c++, но это будет быстрее и надежнее. Особенно когда у вас один сервер, и нужно ускорить чтобы не покупать второй и не усложнять инфраструктуру. К тому же написано однажды работает везде - абсолютно справедливый лозунг если не юзать редкие фичи, которые под конкретную операционку(скомпилированную jar desktop аппликуху запускал на mac,windows,linux, где кстати из-за этого максимально абстрактный код без возможности оптимизации), . Но самый ключевой момент(для бизнеса) - если большая программа и есть пара узких мест в программе(обработка графики, и другие, где нетривиальная работа с памятью, или задачи, которые плохо подходят для JVM) можно написать dll на C++. Тогда общая производительность будет отличаться на проценты, и можно получить остальные плюшки от VM типа java и с#, дешевле и быстрее. Но если вы с++ developer, то можете продолжать тащить на скиле(если не любить другие технологии) экономя на сне либо своей любимой производительности(а читабельность проиграли).
если я не ошибаюсь , по мере роста программы производительность С++ становится всё значительнее по сравнению с другими языками т.е. при работе с графикой, с большими данными и т.д. ) С++ не плохой язык программирования , да и читабельность его не сложная если не использовать сложные конструкции языка, без которых можно обходится, да если использовать всю мощь С++ то программы менее читабельны , но иногда это стоить того, так как таких программ вряд-ли напишете на jave и т.д. если напишете то будет работать медленно, при очень больших программах очень менленно, да и мы это видим т.к. да практически все большие программы написаны на С/С++.
@@cppprograms5868 % узких мест к объему кода очень переменный: непрерывные вычисления(желательно с доступом к быстрой памяти), либо ожидание(пользователя, передачи данных). В первом случае, если там большие объемы для обработки - влияние значительно. Во втором - часто влияние никакое, и во главу угла ставятся другие цели(и в итоге умудряются сделать тормознутую хрень, потому что вообще забили на скорость). Например: http 1.1 - текстовый формат - изобрели, когда экономили байты. Большие программы - пишут на разных языках(часто одновременно). www.freelancinggig.com/blog/2018/07/17/top-5-largest-programs-ever-written/
Всегда будут задачи которые требуют на том же железе большей чем у жава производительности, те грубо говоря один два порядка значительные величины для каких-то прорывных вещей. И конечно же для большинства задач дешевле и достаточнее будет жавы. Дело то не в том что плохо а что хорошо дело в существовании ниш.
По большому счёту новые стандарты С++ крадут все плюшки у Жабы как языка, а платформа там мегажирная, если можно без неё обойтись, то C++ будет всяко рулить.
Я не понимаю, а что, вызвать функции POSIX религия не позволяет? Там и mmap, и асинхронный ввод/вывод и пр. и пр. Что за странная идея делать всё только на стандартной библиотеке? Планируется деплоить это под Windows? У автора доклада (и комитета?) - синдром "фатального недостатка"?
@@RenamedChannel только высоконагруженные (лучше будет сказать, требующие низкоуровневой оптимизации, потому что embedded тут тоже присутствует) сервисы на нём и имеет смысл писать (хотя тут есть соперник в виде С), для всего остального есть более выразительные и простые ЯП.
@@RenamedChannel можно, конечно, деплоить и под Windows. Только в более общем виде вопрос стоит так: C++ готов подменить своими абстракциями интерфейсы ОС полностью? (хотя с той скоростью, с которой этот процесс движется, я спокоен - это случится точно не на моём веку) Притом с ныне существующими это имеет хоть какой-то смысл, потому что Mac OS - UNIX-подобная, а Windows в значительной степени POSIX-совместимая (и для достижения этого Microsoft были предприняты значительные шаги). А что насчёт будущих ОС? Если вдруг появится убийца Windows и Linux, то привязанный к ним насмерть C++ сгинет вместе с ними.
@@reflechant Если вдруг появится убийца Windows и Linux, то тогда найдутся люди, которые напишут стандартную библиотеку с++ на эту платформу за месяц, и всё будет работать. Интересно, а с jvm не аналогичная ситуация?
boost тоже в стл засунете. А потом каждое изменение будете через коммитет протаскивать и обещать светлое будущее в след версии к 2023 году. Децентрализованные системы более эффективны и гибки. Комитеты это зло!
@@AntonyPolukhin на самом деле, то как сейчас C++ восстает из мертвых говорит о том, что люди развивающие C++ делают все правильно. Одно не пойму, почему вы еще не в Санта Кларе?
Лектор отличный, очень интересно и воду не льёт.
отличная презентация, спикер четко излагает , а главное не скучно
Антон - красава, всё чётко объяснил!
Ребята, вот сходу скажу что очень очень нужен репозиторий библиотек и зависимостей, у нас небольшой проект под пять ОС. тратится огромное количество сил на поддежку компиляции и подключение новых бибилиотек. Возможно кто-то скажет это не проблемы языка, да это не проблемы языка, но никто не чешется сделать нечто подобное. Была вялая попытка с conan и vcpkg, но пока у меня не взлетело. Было бы очень круто если бы можно было просто перечислить все зависимости и их версии, запустить bootstrap скрипт это все появилось у разработчика внутри рабочего каталога, не в системе. Сейчас у нас лютая смесь cmake и python, это как-то более менее работает, но периодически бьет по пальцам.
Сняли с языка. Вообще я не программист С++, но вот смотрю на на тулзы по сборке и понимаю что у вас там боль сплошная CMake / Make и еще куча всего. В отличии от рас, где есть cargo и он прям идет в коробке с Rust. Это не в коем случае не реклама другого языка. Просто было бы суперски здорово иметь дефолтный менеджер и стандартный репозиторий с зависимостями который шел бы с компилятором и единый формат описания по сборке проекта.
есть такая вещь, называется conan.io
вы понимаете что для всех платформ держать бинарники это нереально. кроме того даже под одну платформу есть масса вариантов как сбилдить проект. какой glibc, какие флаги оптимизации и пр пр. все варианты бинарников для всего мира хранить и менеджить не удастся. Поэтому мавен или пайпай репо в c++ не получится сделать.
Вариантов не много - билдить with cmake/make все third парти проекты из сурсов при билде главного проекта.
Или писать бутстрап скрипт и даунлоадить сбилженые конкретно для вас депенденси из клауда.
например как делает tensorflow/bazel build from source.
@@AlexanderUstinovAD jFrog Artifactory
А что с vcpkg не так ?
Антон, мое почтение ) я поражен Вашим талантом излагать !
14:14 - создание buf можно было вынести за цикл, в цикле массив только расширять при необходимости.
Антон ты супер
По поводу коммента из зала на тему "упоси и все такое", вот как раз из-за таких людей новые разработчики не приходят, так как сидят вот такие сычи и не поддержки, ничего от них не дождешься, только тупой троллинг.
Не понимаю, чего многие так боятся расширения стандартной либы. С++ это инструмент. Если хотите можете представить швейцарский нож. Но сколько функционала ему не добавляй, он ракетой никогда не станет. Кол-во хотелок к инструменту рано или поздно придет к 0, всё остальное это уже шиза в роде "я хочу чтобы с одной строчки у меня фабрика по производству дронов построилась", от которой спасет комитет. Не сможет разрастись стандартная либа настолько, чтобы её было невозможно портировать. Сейчас С++ развивается в необходимой степени, инструмент обретает удобство и качество, но он не становится чем-то другим. Ну и слава deprecated!
Боль... года 3 назад писал на C++ закачку и обработку большого количества постоянно генерируемых файлов по FTP. Актуальной FTP библиотеки для C++ не нашел. Самому реализовывать FTP клиента как-то не хотелось. В итоге заюзал уже давно неподдерживаемый QFtp, что как бы не очень прикольно.
Отсутствие таких нужных готовых прикладных библиотек сильно ограничивает применение языка.
Насчёт embedded можно просто использовать фреймворк который добавит то что нету в free-standing. Например тот же Arduino который портирован от ATtiny (AVR) до Stm на Arm и других архитектур. Вообще говорят что это все для детей но блин, если вам в кайф делать свой софт под каждую платформу то вы наверное assembly developer
может комитет запилит стандартную систему сборки, т.к. те которые имеются сейчас это дно.
сейчас стандарт де-факто это CMake. А зависимости на другие C++ проекты добавляются в папку 3rdparty в виде гит модулей.
@@apivovarov2 может для вас это и стандарт, а для меня это меньшее из зол.
@@joedoe1042 еще интересно сделан Bazel. Его использует гугл для сборки больших C++ проектов с кучей зависимостей. Например Tensorflow so 200-400MB
Такая фигня с первых минут "нельзя одновременно мигать лампочками и смотреть какую клавишу нажал пользователь"
Как тогда все игры были написаны до многопточности? Как Doom работает? А GameLoop слышал понятие? Видимо нет
Дальше классно, респект автору
Но пример в начале совершенно на низком уровне
@13:56 на счет динамической аллокации памяти. Плюсовики на те же грабли что и джависты наступают. Из-за удобства где нужно и где не нужно по умолчанию используют вектор. Хотя во многих случаях можно просто массив в стеке иметь. А вектор вас даже не спрашивает где будет алоцирована пямять.
Если вы нашли проблему в опенсурсной библиотеке, то можно открыть пиар и пофиксить проблему.
А скорее всего код этой библиотеки и будут использовать в стандарте. Только когда этот код ляжет в стл вы уже так просто этот код не пофиксите.
А зачем засерать стек? Файл не влезет в стек.
И да Java прожорливая фигня.
Ну это начинающие плюсовики. А более продвинутые используют std::array или boost::container::stack_vector
А исправлять код не ломая обратную совместимость всегда тяжело - будь то Boost, Stl, Qt, Rust, Java, ...
многие c++ cmake проекты кладут зависимости (другие cmake проекты) в папочку 3rdparty (как git submodule). А потом в главном Cmake файле перечисляются все другие cmake проекты и все вместе билдится. например tvm.ai от китайских товарищей.
Хотел спросить. это вообще нормальный подход? Может имеет смысл стандартизировать объявление зависимостей? типа как в go
Это модули называется и это все уже давно ждут, кстати по поводу cmake посмотри conan.io
pls use POLL
Что значит нельзя мигать и отслеживать клавиши?
Так и мигать не получится, нет такой стандартной библиотеки что бы цветом подкрашивать текст в консоли.
Для таких вещей нужно по любому системные вещи использовать под видной WinApi.
Т.е. сразу можно использовать таймеры и обрабатывать очередь сообщений.
Про файл совсем не понял. Что мешает блин считать файл в "массив байт" (буквально массив char или вектор)
> Что мешает блин считать файл в "массив байт" (буквально массив char или вектор)
Ничего не мешает. Однако вместо быстрой и эффективной работы с файлом через mmap (или его аналоги), вы сами выделяете память, сами копируете данные... Намного больше действий и меньшая эффективность.
когда то писал на си и с++, потом перееш на яву и с тех пор там и оставился в JVM стэке.
ну вот когда, когда в С++ стандарной библиотеке появятся все необходимые классы, структуры и возможности.
вот есть же qt, там писать код одно удовольствие, почему нельзя расширить стандартную библиотеку?
Насколько я знаю qt появился как решение для языка с древним стандартом. Сейчас же сами разрабы qt утверждают, что стоит использовать современный std вместо qt-шной иерархии, которая, на мой взгляд, местами чрезмерно перегружена. Как сказано в видео, над стандартом работают 180+ экспертов, которые решают, что пойдет языку на пользу. Да, стандарт развивается медленно, но, как говориться, семь раз отмерь, один раз отрежь. Дело не только в удобстве для разработчка, дело в качестве решения задачи и у джавы это качество часто не соответствует ожиданиям.
А можно поинтересоваться, что именно вы пишете? Сам пишу на Qt/C++ десктопные приложения и думаю куда бы отсюда свичнуться..
можно код елочки плз)
Пишите на Си под линуксом и проблем не будет с переходом на новые платформы.
c Qt в комитет ребят звать нужно, они для простых людей библиотеки делают
Здравствуйте, посоветуйте пожалуйста книгу по QT для начинающих.
@@Gena-ku7if Макс Шлее, Профессиональное программирование на C++
@@ЯсенПень-ф9л Благодарю, Шлее я уже прочитал(((
@@Gena-ku7if ну тогда база у вас есть. Смотрите примеры - они у Qt в поставке очень неплохие
@@ЯсенПень-ф9л Да, примеры хорошие, у меня сложность с gui((( сама библиотека даже проще и удобнее стандартных C++ библиотек, а вот с интерфейсом всё время проблемы(((
вместо вашего engine::sleep можно ли было использовать std::this_thread::sleep_for? или у вашей функции/ корутин есть преемущества перед std::this_thread::sleep_for?
работает ли AFIO напрямую через операционную память как у вас в пилорамме?
std::this_thread::sleep_for усыпит поток выполнения (std::thread). engine::Sleep снимает текущую задачу с выпонения на потоке и запускает другую готовую задачу. Тоесть engine::Sleep выгоднее, так как позволяет пользоваться потоком (вычислять на нем готовые задачи), пока мы ожидаем события по таймеру.
Как AFIO работает не помню, давно не заглядывал в его исходники.
@@AntonyPolukhin спасибо
25:31 чисто я
Антон, спасибо за доклад. Но поясните чуть подробнее про вопрос, который вроде бы трое человек спросили, но ответы смазались.
Зачем именно все нужно тащить в стандартную библиотеку? Не лучше ли в стандартной библиотеке иметь возможный минимум, который предоставляет консрукции языка, а все остальное: stl, работа с файлами, работа с сетевыми протоколами и т.д. - это иметь в виде отдельных библиотек (которые будут писаться хоть тем же комитетом и теми, кто сейчас формирует boost), а конечный пользователь под конечный продукт будет лишь сам выбирать необходимые ему компоненты, которые будут задействованы у него.
Т.е. самое важное лишь иметь такое место, где будут лежать либы на подобие boost и ему подобных, на которые смотрит комитет и говорит, что да используйте их, а не рыскайте по гитхабам и не пишите свой велосипед, а лучше вносите правки в эти, если реально видите как улучшить. Ну и бонусом официальную систему сборки, которую также будут курировать и развивать, но одну, написанную также на этом же языке, а не сторонних решениях (т.е. С++ или хотя бы С), чтобы это давало гарантию, что это все будет работать на любой новой платформе, где уже есть наш язык, но далеко не факт, что есть какой-то другой.
А зачем тянуть что-то стороннее, пусть тот же Boost, если иметь всё это в стандартной библиотеке удобнее? При этом, мы по прежнему не платим за то, что не используем - не используете вы в проекте ranges/networking, и ок, на размер вашего бинарника и производительность проекта это не влияет
Значит мы получим андефейнед бихевиор и редковоспроизводимые баги, если человек намеренно передаст в функцию int и char8_t* указывающий на этот инт ? Ведь на самом деле нет гарантий что char8_t не указывает на что-то ещё
Любимый анекдот Страуструпа:
- Доктор, когда я делаю вот так, то мне больно
- Тогда не делайте так!
Так вот, char8_t предназначен только для символов. Если вы делаете reinterpret_cast в этот тип, то вам будет больно. Не делайте так
Хочется писать на ++ бекенд как на C#/java, а веб фреймворков не видать. Или я плохо ищу. То что нахожу, или мертвое или ужасно написано.
Так низкоуровнево никто не будет делать. Никогда. Где-то читал что это overkill. Преимущества в скорости уничтожаться сложностью поддержки кода.
Что значит Алясится?
stackoverflow.com/questions/9709261/what-is-aliasing-and-how-does-it-affect-performance
Похоже Си остаётся последней надеждой... Темная сила захватила всю остальную вселенную.
👍👍
я смотрю тут хейтят джаву, но пописав на одном и другом языке - я за джаву. насколько медленнее - настолько же удобней, проще и приятней разрабатывать.
Ну, пример для сравнения показан. 🤷🏻
Низкий порог вхождения привлекает обезьян и в итоге получаются решения в 100 раз медленней C++, а на деле Java может быть не так плоха.
Послушала лекцию, ничего не поняла кроме одного, что я бездарность, пошла спать с плохим настроением и с чувством, что программирование наверное всё же не для всех, тут уровень Бог нужен
для хоббийного уровня он сильно заумь гонит. так что всё норм.
единственный вопрос -- не пойму о чем речь от челов, которые грят про отсутствие СТЛ на новых платформах? ведь енто просто либа, которая использует базовые возможности языка, конструируя удобные инструменты, что бы их не надо было каждый раз каждому сочинять самому...
единственная траббла в данном моменте может быть только портирование компилятора на новую платформу, однако, как представляется от большинства новых фитч он не будет портироваться сложнее или дольше, т.к. изменяться будет только низкоуровневая часть, которую в принцыпе енти новые фичи мало когда затрагивают...
@You Tube ты к чему вообще? я про сложность создания stl, а не про реализацию разрабами где то...
Так что, всё-таки c++ рулит? А то смотрю много лекций по СИ плюсам, в коментах его засирают почему-то... Если что, я не программист, только хочу изучать язык
Ассемблер рулит гы... А если серьезно, Си отличный язык, а алгоритм продумывать за ранее надо, оптимизация это называется.
Просто в с++ что войти надо ну, года два как минимум, да и то, я в с++ уже 5 лет и из урока понял процентов 70
Рулит если понимаешь различия. Универсальных рулящих языков НЕТ ! Каждый язык подходит для своих применений, даже если на нём в принципе можно написать то что пишут на других языках. Например на асме браузер написать можно, но не очень разумно. Скриптовать на C++ можно, но скорей всего - это вызовет разные проблемы.
Не я один использовал потоки для управления с клавиатуры!
А почему бы ни использовать виндовский hook или там... getAsyncKey() ?
@@iliasalaur не кроссплатформенное решение
@@antonmanin3521 ну, так то не на каждой платформе есть несколько ядер для обеспечения работы нескольких потоков. Но справедливости ради, решение с потоками будет работать на большинстве платформ
@@iliasalaur решение с потоками будет работать и на одноядерном процессоре
Скорость мутации языка конечно настораживает. Откуда лектор взял что один человек может сделать всё. За 100 лет что ли ?
Для Линуса все равно недостаточно.
С++ быстрее java в 100 раз(нет).
Во-первых LogStash писали изначально на руби. Затем, чтобы ускорить(дефолтный интерпретатор руби работает на С) - запустили ruby код на java интерпретаторе jruby. Никаких иных сорцов java кода там практически нет. Имеет смысл говорить откуда у докладчика получились лишние блокировки(которыми и дефолтный интерпретатор ruby грешит везде)?
Во-вторых некорректно сравнивать язык, когда критерием сравнения является свой код(возможно упрощенная задача) с реализованным опенсорс кодом(напр. на java много неоправданно громоздкого enterprise со своим xml. Всё из-за низкого порога входа разработчиков). Поэтому я и полез разбираться, чтобы опровергнуть докладчика.
В-третьих я в своё время писал на java и с++ различные тесты типа перемножения матриц и т.п.. Всё что могу сказать, из-за того что java это платформа - то она чаще будет медленнее плюсов и жрать больше памяти. Быстрее плюсов работать будет очень редко(да, такое бывало). Если усреднить и взять не очень простую программу, то работать красиво написанный java код будет в 3 раза медленнее чем аналогичный на c++ и кушать больше памяти(3-10 раз из-за резервирования)если не прописывать в ключах запуска нужную, что на программах, где в зависимости от ситуации нужно выделить разную - предсказать не выйдет.
В-четвертых код в отличие от c++ более читабелен, написан для людей. Также простой синтаксис, и проектировка java как платформы(без undefined behaviour) - делает её надежной. При чтении кода мало мест, где нужно быть внимательным. Т.е. можно прочитать код и быть уверенным в его работоспособности. В отличие от автотестов(черного ящика) - гарантия программистом что код работает как надо - очень важный параметр. Также важно, что когда придёт новый программист - он поймёт что писали до него, и реже будет лезть в ман за изучением редких операторов.
Выводы. Выступление интересное, но правда в том, что многое вывернуто наизнанку и неочевидно, почему c++ имеет серьезных конкурентов. Производительность программы vs затраты на разработку. 3 раза больше скорость и меньшее потребление памяти или в 10 раз меньше порог вхождения и/или в 10 раз большая потенциальная надежность написанной программы. Т.е. если стоит задача написать максимально эффективно(чтобы сократить сервера со 100 до 30) и на это выделено время - имеет смысл переписывать на c++. Если же у вас готовый проект java(без рубей), то можно также заоптимизировать код почти как на c++, но это будет быстрее и надежнее. Особенно когда у вас один сервер, и нужно ускорить чтобы не покупать второй и не усложнять инфраструктуру. К тому же написано однажды работает везде - абсолютно справедливый лозунг если не юзать редкие фичи, которые под конкретную операционку(скомпилированную jar desktop аппликуху запускал на mac,windows,linux, где кстати из-за этого максимально абстрактный код без возможности оптимизации), .
Но самый ключевой момент(для бизнеса) - если большая программа и есть пара узких мест в программе(обработка графики, и другие, где нетривиальная работа с памятью, или задачи, которые плохо подходят для JVM) можно написать dll на C++. Тогда общая производительность будет отличаться на проценты, и можно получить остальные плюшки от VM типа java и с#, дешевле и быстрее. Но если вы с++ developer, то можете продолжать тащить на скиле(если не любить другие технологии) экономя на сне либо своей любимой производительности(а читабельность проиграли).
если я не ошибаюсь , по мере роста программы производительность С++ становится всё значительнее по сравнению с другими языками т.е. при работе с графикой, с большими данными и т.д. ) С++ не плохой язык программирования , да и читабельность его не сложная если не использовать сложные конструкции языка, без которых можно обходится, да если использовать всю мощь С++ то программы менее читабельны , но иногда это стоить того, так как таких программ вряд-ли напишете на jave и т.д. если напишете то будет работать медленно, при очень больших программах очень менленно, да и мы это видим т.к. да практически все большие программы написаны на С/С++.
@@cppprograms5868 % узких мест к объему кода очень переменный: непрерывные вычисления(желательно с доступом к быстрой памяти), либо ожидание(пользователя, передачи данных). В первом случае, если там большие объемы для обработки - влияние значительно. Во втором - часто влияние никакое, и во главу угла ставятся другие цели(и в итоге умудряются сделать тормознутую хрень, потому что вообще забили на скорость). Например: http 1.1 - текстовый формат - изобрели, когда экономили байты. Большие программы - пишут на разных языках(часто одновременно). www.freelancinggig.com/blog/2018/07/17/top-5-largest-programs-ever-written/
Всегда будут задачи которые требуют на том же железе большей чем у жава производительности, те грубо говоря один два порядка значительные величины для каких-то прорывных вещей. И конечно же для большинства задач дешевле и достаточнее будет жавы. Дело то не в том что плохо а что хорошо дело в существовании ниш.
Оу, остынь
По большому счёту новые стандарты С++ крадут все плюшки у Жабы как языка, а платформа там мегажирная, если можно без неё обойтись, то C++ будет всяко рулить.
Блин, я .net'чик нафига я это смотрю?
Я сейчас учу ruby, аналогично)
Всё в порядке, просто ты латентный программист на C++/CLI :-)
@@IExSet Угадал, я на Rust перешел🤣
Русские программисты)
Я не понимаю, а что, вызвать функции POSIX религия не позволяет? Там и mmap, и асинхронный ввод/вывод и пр. и пр. Что за странная идея делать всё только на стандартной библиотеке? Планируется деплоить это под Windows? У автора доклада (и комитета?) - синдром "фатального недостатка"?
@@RenamedChannel ёлочку? Ёлочку, конечно, можно и под Windows, только там обычно к GUI привыкли, не оценят, скорее всего.
@@RenamedChannel а зачем windows высоконагруженному сервису?
@@RenamedChannel только высоконагруженные (лучше будет сказать, требующие низкоуровневой оптимизации, потому что embedded тут тоже присутствует) сервисы на нём и имеет смысл писать (хотя тут есть соперник в виде С), для всего остального есть более выразительные и простые ЯП.
@@RenamedChannel можно, конечно, деплоить и под Windows. Только в более общем виде вопрос стоит так: C++ готов подменить своими абстракциями интерфейсы ОС полностью? (хотя с той скоростью, с которой этот процесс движется, я спокоен - это случится точно не на моём веку) Притом с ныне существующими это имеет хоть какой-то смысл, потому что Mac OS - UNIX-подобная, а Windows в значительной степени POSIX-совместимая (и для достижения этого Microsoft были предприняты значительные шаги). А что насчёт будущих ОС? Если вдруг появится убийца Windows и Linux, то привязанный к ним насмерть C++ сгинет вместе с ними.
@@reflechant Если вдруг появится убийца Windows и Linux, то тогда найдутся люди, которые напишут стандартную библиотеку с++ на эту платформу за месяц, и всё будет работать. Интересно, а с jvm не аналогичная ситуация?
Пожалуйста.... Не нужны люди из стартапов в коммитете. Там и так половину надо выгныть.
Rust, и ты просто пишешь
А где не просто пишешь ?
boost тоже в стл засунете. А потом каждое изменение будете через коммитет протаскивать и обещать светлое будущее в след версии к 2023 году.
Децентрализованные системы более эффективны и гибки. Комитеты это зло!
Какой механизм развития языка вам кажется более разумным? Распишите пожалуйста детали
@@AntonyPolukhin на самом деле, то как сейчас C++ восстает из мертвых говорит о том, что люди развивающие C++ делают все правильно. Одно не пойму, почему вы еще не в Санта Кларе?
Смотреть противно 🤮