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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

25:31 чисто я

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

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

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

👍👍

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

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

pls use POLL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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