Михаил Матросов (mmatrosov) — ведущий инженер по разработке в московском R&D-офисе Align Technology. Его специализация весьма необычна — он разрабатывает специализированную CAD-систему для дизайна ортодонтических приспособлений.
Михаил участвует в C++ Russia с самой первой конференции. В этом году на С++ Russia 2019 Piter он выступит с докладом «Спецификаторы, квалификаторы и шаблоны». Вы также можете его знать по курсам от Яндекса «Основы разработки на С++: коричневый пояс» и «Основы разработки на С++: чёрный пояс» на Coursera, в создании которых Михаил выступил соавтором.
Конференция уже на носу, а пока ловите интервью с Михаилом, где мы обсудили его работу в Align Technology, миграцию легаси-кода, подготовку онлайн-курсов и докладов, а также особенности C++. Вопросы задавали Павел Филонов (программный комитет C++ Russia) и Олег Чирухин (журналист JUG Ru Group).
На стыке технологий и медицины
Павел: Расскажи, чем твоя компания занимается.
Михаил: Align Technology — пионер и лидер на рынке чистой ортодонтии. Это такая штука, которая делается сейчас во всем мире вместо брекетов. Если раньше для правки зубов ставилась металлическая проволока, и с ней бегали, то сейчас вместо этого надеваете прозрачные пластиковые капы (алайнеры), которые делаются индивидуально для каждого пациента. Недавно опробовал на себе продукцию нашей компании, очень забавные ощущения!
Павел: То есть у тебя такой dogfooding, да, получается?
Михаил: Да, вроде того. На самом деле, если не знаешь, то очень сложно заметить, что человек в алайнерах. Разве что поначалу с непривычки появляются небольшие дефекты речи, но даже их сложно заметить.
Павел: А при чем здесь C++, о котором сегодня будем много говорить?
Михаил: Отличный вопрос. Когда компания только зарождалась, в ней два веселых пакистанца брали какой-то специальный пластик (не знаю, откуда они его нашли), который должен быть нетоксичен и инертен со слюной и прочими веществами во рту.
Затем брали модель челюсти пациента, которую умели делать уже очень давно. Например, чтобы сделать коронки, человеку давали прикусить что-то вроде специального пластилина. Оставался слепок зубов, который заполняли материалом. Так получали копию челюсти, и на нее натягивали пластик (как-то разогревали), и капа готова. То есть весь этот рынок буквально 20 лет назад был полностью аналоговым.
Сейчас объем производства в районе 300−400 тысяч алайнеров в день (прошу оценить масштабы). Это гигантские производства, поэтому они полностью автоматизированы.
Для создания алайнера мы печатаем на специальном 3D-принтере молд. Это, по сути, копия челюсти пациента в процессе лечения. Мы моделируем, как будет выглядеть челюсть через неделю, две, месяц, год. Дальше мы запускаем процесс термоформинга — мы берем пластиковую ленту, разогреваем ее и натягиваем на молд. Отрезаем и получаем пластиковый алайнер.
На текущий момент слепки пациентов никто уже не делает, а используют трехмерные интраоральные сканеры. У нас этим занимаются ребята в соседнем офисе. Наверное, это самая «вау-часть» нашего производства. Там в реальном времени специальной насадкой ведут по челюсти и строят её форму. Информация загружается на сервера компании, обрабатывается и отправляется нашим специалистам (техникам). Они могут редактировать скан, убрать шумы.
Потом в специализированной CAD-системе планируется лечение. Это очень сложная штука, потому что никто не знает, что такое правильный прикус. У каждого врача есть свой взгляд на это дело. Мы сейчас ведём работу по формализации подходов к лечению, но в проде этого пока нет.
Но вернемся к C++. Есть например такая задача. Молды печатаются на специальном 3D принтере по технологии лазерной стереолитографии. Есть большой чан со специальной фотополимерной жидкостью. На неё светят лазером и она затвердевает. Сначала светят на самую нижнюю часть печатаемой модели, потом чуть выше, ещё выше и т.д. И вот так внутри жидкости снизу вверх по слоям появляется твёрдая модель.
Печатать по такой технологии молды по одному было бы непрактично. Чан довольно большой и в него можно засунуть около сотни молдов. Но их надо компактно расположить. Форма у молда похожа на подкову — то есть невыпуклая и довольно сложная. И все они отличаются. Получается интересная задача замощения прямоугольника сложными фигурами.
Вот на этом видео с указанной временной отметки видно, как это выглядит.
Это только один пример, задач очень много.
Павел: Твои описания похожи на наукоемкие вычисления. В них исторически хорошо зарекомендовали себя такие языки, как Fortran. По крайней мере, можно до сих пор встретить отголоски. Почему именно C++?
Михаил: Хорошо, что не Fortran, было бы совсем мощно. В самом начале разработки главным продуктом была эта самая специализированная CAD-система — десктопное приложение под Windows. Поэтому был нужен язык для эффективных вычислений и одновременно для разработки самого приложения. В то время выбора особо не было — только C++.
Сейчас у нас зоопарк языков: JavaScript и TypeScript для веба, Java для мобильных приложений, Go для серверов, Python для автоматизации, ну и куча всего по мелочи. В принципе, стандартный стек. А в наукоемких и вычислительно сложных приложениях остается C++.
Чем выше должность, тем шире кругозор
Павел: Ты упомянул свою должность — ведущий инженер. И вот я обратил внимание на такую странность. Если бы начинающего разработчика на C++ из твоей компании спросили, чем он занимается, он бы сказал, что крутит какой-то суперфреймворк на шаблонах, который на основе бустстейджа делает балансировку серверов, и сразу бы свалились технологии.
Когда тебя спрашивают, что делает твоя компания, начинается целая история про бизнес: где там деньги, почему это важно, и т.д. Это как-то коррелирует с твоей должностью? Именно такой взгляд на процессы, технологии, инструменты?
Михаил: Да, пожалуй. Но к тому же, если я начну сразу рассказывать про то, как я пересекаю деревья (правда, сам я этого не делаю), будет не всем понятно. Например, чуваки из Яндекса, Kaspersky Lab могут начинать с технологий, поскольку все знают их продукты. Мы же говорим про алайнеры, про которые знает небольшое количество людей. Поэтому нужно объяснить, что же это такое.
Касательно того, как это коррелирует с должностью. На моем грейде приходится как минимум понимать элементы нашего workflow текущих систем, которые работают вместе. Ведь если что-то меняется, то это может повлиять на производство, сайт докторов, интерфейс, с которым взаимодействуют техники, доктора и бизнес-аналитики. То есть да, корреляция есть. С ростом грейда нужно лучше видеть, что происходит в компании.
Павел: Думал ли ты, как внедрение новых технологий, допустим, касаемых C++, повлияло бы на workflow? Редко кто смотрит на новые фичи языка. И если нет, то расскажи о том, как вы в последнее время внедряли инструменты?
Михаил: Про C++ навскидку не вспомню. Если брать инструменты, то последнее, что мы прикручивали, — это система облачного логирования. У нас конкретно для этого используется Splunk. Изначально платформа была под десктоп, и миграция в cloud сейчас в самом разгаре. Поэтому мы прикручиваем, в частности, облачное логирование. Наш менеджер быстренько научился делать запросы и строить красивые дэшборды, выводить графики в реальном времени. Был очень доволен. Всем разослал и сказал смотрите, как у нас варьируется время работы такого-то сложного алгоритма, с чем это связано? Стали разбираться, поняли, что на тестовых агентах у нас почти нет многопоточности. Постоянно что-то внедряется.
С++, легаси, кроссплатформенность и все, все, все
Олег: Я правильно понимаю, что у вас есть рендеринг в браузере?
Михаил: Да, есть.
Олег: Браузерные технологии постоянно изменяются. Это как-то влияет? Например, новый JS, Shading Language, что-нибудь такое.
Михаил: Оно влияет, но здесь немного скучно. В плане рендеринга сцена у нас довольно простая. У нас нет каких-то невероятных спецэффектов.
Павел: Хорошо. А вот ты сказал, что начинали с десктопного приложения, где C++ был лучшим решением, которое совмещало в себе все плюсы. Когда бизнес начал разрастаться вместе с продуктом, вы начали осваивать другие платформы. Какой-то код поехал в браузер, какой-то на бэкенд, какой-то на мобильники. А «плюсовое» ядро сохранилось на всех платформах?
Михаил: Движение на другие платформы началось два года назад, и для наших масштабов это небольшое время. Поэтому у нас первое облачное решение представляло собой десктопный монолит, из которого выкинули, грубо говоря, GUI. Года полтора назад мы выделили условное ядро и обвязку вокруг него, поэтому смогли скомпилировать и запустить его уже под Linux. Это был большой прорыв. Linux нам был важен в первую очередь потому, что облачные Linux машины намного дешевле.
Сейчас мы хотим отделить вычислительное ядро на C++, где будут происходить все сложные вычисления, от бизнес-логики, которая описывает, что и в каком порядке делать, откуда кейс приехал, какой тип продукта, что доктор имеет право делать, а что нет, и вот это все.
Павел: У вас наверняка уже есть roadmap этого процесса, раз ты так про него хорошо рассказываешь.
Михаил: Мы много раз пытались создать roadmap. Мы понимаем, куда вроде бы можем двигаться с учетом 20 лет легаси (там с полтычка не доедешь, надо подумать).
Взаимодействие плюсовых проектов у нас сейчас сделано по-простому. Из них торчат именно интерфейсы на C++, поэтому собираются они только вместе, чтобы точно был один компилятор. Всего около 250 проектов, каждый собираются в свою динамическую библиотеку. И мы их комбинируем разными способами под конкретные задачи.
Над системой трудится около 10 команд. Каждая команда набирает свое подмножество этих проектов, обычно 50-70. Сейчас движемся в ту сторону, что на их основе будет создаваться некоторый сервис. У сервиса определим строгий API (на основе protobuf или чего-то еще), и сделаем стандартную схему взаимодействия между сервисами. Сложно назвать процесс разделением вычислений и логики, но это первые попытки компонентизации.
Моя команда и ещё несколько уже начали это делать. Сразу чувствуешь, насколько прикольнее, когда собираешь монолит не из 250 проектов, а всего лишь из 70. И больше нет ситуации, когда кто-то изменил другой модуль, который взаимодействует вроде бы совсем с не связанными вещами, а у тебя что-то сломалось. Это имеет прикольный психологический эффект. И пока мы пытаемся уйти от здорового десктопного монолита через выделение условно 10 небольших монолитиков в свои сервисы.
Павел: И вот в ходе этого процесса ты не рассматривал, могут ли модули, которые вот-вот нам обещают загрузить в каком-то виде, помочь ему на каком-нибудь из уровней?
Михаил: Конкретно этому процессу и процессу перемещения в Linux нам помог Conan. У нас была серьезная проблема с управлением third-party. О том, как мы использовали Conan, я рассказывал на C++ Russia 2019 в Москве.
«Плюсовые» модули помогли бы решить некоторые проблемы со временем компиляции, откуда, собственно, всё и начиналось, почему все так хотят модули. Переиспользовать плюсовые модули для взаимодействия с сервисом глупо, потому что они будут общаться на некотором language-agnostic уровне (protobuf), и это правильно. Может, нам бы удалось выполнить компонентизацию и не билдить каждый раз из исходников наши 250 проектов, а положить их в конановские пакеты. И если складывать, допустим, dll-ки, по определенным причинам неудобно, то собирать в модули — вариант.
Но не могу сказать, что мы ждем какую-то фичу, которая изменит наш подход к разработке.
Павел: Ты упомянул, что Conan помогает вам решать проблемы с управлением пакетами. На мой взгляд, года 3 назад в сообществе C++ об этом только говорили. Появлялись первые доклады, первые предпосылки. А сейчас ты говоришь, что это уже работает в продакшене.
Расскажи о своем опыте эволюции проекта. Был ли процесс перехода болезненным и стоил ли того?
Михаил: Определенно стоил того. Conan’ом мы довольны. Там есть некоторые огрехи, но ведь управление зависимостями в C++ — очень сложная задача. Поэтому очевидно, что для ее решения не будет простого инструмента.
С Conan и процессом на нем мы достигли баланса сложности задачи и решения. Мы изначально сказали: «Окей, мы хотим выделить такие-то множества компиляторов и конфигураций, потом по умолчанию билдить динамические библиотеки (а не статические), сделать определенный небольшой набор ограничений», и мы стали строить систему в рамках этого набора ограничений. У нас есть wiki-страница «как создать Conan рецепт для библиотеки», где учитывается вся специфика нашей системы. Страница довольно большая и не очень простая. Но, опять же, мы достигли баланса сложности, поэтому я доволен переходом.
Павел: А вот, кстати, на предстоящей С++ Russia 2019 Piter Денис Панин из NVIDIA расскажет про альтернативу в лице vcpkg. Было бы ли интересно тебе сходить на доклад и послушать, как делают в другом инструментарии?
Михаил: Да, было бы интересно. Я немного пользовался vcpkg, но, на мой взгляд, в vcpkg очень мало гибкости. И я не представляю, как мы могли бы построить систему с нашими требованиями на базе vcpkg. Но если мне нужно быстро взять и потестить какую-то библиотеку, то я не буду ее качать и читать Build Instructions, что там нужно указать, как прописать зависимости, вот весь этот треш. Я посмотрю, есть ли она в портах vcpkg. Если есть, то быстренько её ставлю, экспериментирую с ней. Если всё хорошо, то иду писать для нее конан рецепт.
Павел: Продолжим про внедрение новых инструментов и подходов. Сталкивался ли ты с тем, что инженеры прибегают с горящими глазами с конференции, где им рассказали про новую классную штуку, и они хотят вставить ее в проект? Как ты реагируешь обычно на такие вещи? Или сам так прибегаешь после каждой конференции?
Михаил: Есть как раз отличная история. Когда я только начал работать в компании, написали фичу, и нужно было сделать конфижку для нее. Причем у фичи может быть несколько разных версий, а значения конкретных свойств могут шариться между разными версиями. И я придумал крутую схему на базе YAML, где было наследование и переопределение свойств. Писал ее около недели, покрыл тестами. И в самом начале ко мне подходил менеджер и говорил: «Слушай, Михаил, может, не нужно сейчас тратить время и делать настолько гибкую схему?». Но он не смог меня переубедить. У меня слишком горели глаза.
Спустя пару лет смотрю на этот код и не понимаю, зачем нужно было так сложно делать. Такое бывает, но, к счастью, с тех пор я поумнел. К тому же, обычно разработчики — люди весьма рациональные, с ними можно поговорить.
Бывало, что кто-то втаскивает сомнительные third-party решения. Непонятно кем развиваются, последнее обновление было 5 лет назад, не проверено, работает ли под Linux, генерируют какие-нибудь отчеты в проприетарном формате, которые ни во что не сконвертируешь. И мы сидим и не понимаем, что дальше с этим делать. Большая часть таких third-party была добавлено много лет назад, но бывает, что и сейчас что-то похожее происходит.
Поэтому мы придумали достаточно простую вещь — third-party чек-лист. Если хочешь затащить third-party, просто пройдись по пунктам чек-листа: кроссплатформенность, уровень поддержки, лицензия, какие аналоги, уровень поддержки разработки (сколько мейнтейнеров поддерживают, какое коммьюнити). Все пункты очевидны, но их довольно много, и когда набираешь third-party, сходу все не вспомнишь. Ситуация стала получше, и мы следим за тем, что добавляется.
Классно еще то, что раньше было легко затащить third-party и собрать ее, допустим, только в релизе под «виндой» и 32 бита. Сейчас же в принципе нет такой возможности, поскольку ты обязан положить ее в Conan. И если ты затаскиваешь third-party, то придется убедиться или явно указать, что в какой-то конфигурации она не собирается. Благодаря этому левых third-party стало добавляться гораздо меньше.
Олег: А что делать с third-party, которые очень мало живут? Например, какой-нибудь left-pad из JavaScript. Он же проходит по твоему чек-листу. Его часто обновляют, мейнтейнят, делают пакеты.
Михаил: Такого нет. В C++ third-party — это обычно толстая штука. А сторонние решения, которые выполняют мелкие функции, не используются. Ведь в C++ не так просто добавить third-party. И это не JS, в котором на каждый чих есть свой модуль.
У нас затащили условно 80 third-party, половину из которых я никогда не видел. Или какая-нибудь адская геометрия, которую написали 15 лет назад в каком-то университете, и у нас лежит.
Олег: С Conan же просто добавить third-party.
Михаил: С Conan проще, но всё равно далеко от того же Python, где пишешь pip install и готово. C++ обладает очень сложной экосистемой: разные операционные системы, компиляторы, тулчейн, библиотеки, стандарты. Большинство библиотек имеет ещё ворох опций.
Нас любят спрашивать: «А чего вы пишите свои рецепты библиотек, а не берете их с Conan-center?». Я смотрел периодически рецепты оттуда, но они нам не подходят. Мы делаем лучше. Например, наши рецепты заботятся о дебажных символах, и добавляют в них привязку к исходникам. Так что когда отладчиком из Visual Studio попадаешь стороннюю библиотеку, у тебя автоматом подгружаются исходники.
Так что с Conan гораздо лучше, но еще далеко по удобству от других языков.
Олег: А в самом Conan есть недостатки, которые хотел бы поправить?
Михаил: Да, недостатки есть, но технические.
В Conan есть методы, которые условно отвечают за генерацию пакетов и за подключение сгенерированных пакетов к твоему решению. Идеологически это два разных этапа, и я могу менять один, не меняя другой. Я бы не хотел, когда меняю способ подключения пакетов, перегенерировать бинарные пакеты, ведь они будут точно такими же. В Conan это делать нельзя, поскольку рецепт — это одна сущность. Если ты изменил рецепт, то формально ты должен изменить версию и сгенерировать новые бинарники, что неудобно.
Особенности перехода на новые стандарты
Павел: Поговорим про новые стандарты. К тому же ваш продукт уже имеет некоторую историю.
Сейчас мы приходим на конференции, где каждые три года нам рассказывают про новые замечательные фичи. К примеру, на С++ Russia 2019 Piter будет три доклада про грядущие изменения в языке. Есть ли у тебя опыт миграции старой кодовой базы, которая соответствовала старым стандартам, на то, что предложили или будут предлагать?
Михаил: Да, был такой опыт, немного рассказывал об этом на C++ Russia 2019. У нас была миграция с Visual Studio 2013 на Visual Studio 2017 и gcc, то есть мы одновременно добавляли поддержку Linux и обновляли компиляторы от Microsoft.
Проблем в коде было гораздо меньше в сравнении с организационными, техническими, инфраструктурными проблемами, CI и остальным тулингом. И у нас проблемы в коде были связаны в первую очередь с UB, которое после обновления компилятора начало выстреливать. Хоть C++ гнобят за многолетнюю обратную совместимость, но она помогает. Сейчас мы всё компилируем под C++17.
Бывают не синхронизированы ворнинги, когда разработчики собирают под «виндой», пушат в CI и только после этого начинают собирать под Linux. Но существенных проблем не возникло.
В C++17 были убраны некоторые устаревшие вещи, но мы потратили всего несколько часов на их выпиливание. Например, библиотека log4cplus использовала std::auto_ptr в хедерах, но в новых версиях его уже заменили на std::unique_ptr, поэтому достаточно было просто обновить библиотеку.
Так что миграция на новый стандарт прошла относительно безболезненно. И с учетом объёма нашей кодовой базы, я удивлен, как мало проблем у нас возникло.
О коричневом и черном поясе по C++
Павел: Мы с тобой говорим уже о сложившихся процессах, где уже работают разработчики с опытом. Давай дадим пищу для размышлений начинающим разработчикам, которые только учатся. С какого стандарта C++ ты советовал бы начать?
Михаил: Надо брать сразу последний стандарт. Ты же не будешь учить STL на том же C++98, так как STL без лямбд не имеет никакого смысла. Если вы посмотрите на курсы «Основы разработки на С++: коричневый пояс» и «Основы разработки на С++: чёрный пояс» на Coursera, то там уже пишем на C++17. Например, используем structured bindings.
Павел: Хорошо, что ты упомянул эти курсы. Как я знаю, ты тоже участвовал в их разработке. Расскажи, как ты стал соавтором и что ты видишь интересного там для себя?
Михаил: Всем этим занимается Илья Шишков из Яндекса, и мы с ним давние знакомые. Однажды он спросил меня, не хочу ли заниматься созданием курса по C++. У него было много людей из Яндекса, которые хорошо разбираются в C++, но не хватало тех, кто просто и понятно обо всем расскажет. Мне же нравится объяснять, доносить мысли и упорядочивать материал, но в таком формате еще не работал. Я понимал, что это займет на порядок больше времени, чем, скажем, подготовка доклада на конференцию. И вопрос был в том, выделят ли мне рабочее время. Поэтому пошел к руководству с этой идеей, объяснил, что нам будет с этого промоушен, что могу налепить на ноутбук в кадре стикер Align Technology.
Павел: Ты сказал, что подготовить учебный материал на порядок сложнее, чем доклад. Почему?
Михаил: Во-первых, доклад — это диалог. Я предполагаю, что у меня будет аудитория. Если во время выступления я вижу непонимание в глазах аудитории, то останавливаюсь и подробнее объясняю. А когда ты в студии с прожекторами, и на тебя смотрит камера, то нужно очень точно подбирать слова, потому что никакой обратной связи нет. Во-вторых, материала больше, и его нужно разбивать на короткие, но законченные фрагменты. Нужно чётко продумывать структуру. В-третьих, на докладе я могу рассказать либо что-то совсем новое (наш опыт), либо что-то, с чем люди мало знакомы. Там ценность в информации. А тут я никакой новой информации не говорю. Всё это уже давно известно. Здесь вся ценность в понятности изложения. И приходится уделять этому особенно много внимания. Например, на коричневый пояс я сделал ряд слайдов, почесал репу, обсудил с ребятами, и решил всё переделал. Кстати, именно по этой же причине я считаю, что tutorial доклады должны быть высочайшего качества. Если уж ты решил объяснить что-то, что и так уже известно, это нужно сделать хорошо.
Трудно быть спикером
Павел: Кстати, о теме твоих докладов. Ты обычно затрагиваешь разные темы, связанные с практическими задачами. Как ты вообще придумываешь темы?
Михаил: Обычно беру те темы, в которых приходилось разбираться. Вспоминаю, с чем долбался за последний год и о чем будет интересно рассказать.
Павел: На мой взгляд, тебе всегда удается сделать свои доклады «прозрачными» для аудитории. Понятны проблема, инструмент и методы. Как тебе удается сохранять «прозрачность» и понятность, даже когда уходишь в сложные темы?
Михаил: Очень помогает базовая презентация о том, как делать презентации, которую раздают всем докладчикам. Также помогают прогоны. Только берите на прогон не своего знакомого эксперта, а какого-нибудь мидла. Так вы узнаете, как реагирует аудитория.
Еще мне помог опыт проведения семинаров по C++ в аспирантуре. Я готовил для студентов материалы, вычитывал стандарт. И по прошествии времени могу сказать, что семинары были отвратительными. Было непонятно, сложно, много концентрации на деталях. До сих пор стыдно перед теми студентами. В какой-то момент пришло понимание, что так делать нельзя.
Очень важно понимать, зачем ты делаешь доклад. Тогда мне хотелось разобраться во всяких фишках, и неважно, что студенты не поймут, зато мне интересно. Сейчас же я хочу, чтобы мой доклад поняли. Поэтому на каждом слайде и предложении задаю себе вопрос «а это понятно?». В этом помогает фидбек от аудитории, поэтому важна практика.
Павел. Ты постоянно участвуешь на C++ Russia и даже был самым первым спикером. Какая конференция тебе понравилась больше всего?
Михаил: По организации больше всего понравилась последняя. Но самая первая, очевидно, была самой камерной. На ней я, собственно, и познакомился с Ильей Шишковым. Но запомнилась больше всего та конференция, где я кидал шарики в аудиторию.
Павел: Мне кажется, тот доклад запомнился всем участникам. А если говорить о темах, то какие ты видишь тенденции? О чем говорили в 2015, будут говорить в 2019 и даже в 2020 году?
Михаил: Я прагматик, поэтому, когда иду на конференцию, выделяю то, что мне интересно. О каких-то трендах сказать не готов. Но меня удивляет, что на конференциях продолжают появляться доклады по основам, не приносящие ничего нового, но такие доклады реально интересные. Даже в тех докладах, что я делал, почти ничего нового не рассказывал. Только о вещах, которые на практике встраиваются для решения конкретной задачи.
Мне вспоминается доклад с CppCon 2018 про шаблонные функции. Вроде казалось бы, это просто шаблонные функции, но за час узнал много нового. Ведь C++ обширен. И под тем, чем ты пользуешься уже много лет, скрывается множество нюансов.
Мой следующий доклад тоже можно отнести к этой категории. Там будет немного про новомодные фишки, но большая часть — то, что существует много лет.
Павел: Про что будет твой доклад?
Михаил: Доклад будет про спецификаторы и квалификаторы const, volatile, static, constexpr, inline, extern и как они друг с другом взаимодействуют. Для глобальных сущностей, членов класса, локальных переменных и т.д.
Павел: Будут ли там совсем свежие consteval и constinit?
Михаил: Расскажу об этом под конец доклада. Мне это было очень интересно, поскольку особо этого не понимал, полез разбираться. Признаться, за первые 3-4 часа изучения возникло больше вопросов, чем ответов.
Олег: Кстати, а правда, что Visual Studio до конца не поддерживает constexpr?
Михаил: Visual Studio поддерживает их хорошо. По крайней мере, я пробовал основные функции. Правда, не тестировал constexpr-лямбды.
Олег: Просто видел кучу внутренних багов, о которых разработчики говорят: чтобы использовать эту фичу, нужно переписать полкомпилятора, поэтому обойдемся без нее.
Михаил: Как пользователь Visual Studio скажу, что стало намного лучше. Я хорошо помню, что было в 2010 году: завожу статическую переменную в лямбде, и компилятор крашится. Сейчас же поддержка Microsoft новых функций радует.
Павел: В тему твоего доклада. Для неизменяемых сущностей уже есть пять слов: const, constexpr, constinit, consteval и, неожиданно, final. Почему final не называется, скажем, constfinal?
Михаил: final, в отличие от других ключевых слов, связан с полиморфизмом. О нём я лишь упомяну. Хорошо, что у нас нет constfinal, было бы слишком.
Павел: Ты сказал, что любишь взять программу конференции, подчеркнуть в ней то, что тебе интересно, и пойти послушать. Удалось ли так сделать с текущей программой конференции?
Михаил: Нет, я это делаю всегда перед самой конференцией, ведь программа может измениться. Даже хотя бы два доклада, что раньше были в разное время, могут встать в параллель.
Павел: То есть пока ты знаешь только о своем докладе?
Михаил: Нет, JUG Ru Group мне спамит тем, кто будет выступать на конференции (улыбается).
Павел: Спасибо тебе большое за приятное интервью. Что бы ты хотел сказать потенциальным участникам конференции?
Михаил: Помните, что конференция — это в первую очередь нетворкинг и знакомства. Так что если вы находитесь в коридоре и ведете интересную беседу, но начинается доклад, ничего страшного, если его пропустите. Потом посмотрите в записи.
Павел: И последний вопрос. Как ты думаешь, на конференцию интереснее ездить участником или спикером?
Михаил: Спикером, конечно. Потому что во время обеда участники стоят вокруг столиков, а спикеры обедают сидя (смеется).
Михаил Матросов выступает в эту пятницу на C++ Russia 2019 Piter с докладом «Спецификаторы, квалификаторы и шаблоны». Осталось всего пара дней, приобрести билеты можно на официальном сайте конференции.
