Хабрахабр

С++ на службе ортодонтии: интервью с Михаилом Матросовым, разработчиком CAD из Align Technology

Его специализация весьма необычна — он разрабатывает специализированную CAD-систему для дизайна ортодонтических приспособлений. Михаил Матросов (mmatrosov) — ведущий инженер по разработке в московском R&D-офисе Align Technology.

В этом году на С++ Russia 2019 Piter он выступит с докладом «Спецификаторы, квалификаторы и шаблоны». Михаил участвует в C++ Russia с самой первой конференции. Вы также можете его знать по курсам от Яндекса «Основы разработки на С++: коричневый пояс» и «Основы разработки на С++: чёрный пояс» на Coursera, в создании которых Михаил выступил соавтором.

Вопросы задавали Павел Филонов (программный комитет C++ Russia) и Олег Чирухин (журналист JUG Ru Group). Конференция уже на носу, а пока ловите интервью с Михаилом, где мы обсудили его работу в Align Technology, миграцию легаси-кода, подготовку онлайн-курсов и докладов, а также особенности C++.

На стыке технологий и медицины

Павел: Расскажи, чем твоя компания занимается.

Это такая штука, которая делается сейчас во всем мире вместо брекетов. Михаил: Align Technology — пионер и лидер на рынке чистой ортодонтии. Недавно опробовал на себе продукцию нашей компании, очень забавные ощущения! Если раньше для правки зубов ставилась металлическая проволока, и с ней бегали, то сейчас вместо этого надеваете прозрачные пластиковые капы (алайнеры), которые делаются индивидуально для каждого пациента.

Павел: То есть у тебя такой dogfooding, да, получается?

На самом деле, если не знаешь, то очень сложно заметить, что человек в алайнерах. Михаил: Да, вроде того. Разве что поначалу с непривычки появляются небольшие дефекты речи, но даже их сложно заметить.

Павел: А при чем здесь C++, о котором сегодня будем много говорить?

Когда компания только зарождалась, в ней два веселых пакистанца брали какой-то специальный пластик (не знаю, откуда они его нашли), который должен быть нетоксичен и инертен со слюной и прочими веществами во рту. Михаил: Отличный вопрос.

Например, чтобы сделать коронки, человеку давали прикусить что-то вроде специального пластилина. Затем брали модель челюсти пациента, которую умели делать уже очень давно. Так получали копию челюсти, и на нее натягивали пластик (как-то разогревали), и капа готова. Оставался слепок зубов, который заполняли материалом. То есть весь этот рынок буквально 20 лет назад был полностью аналоговым.

Это гигантские производства, поэтому они полностью автоматизированы. Сейчас объем производства в районе 300−400 тысяч алайнеров в день (прошу оценить масштабы).

Это, по сути, копия челюсти пациента в процессе лечения. Для создания алайнера мы печатаем на специальном 3D-принтере молд. Дальше мы запускаем процесс термоформинга — мы берем пластиковую ленту, разогреваем ее и натягиваем на молд. Мы моделируем, как будет выглядеть челюсть через неделю, две, месяц, год. Отрезаем и получаем пластиковый алайнер.

У нас этим занимаются ребята в соседнем офисе. На текущий момент слепки пациентов никто уже не делает, а используют трехмерные интраоральные сканеры. Там в реальном времени специальной насадкой ведут по челюсти и строят её форму. Наверное, это самая «вау-часть» нашего производства. Они могут редактировать скан, убрать шумы. Информация загружается на сервера компании, обрабатывается и отправляется нашим специалистам (техникам).

Это очень сложная штука, потому что никто не знает, что такое правильный прикус. Потом в специализированной CAD-системе планируется лечение. Мы сейчас ведём работу по формализации подходов к лечению, но в проде этого пока нет. У каждого врача есть свой взгляд на это дело.

Есть например такая задача. Но вернемся к C++. Есть большой чан со специальной фотополимерной жидкостью. Молды печатаются на специальном 3D принтере по технологии лазерной стереолитографии. Сначала светят на самую нижнюю часть печатаемой модели, потом чуть выше, ещё выше и т.д. На неё светят лазером и она затвердевает. И вот так внутри жидкости снизу вверх по слоям появляется твёрдая модель.

Чан довольно большой и в него можно засунуть около сотни молдов. Печатать по такой технологии молды по одному было бы непрактично. Форма у молда похожа на подкову — то есть невыпуклая и довольно сложная. Но их надо компактно расположить. Получается интересная задача замощения прямоугольника сложными фигурами. И все они отличаются.

Вот на этом видео с указанной временной отметки видно, как это выглядит.

Это только один пример, задач очень много.

В них исторически хорошо зарекомендовали себя такие языки, как Fortran. Павел: Твои описания похожи на наукоемкие вычисления. Почему именно C++? По крайней мере, можно до сих пор встретить отголоски.

В самом начале разработки главным продуктом была эта самая специализированная CAD-система — десктопное приложение под Windows. Михаил: Хорошо, что не Fortran, было бы совсем мощно. В то время выбора особо не было — только C++. Поэтому был нужен язык для эффективных вычислений и одновременно для разработки самого приложения.

В принципе, стандартный стек. Сейчас у нас зоопарк языков: JavaScript и TypeScript для веба, Java для мобильных приложений, Go для серверов, Python для автоматизации, ну и куча всего по мелочи. А в наукоемких и вычислительно сложных приложениях остается C++.

Чем выше должность, тем шире кругозор

И вот я обратил внимание на такую странность. Павел: Ты упомянул свою должность — ведущий инженер. Если бы начинающего разработчика на C++ из твоей компании спросили, чем он занимается, он бы сказал, что крутит какой-то суперфреймворк на шаблонах, который на основе бустстейджа делает балансировку серверов, и сразу бы свалились технологии.

Это как-то коррелирует с твоей должностью? Когда тебя спрашивают, что делает твоя компания, начинается целая история про бизнес: где там деньги, почему это важно, и т.д. Именно такой взгляд на процессы, технологии, инструменты?

Но к тому же, если я начну сразу рассказывать про то, как я пересекаю деревья (правда, сам я этого не делаю), будет не всем понятно. Михаил: Да, пожалуй. Мы же говорим про алайнеры, про которые знает небольшое количество людей. Например, чуваки из Яндекса, Kaspersky Lab могут начинать с технологий, поскольку все знают их продукты. Поэтому нужно объяснить, что же это такое.

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

Редко кто смотрит на новые фичи языка. Павел: Думал ли ты, как внедрение новых технологий, допустим, касаемых C++, повлияло бы на workflow? И если нет, то расскажи о том, как вы в последнее время внедряли инструменты?

Если брать инструменты, то последнее, что мы прикручивали, — это система облачного логирования. Михаил: Про C++ навскидку не вспомню. Изначально платформа была под десктоп, и миграция в cloud сейчас в самом разгаре. У нас конкретно для этого используется Splunk. Наш менеджер быстренько научился делать запросы и строить красивые дэшборды, выводить графики в реальном времени. Поэтому мы прикручиваем, в частности, облачное логирование. Всем разослал и сказал смотрите, как у нас варьируется время работы такого-то сложного алгоритма, с чем это связано? Был очень доволен. Постоянно что-то внедряется. Стали разбираться, поняли, что на тестовых агентах у нас почти нет многопоточности.

С++, легаси, кроссплатформенность и все, все, все

Олег: Я правильно понимаю, что у вас есть рендеринг в браузере?

Михаил: Да, есть.

Это как-то влияет? Олег: Браузерные технологии постоянно изменяются. Например, новый JS, Shading Language, что-нибудь такое.

В плане рендеринга сцена у нас довольно простая. Михаил: Оно влияет, но здесь немного скучно. У нас нет каких-то невероятных спецэффектов.

А вот ты сказал, что начинали с десктопного приложения, где C++ был лучшим решением, которое совмещало в себе все плюсы. Павел: Хорошо. Какой-то код поехал в браузер, какой-то на бэкенд, какой-то на мобильники. Когда бизнес начал разрастаться вместе с продуктом, вы начали осваивать другие платформы. А «плюсовое» ядро сохранилось на всех платформах?

Поэтому у нас первое облачное решение представляло собой десктопный монолит, из которого выкинули, грубо говоря, GUI. Михаил: Движение на другие платформы началось два года назад, и для наших масштабов это небольшое время. Это был большой прорыв. Года полтора назад мы выделили условное ядро и обвязку вокруг него, поэтому смогли скомпилировать и запустить его уже под Linux. Linux нам был важен в первую очередь потому, что облачные Linux машины намного дешевле.

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

Павел: У вас наверняка уже есть roadmap этого процесса, раз ты так про него хорошо рассказываешь.

Мы понимаем, куда вроде бы можем двигаться с учетом 20 лет легаси (там с полтычка не доедешь, надо подумать). Михаил: Мы много раз пытались создать roadmap.

Из них торчат именно интерфейсы на C++, поэтому собираются они только вместе, чтобы точно был один компилятор. Взаимодействие плюсовых проектов у нас сейчас сделано по-простому. И мы их комбинируем разными способами под конкретные задачи. Всего около 250 проектов, каждый собираются в свою динамическую библиотеку.

Каждая команда набирает свое подмножество этих проектов, обычно 50-70. Над системой трудится около 10 команд. У сервиса определим строгий API (на основе protobuf или чего-то еще), и сделаем стандартную схему взаимодействия между сервисами. Сейчас движемся в ту сторону, что на их основе будет создаваться некоторый сервис. Сложно назвать процесс разделением вычислений и логики, но это первые попытки компонентизации.

Сразу чувствуешь, насколько прикольнее, когда собираешь монолит не из 250 проектов, а всего лишь из 70. Моя команда и ещё несколько уже начали это делать. Это имеет прикольный психологический эффект. И больше нет ситуации, когда кто-то изменил другой модуль, который взаимодействует вроде бы совсем с не связанными вещами, а у тебя что-то сломалось. И пока мы пытаемся уйти от здорового десктопного монолита через выделение условно 10 небольших монолитиков в свои сервисы.

Павел: И вот в ходе этого процесса ты не рассматривал, могут ли модули, которые вот-вот нам обещают загрузить в каком-то виде, помочь ему на каком-нибудь из уровней?

У нас была серьезная проблема с управлением third-party. Михаил: Конкретно этому процессу и процессу перемещения в Linux нам помог Conan. О том, как мы использовали Conan, я рассказывал на C++ Russia 2019 в Москве.

Переиспользовать плюсовые модули для взаимодействия с сервисом глупо, потому что они будут общаться на некотором language-agnostic уровне (protobuf), и это правильно. «Плюсовые» модули помогли бы решить некоторые проблемы со временем компиляции, откуда, собственно, всё и начиналось, почему все так хотят модули. И если складывать, допустим, dll-ки, по определенным причинам неудобно, то собирать в модули — вариант. Может, нам бы удалось выполнить компонентизацию и не билдить каждый раз из исходников наши 250 проектов, а положить их в конановские пакеты.

Но не могу сказать, что мы ждем какую-то фичу, которая изменит наш подход к разработке.

На мой взгляд, года 3 назад в сообществе C++ об этом только говорили. Павел: Ты упомянул, что Conan помогает вам решать проблемы с управлением пакетами. А сейчас ты говоришь, что это уже работает в продакшене. Появлялись первые доклады, первые предпосылки.

Был ли процесс перехода болезненным и стоил ли того? Расскажи о своем опыте эволюции проекта.

Conan’ом мы довольны. Михаил: Определенно стоил того. Поэтому очевидно, что для ее решения не будет простого инструмента. Там есть некоторые огрехи, но ведь управление зависимостями в C++ — очень сложная задача.

Мы изначально сказали: «Окей, мы хотим выделить такие-то множества компиляторов и конфигураций, потом по умолчанию билдить динамические библиотеки (а не статические), сделать определенный небольшой набор ограничений», и мы стали строить систему в рамках этого набора ограничений. С Conan и процессом на нем мы достигли баланса сложности задачи и решения. Страница довольно большая и не очень простая. У нас есть wiki-страница «как создать Conan рецепт для библиотеки», где учитывается вся специфика нашей системы. Но, опять же, мы достигли баланса сложности, поэтому я доволен переходом.

Было бы ли интересно тебе сходить на доклад и послушать, как делают в другом инструментарии? Павел: А вот, кстати, на предстоящей С++ Russia 2019 Piter Денис Панин из NVIDIA расскажет про альтернативу в лице vcpkg.

Я немного пользовался vcpkg, но, на мой взгляд, в vcpkg очень мало гибкости. Михаил: Да, было бы интересно. Но если мне нужно быстро взять и потестить какую-то библиотеку, то я не буду ее качать и читать Build Instructions, что там нужно указать, как прописать зависимости, вот весь этот треш. И я не представляю, как мы могли бы построить систему с нашими требованиями на базе vcpkg. Если есть, то быстренько её ставлю, экспериментирую с ней. Я посмотрю, есть ли она в портах vcpkg. Если всё хорошо, то иду писать для нее конан рецепт.

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

Когда я только начал работать в компании, написали фичу, и нужно было сделать конфижку для нее. Михаил: Есть как раз отличная история. И я придумал крутую схему на базе YAML, где было наследование и переопределение свойств. Причем у фичи может быть несколько разных версий, а значения конкретных свойств могут шариться между разными версиями. И в самом начале ко мне подходил менеджер и говорил: «Слушай, Михаил, может, не нужно сейчас тратить время и делать настолько гибкую схему?». Писал ее около недели, покрыл тестами. У меня слишком горели глаза. Но он не смог меня переубедить.

Такое бывает, но, к счастью, с тех пор я поумнел. Спустя пару лет смотрю на этот код и не понимаю, зачем нужно было так сложно делать. К тому же, обычно разработчики — люди весьма рациональные, с ними можно поговорить.

Непонятно кем развиваются, последнее обновление было 5 лет назад, не проверено, работает ли под Linux, генерируют какие-нибудь отчеты в проприетарном формате, которые ни во что не сконвертируешь. Бывало, что кто-то втаскивает сомнительные third-party решения. Большая часть таких third-party была добавлено много лет назад, но бывает, что и сейчас что-то похожее происходит. И мы сидим и не понимаем, что дальше с этим делать.

Если хочешь затащить third-party, просто пройдись по пунктам чек-листа: кроссплатформенность, уровень поддержки, лицензия, какие аналоги, уровень поддержки разработки (сколько мейнтейнеров поддерживают, какое коммьюнити). Поэтому мы придумали достаточно простую вещь — third-party чек-лист. Ситуация стала получше, и мы следим за тем, что добавляется. Все пункты очевидны, но их довольно много, и когда набираешь third-party, сходу все не вспомнишь.

Сейчас же в принципе нет такой возможности, поскольку ты обязан положить ее в Conan. Классно еще то, что раньше было легко затащить third-party и собрать ее, допустим, только в релизе под «виндой» и 32 бита. Благодаря этому левых third-party стало добавляться гораздо меньше. И если ты затаскиваешь third-party, то придется убедиться или явно указать, что в какой-то конфигурации она не собирается.

Например, какой-нибудь left-pad из JavaScript. Олег: А что делать с third-party, которые очень мало живут? Его часто обновляют, мейнтейнят, делают пакеты. Он же проходит по твоему чек-листу.

В C++ third-party — это обычно толстая штука. Михаил: Такого нет. Ведь в C++ не так просто добавить third-party. А сторонние решения, которые выполняют мелкие функции, не используются. И это не JS, в котором на каждый чих есть свой модуль.

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

Олег: С Conan же просто добавить third-party.

C++ обладает очень сложной экосистемой: разные операционные системы, компиляторы, тулчейн, библиотеки, стандарты. Михаил: С Conan проще, но всё равно далеко от того же Python, где пишешь pip install и готово. Большинство библиотек имеет ещё ворох опций.

Я смотрел периодически рецепты оттуда, но они нам не подходят. Нас любят спрашивать: «А чего вы пишите свои рецепты библиотек, а не берете их с Conan-center?». Например, наши рецепты заботятся о дебажных символах, и добавляют в них привязку к исходникам. Мы делаем лучше. Так что когда отладчиком из Visual Studio попадаешь стороннюю библиотеку, у тебя автоматом подгружаются исходники.

Так что с Conan гораздо лучше, но еще далеко по удобству от других языков.

Олег: А в самом Conan есть недостатки, которые хотел бы поправить?

Михаил: Да, недостатки есть, но технические.

Идеологически это два разных этапа, и я могу менять один, не меняя другой. В Conan есть методы, которые условно отвечают за генерацию пакетов и за подключение сгенерированных пакетов к твоему решению. В Conan это делать нельзя, поскольку рецепт — это одна сущность. Я бы не хотел, когда меняю способ подключения пакетов, перегенерировать бинарные пакеты, ведь они будут точно такими же. Если ты изменил рецепт, то формально ты должен изменить версию и сгенерировать новые бинарники, что неудобно.

Особенности перехода на новые стандарты

К тому же ваш продукт уже имеет некоторую историю. Павел: Поговорим про новые стандарты.

К примеру, на С++ Russia 2019 Piter будет три доклада про грядущие изменения в языке. Сейчас мы приходим на конференции, где каждые три года нам рассказывают про новые замечательные фичи. Есть ли у тебя опыт миграции старой кодовой базы, которая соответствовала старым стандартам, на то, что предложили или будут предлагать?

У нас была миграция с Visual Studio 2013 на Visual Studio 2017 и gcc, то есть мы одновременно добавляли поддержку Linux и обновляли компиляторы от Microsoft. Михаил: Да, был такой опыт, немного рассказывал об этом на C++ Russia 2019.

И у нас проблемы в коде были связаны в первую очередь с UB, которое после обновления компилятора начало выстреливать. Проблем в коде было гораздо меньше в сравнении с организационными, техническими, инфраструктурными проблемами, CI и остальным тулингом. Сейчас мы всё компилируем под C++17. Хоть C++ гнобят за многолетнюю обратную совместимость, но она помогает.

Но существенных проблем не возникло. Бывают не синхронизированы ворнинги, когда разработчики собирают под «виндой», пушат в CI и только после этого начинают собирать под Linux.

Например, библиотека log4cplus использовала std::auto_ptr в хедерах, но в новых версиях его уже заменили на std::unique_ptr, поэтому достаточно было просто обновить библиотеку. В C++17 были убраны некоторые устаревшие вещи, но мы потратили всего несколько часов на их выпиливание.

И с учетом объёма нашей кодовой базы, я удивлен, как мало проблем у нас возникло. Так что миграция на новый стандарт прошла относительно безболезненно.

О коричневом и черном поясе по C++

Давай дадим пищу для размышлений начинающим разработчикам, которые только учатся. Павел: Мы с тобой говорим уже о сложившихся процессах, где уже работают разработчики с опытом. С какого стандарта C++ ты советовал бы начать?

Ты же не будешь учить STL на том же C++98, так как STL без лямбд не имеет никакого смысла. Михаил: Надо брать сразу последний стандарт. Например, используем structured bindings. Если вы посмотрите на курсы «Основы разработки на С++: коричневый пояс» и «Основы разработки на С++: чёрный пояс» на Coursera, то там уже пишем на C++17.

Как я знаю, ты тоже участвовал в их разработке. Павел: Хорошо, что ты упомянул эти курсы. Расскажи, как ты стал соавтором и что ты видишь интересного там для себя?

Однажды он спросил меня, не хочу ли заниматься созданием курса по 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-лямбды.

Олег: Просто видел кучу внутренних багов, о которых разработчики говорят: чтобы использовать эту фичу, нужно переписать полкомпилятора, поэтому обойдемся без нее.

Я хорошо помню, что было в 2010 году: завожу статическую переменную в лямбде, и компилятор крашится. Михаил: Как пользователь Visual Studio скажу, что стало намного лучше. Сейчас же поддержка Microsoft новых функций радует.

Для неизменяемых сущностей уже есть пять слов: const, constexpr, constinit, consteval и, неожиданно, final. Павел: В тему твоего доклада. Почему final не называется, скажем, constfinal?

О нём я лишь упомяну. Михаил: final, в отличие от других ключевых слов, связан с полиморфизмом. Хорошо, что у нас нет constfinal, было бы слишком.

Удалось ли так сделать с текущей программой конференции? Павел: Ты сказал, что любишь взять программу конференции, подчеркнуть в ней то, что тебе интересно, и пойти послушать.

Даже хотя бы два доклада, что раньше были в разное время, могут встать в параллель. Михаил: Нет, я это делаю всегда перед самой конференцией, ведь программа может измениться.

Павел: То есть пока ты знаешь только о своем докладе?

Михаил: Нет, JUG Ru Group мне спамит тем, кто будет выступать на конференции (улыбается).

Что бы ты хотел сказать потенциальным участникам конференции? Павел: Спасибо тебе большое за приятное интервью.

Так что если вы находитесь в коридоре и ведете интересную беседу, но начинается доклад, ничего страшного, если его пропустите. Михаил: Помните, что конференция — это в первую очередь нетворкинг и знакомства. Потом посмотрите в записи.

Как ты думаешь, на конференцию интереснее ездить участником или спикером? Павел: И последний вопрос.

Потому что во время обеда участники стоят вокруг столиков, а спикеры обедают сидя (смеется). Михаил: Спикером, конечно.

Осталось всего пара дней, приобрести билеты можно на официальном сайте конференции. Михаил Матросов выступает в эту пятницу на C++ Russia 2019 Piter с докладом «Спецификаторы, квалификаторы и шаблоны».

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть