C++ Siberia 2019: Антон Полухин, C++ на практике

Ближайшая конференция: С++ Russia 2024, 24 мая (online), 2-3 июня (offline, Москва)
Подробности и билеты: jrg.su/W8skjE
- -
. . . Приложения чувствительные ко времени выполнения и высокая нагрузка - те сферы где C++ считается практически незаменимым. Но все ли необходимые библиотеки и инструменты доступны из коробки? Во время доклада мы по шагам создадим небольшое приложение и задумаемся о вещах, которые неплохо было бы иметь в C++.

[@Gena-ku7if]

Лектор отличный, очень интересно и воду не льёт.

[@kl45gp]

отличная презентация, спикер четко излагает , а главное не скучно

[@cppprograms5868]

Антон ты супер

[@evkh8917]

Антон, мое почтение ) я поражен Вашим талантом излагать !

[@senioreasy]

Антон - красава, всё чётко объяснил!

[@roman1324]

14:14 - создание buf можно было вынести за цикл, в цикле массив только расширять при необходимости.

[@strelok_2k]

Ребята, вот сходу скажу что очень очень нужен репозиторий библиотек и зависимостей, у нас небольшой проект под пять ОС. тратится огромное количество сил на поддежку компиляции и подключение новых бибилиотек. Возможно кто-то скажет это не проблемы языка, да это не проблемы языка, но никто не чешется сделать нечто подобное. Была вялая попытка с conan и vcpkg, но пока у меня не взлетело. Было бы очень круто если бы можно было просто перечислить все зависимости и их версии, запустить bootstrap скрипт это все появилось у разработчика внутри рабочего каталога, не в системе. Сейчас у нас лютая смесь cmake и python, это как-то более менее работает, но периодически бьет по пальцам.

[@AlexanderUstinovAD]

Сняли с языка. Вообще я не программист С++, но вот смотрю на на тулзы по сборке и понимаю что у вас там боль сплошная CMake / Make и еще куча всего. В отличии от рас, где есть cargo и он прям идет в коробке с Rust. Это не в коем случае не реклама другого языка. Просто было бы суперски здорово иметь дефолтный менеджер и стандартный репозиторий с зависимостями который шел бы с компилятором и единый формат описания по сборке проекта.

[@alexiprof]

есть такая вещь, называется conan.io

[@apivovarov2]

вы понимаете что для всех платформ держать бинарники это нереально. кроме того даже под одну платформу есть масса вариантов как сбилдить проект. какой glibc, какие флаги оптимизации и пр пр. все варианты бинарников для всего мира хранить и менеджить не удастся. Поэтому мавен или пайпай репо в c++ не получится сделать. Вариантов не много - билдить with cmake/make все third парти проекты из сурсов при билде главного проекта. Или писать бутстрап скрипт и даунлоадить сбилженые конкретно для вас депенденси из клауда. например как делает tensorflow/bazel build from source.

[@nameundef8076]

@@AlexanderUstinovAD jFrog Artifactory

[@IExSet]

А что с vcpkg не так ?

[@Anatoliy_-]

Боль... года 3 назад писал на C++ закачку и обработку большого количества постоянно генерируемых файлов по FTP. Актуальной FTP библиотеки для C++ не нашел. Самому реализовывать FTP клиента как-то не хотелось. В итоге заюзал уже давно неподдерживаемый QFtp, что как бы не очень прикольно. Отсутствие таких нужных готовых прикладных библиотек сильно ограничивает применение языка.

[@FakePlv]

Не понимаю, чего многие так боятся расширения стандартной либы. С++ это инструмент. Если хотите можете представить швейцарский нож. Но сколько функционала ему не добавляй, он ракетой никогда не станет. Кол-во хотелок к инструменту рано или поздно придет к 0, всё остальное это уже шиза в роде "я хочу чтобы с одной строчки у меня фабрика по производству дронов построилась", от которой спасет комитет. Не сможет разрастись стандартная либа настолько, чтобы её было невозможно портировать. Сейчас С++ развивается в необходимой степени, инструмент обретает удобство и качество, но он не становится чем-то другим. Ну и слава deprecated!

[@denmisanthrope3343]

Антон, спасибо за доклад. Но поясните чуть подробнее про вопрос, который вроде бы трое человек спросили, но ответы смазались. Зачем именно все нужно тащить в стандартную библиотеку? Не лучше ли в стандартной библиотеке иметь возможный минимум, который предоставляет консрукции языка, а все остальное: stl, работа с файлами, работа с сетевыми протоколами и т.д. - это иметь в виде отдельных библиотек (которые будут писаться хоть тем же комитетом и теми, кто сейчас формирует boost), а конечный пользователь под конечный продукт будет лишь сам выбирать необходимые ему компоненты, которые будут задействованы у него. Т.е. самое важное лишь иметь такое место, где будут лежать либы на подобие boost и ему подобных, на которые смотрит комитет и говорит, что да используйте их, а не рыскайте по гитхабам и не пишите свой велосипед, а лучше вносите правки в эти, если реально видите как улучшить. Ну и бонусом официальную систему сборки, которую также будут курировать и развивать, но одну, написанную также на этом же языке, а не сторонних решениях (т.е. С++ или хотя бы С), чтобы это давало гарантию, что это все будет работать на любой новой платформе, где уже есть наш язык, но далеко не факт, что есть какой-то другой.

[@AntonyPolukhin]

А зачем тянуть что-то стороннее, пусть тот же Boost, если иметь всё это в стандартной библиотеке удобнее? При этом, мы по прежнему не платим за то, что не используем - не используете вы в проекте ranges/networking, и ок, на размер вашего бинарника и производительность проекта это не влияет

[@Mihailbatkovich]

вместо вашего engine::sleep можно ли было использовать std::this_thread::sleep_for? или у вашей функции/ корутин есть преемущества перед std::this_thread::sleep_for? работает ли AFIO напрямую через операционную память как у вас в пилорамме?

[@AntonyPolukhin]

std::this_thread::sleep_for усыпит поток выполнения (std::thread). engine::Sleep снимает текущую задачу с выпонения на потоке и запускает другую готовую задачу. Тоесть engine::Sleep выгоднее, так как позволяет пользоваться потоком (вычислять на нем готовые задачи), пока мы ожидаем события по таймеру. Как AFIO работает не помню, давно не заглядывал в его исходники.

[@Mihailbatkovich]

@@AntonyPolukhin спасибо

[@apivovarov2]

многие c++ cmake проекты кладут зависимости (другие cmake проекты) в папочку 3rdparty (как git submodule). А потом в главном Cmake файле перечисляются все другие cmake проекты и все вместе билдится. например tvm.ai от китайских товарищей. Хотел спросить. это вообще нормальный подход? Может имеет смысл стандартизировать объявление зависимостей? типа как в go

[@osolovyoff]

Это модули называется и это все уже давно ждут, кстати по поводу cmake посмотри conan.io

[@iliasalaur]

Насчёт embedded можно просто использовать фреймворк который добавит то что нету в free-standing. Например тот же Arduino который портирован от ATtiny (AVR) до Stm на Arm и других архитектур. Вообще говорят что это все для детей но блин, если вам в кайф делать свой софт под каждую платформу то вы наверное assembly developer

[@thegod3500]

Значит мы получим андефейнед бихевиор и редковоспроизводимые баги, если человек намеренно передаст в функцию int и char8_t* указывающий на этот инт ? Ведь на самом деле нет гарантий что char8_t не указывает на что-то ещё

[@AntonyPolukhin]

Любимый анекдот Страуструпа: - Доктор, когда я делаю вот так, то мне больно - Тогда не делайте так! Так вот, char8_t предназначен только для символов. Если вы делаете reinterpret_cast в этот тип, то вам будет больно. Не делайте так

[@ievgenchizz9153]

можно код елочки плз)

[@ms77grz]

👍👍

[@AlexanderUstinovAD]

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

[@avazart614]

Что значит нельзя мигать и отслеживать клавиши? Так и мигать не получится, нет такой стандартной библиотеки что бы цветом подкрашивать текст в консоли. Для таких вещей нужно по любому системные вещи использовать под видной WinApi. Т.е. сразу можно использовать таймеры и обрабатывать очередь сообщений. Про файл совсем не понял. Что мешает блин считать файл в "массив байт" (буквально массив char или вектор)

[@AntonyPolukhin]

> Что мешает блин считать файл в "массив байт" (буквально массив char или вектор) Ничего не мешает. Однако вместо быстрой и эффективной работы с файлом через mmap (или его аналоги), вы сами выделяете память, сами копируете данные... Намного больше действий и меньшая эффективность.

[@kirillsh8383]

когда то писал на си и с++, потом перееш на яву и с тех пор там и оставился в JVM стэке. ну вот когда, когда в С++ стандарной библиотеке появятся все необходимые классы, структуры и возможности. вот есть же qt, там писать код одно удовольствие, почему нельзя расширить стандартную библиотеку?

[@FakePlv]

Насколько я знаю qt появился как решение для языка с древним стандартом. Сейчас же сами разрабы qt утверждают, что стоит использовать современный std вместо qt-шной иерархии, которая, на мой взгляд, местами чрезмерно перегружена. Как сказано в видео, над стандартом работают 180+ экспертов, которые решают, что пойдет языку на пользу. Да, стандарт развивается медленно, но, как говориться, семь раз отмерь, один раз отрежь. Дело не только в удобстве для разработчка, дело в качестве решения задачи и у джавы это качество часто не соответствует ожиданиям.

[@Thgq]

А можно поинтересоваться, что именно вы пишете? Сам пишу на Qt/C++ десктопные приложения и думаю куда бы отсюда свичнуться..

[@iliasalaur]

25:31 чисто я

[@joedoe1042]

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

[@apivovarov2]

сейчас стандарт де-факто это CMake. А зависимости на другие C++ проекты добавляются в папку 3rdparty в виде гит модулей.

[@joedoe1042]

@@apivovarov2 может для вас это и стандарт, а для меня это меньшее из зол.

[@apivovarov2]

@@joedoe1042 еще интересно сделан Bazel. Его использует гугл для сборки больших C++ проектов с кучей зависимостей. Например Tensorflow so 200-400MB

[@apivovarov2]

@13:56 на счет динамической аллокации памяти. Плюсовики на те же грабли что и джависты наступают. Из-за удобства где нужно и где не нужно по умолчанию используют вектор. Хотя во многих случаях можно просто массив в стеке иметь. А вектор вас даже не спрашивает где будет алоцирована пямять. Если вы нашли проблему в опенсурсной библиотеке, то можно открыть пиар и пофиксить проблему. А скорее всего код этой библиотеки и будут использовать в стандарте. Только когда этот код ляжет в стл вы уже так просто этот код не пофиксите.

[@avazart614]

А зачем засерать стек? Файл не влезет в стек. И да Java прожорливая фигня.

[@AntonyPolukhin]

Ну это начинающие плюсовики. А более продвинутые используют std::array или boost::container::stack_vector А исправлять код не ломая обратную совместимость всегда тяжело - будь то Boost, Stl, Qt, Rust, Java, ...

[@22altair22]

Что значит Алясится?

[@apivovarov2]

stackoverflow.com/questions/9709261/what-is-aliasing-and-how-does-it-affect-performance

[@VitaliyNET]

Хочется писать на ++ бекенд как на C#/java, а веб фреймворков не видать. Или я плохо ищу. То что нахожу, или мертвое или ужасно написано.

[@bagzhansadvakassov1093]

Так низкоуровнево никто не будет делать. Никогда. Где-то читал что это overkill. Преимущества в скорости уничтожаться сложностью поддержки кода.

[@user-nh5yb2uv4b]

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

[@Gena-ku7if]

Здравствуйте, посоветуйте пожалуйста книгу по QT для начинающих.

[@user-nh5yb2uv4b]

@@Gena-ku7if Макс Шлее, Профессиональное программирование на C++

[@Gena-ku7if]

@@user-nh5yb2uv4b Благодарю, Шлее я уже прочитал(((

[@user-nh5yb2uv4b]

@@Gena-ku7if ну тогда база у вас есть. Смотрите примеры - они у Qt в поставке очень неплохие

[@Gena-ku7if]

@@user-nh5yb2uv4b Да, примеры хорошие, у меня сложность с gui((( сама библиотека даже проще и удобнее стандартных C++ библиотек, а вот с интерфейсом всё время проблемы(((

[@nikitakhalov]

Такая фигня с первых минут "нельзя одновременно мигать лампочками и смотреть какую клавишу нажал пользователь" Как тогда все игры были написаны до многопточности? Как Doom работает? А GameLoop слышал понятие? Видимо нет

[@nikitakhalov]

Дальше классно, респект автору Но пример в начале совершенно на низком уровне

[@atheroot]

Пишите на Си под линуксом и проблем не будет с переходом на новые платформы.

[@apivovarov2]

Похоже Си остаётся последней надеждой... Темная сила захватила всю остальную вселенную.

[@user-vw1fg9hr8m]

pls use POLL

[@48V2pc]

Не я один использовал потоки для управления с клавиатуры!

[@iliasalaur]

А почему бы ни использовать виндовский hook или там... getAsyncKey() ?

[@antonmanin3521]

@@iliasalaur не кроссплатформенное решение

[@iliasalaur]

@@antonmanin3521 ну, так то не на каждой платформе есть несколько ядер для обеспечения работы нескольких потоков. Но справедливости ради, решение с потоками будет работать на большинстве платформ

[@antonmanin3521]

@@iliasalaur решение с потоками будет работать и на одноядерном процессоре

[@IExSet]

Скорость мутации языка конечно настораживает. Откуда лектор взял что один человек может сделать всё. За 100 лет что ли ?

[@ROMAN84600]

Так что, всё-таки c++ рулит? А то смотрю много лекций по СИ плюсам, в коментах его засирают почему-то... Если что, я не программист, только хочу изучать язык

[@user-ci4fz9co3b]

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

[@iliasalaur]

Просто в с++ что войти надо ну, года два как минимум, да и то, я в с++ уже 5 лет и из урока понял процентов 70

[@IExSet]

Рулит если понимаешь различия. Универсальных рулящих языков НЕТ ! Каждый язык подходит для своих применений, даже если на нём в принципе можно написать то что пишут на других языках. Например на асме браузер написать можно, но не очень разумно. Скриптовать на C++ можно, но скорей всего - это вызовет разные проблемы.

[@PsijicV]

Для Линуса все равно недостаточно.

[@kvasnyukstanislav244]

Ваш Линус заколебал. Си++ уродлив бла-бла-бла. Пускай он идёт нахрен. *Пишу с линукса*

[@safocl9768]

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

[@safocl9768]

@You Tube ты к чему вообще? я про сложность создания stl, а не про реализацию разрабами где то...

[@luckystrike91]

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

[@aa_artemyev]

Ну, пример для сравнения показан. 🤷🏻

[@IExSet]

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

[@user-hy4rl7rg6s]

Послушала лекцию, ничего не поняла кроме одного, что я бездарность, пошла спать с плохим настроением и с чувством, что программирование наверное всё же не для всех, тут уровень Бог нужен

[@user-rt7ei3ii6c]

для хоббийного уровня он сильно заумь гонит. так что всё норм.

[@__alexfox__]

Блин, я .net'чик нафига я это смотрю?

[@pianomusic8160]

Я сейчас учу ruby, аналогично)

[@IExSet]

Всё в порядке, просто ты латентный программист на C++/CLI :-)

[@__alexfox__]

@@IExSet Угадал, я на Rust перешел🤣

[@igorkachkovsky5700]

С++ быстрее 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, то можете продолжать тащить на скиле(если не любить другие технологии) экономя на сне либо своей любимой производительности(а читабельность проиграли).

[@cppprograms5868]

если я не ошибаюсь , по мере роста программы производительность С++ становится всё значительнее по сравнению с другими языками т.е. при работе с графикой, с большими данными и т.д. ) С++ не плохой язык программирования , да и читабельность его не сложная если не использовать сложные конструкции языка, без которых можно обходится, да если использовать всю мощь С++ то программы менее читабельны , но иногда это стоить того, так как таких программ вряд-ли напишете на jave и т.д. если напишете то будет работать медленно, при очень больших программах очень менленно, да и мы это видим т.к. да практически все большие программы написаны на С/С++.

[@igorkachkovsky5700]

​@@cppprograms5868 % узких мест к объему кода очень переменный: непрерывные вычисления(желательно с доступом к быстрой памяти), либо ожидание(пользователя, передачи данных). В первом случае, если там большие объемы для обработки - влияние значительно. Во втором - часто влияние никакое, и во главу угла ставятся другие цели(и в итоге умудряются сделать тормознутую хрень, потому что вообще забили на скорость). Например: http 1.1 - текстовый формат - изобрели, когда экономили байты. Большие программы - пишут на разных языках(часто одновременно). www.freelancinggig.com/blog/2018/07/17/top-5-largest-programs-ever-written/

[@inbuckswetrust7357]

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

[@iliasalaur]

Оу, остынь

[@IExSet]

По большому счёту новые стандарты С++ крадут все плюшки у Жабы как языка, а платформа там мегажирная, если можно без неё обойтись, то C++ будет всяко рулить.

[@tarasshevchenko7772]

Пожалуйста.... Не нужны люди из стартапов в коммитете. Там и так половину надо выгныть.

[@ponchitoseniorito1828]

Русские программисты)

[@reflechant]

Я не понимаю, а что, вызвать функции POSIX религия не позволяет? Там и mmap, и асинхронный ввод/вывод и пр. и пр. Что за странная идея делать всё только на стандартной библиотеке? Планируется деплоить это под Windows? У автора доклада (и комитета?) - синдром "фатального недостатка"?

[@RenamedChannel]

А почему бы под Windows не деплоить?

[@reflechant]

@@RenamedChannel ёлочку? Ёлочку, конечно, можно и под Windows, только там обычно к GUI привыкли, не оценят, скорее всего.

[@RenamedChannel]

@@reflechant Зачем mmap ёлочке?

[@reflechant]

@@RenamedChannel а зачем windows высоконагруженному сервису?

[@RenamedChannel]

@@reflechant А на С++ только высоконагруженные сервисы пишут?

[@dmitryopokin8651]

Rust, и ты просто пишешь

[@IExSet]

А где не просто пишешь ?

[@apivovarov2]

boost тоже в стл засунете. А потом каждое изменение будете через коммитет протаскивать и обещать светлое будущее в след версии к 2023 году. Децентрализованные системы более эффективны и гибки. Комитеты это зло!

[@AntonyPolukhin]

Какой механизм развития языка вам кажется более разумным? Распишите пожалуйста детали

[@apivovarov2]

@@AntonyPolukhin на самом деле, то как сейчас C++ восстает из мертвых говорит о том, что люди развивающие C++ делают все правильно. Одно не пойму, почему вы еще не в Санта Кларе?

[@user-gl2bt1on5p]

Смотреть противно 🤮