Михаил Матросов (англ.
мматросов ) — ведущий инженер-разработчик московского научно-исследовательского офиса Align Technology. Его специализация весьма необычна – он разрабатывает специализированную CAD-систему для проектирования ортодонтических аппаратов.
Михаил участвует в C++ Russia с самой первой конференции.
В этом году он выступит с докладом на C++ Russia 2019 Piter. «Спецификаторы, квалификаторы и шаблоны» .
Также его можно узнать по курсам от Яндекса «Основы разработки на C++: коричневый пояс» И «Основы разработки на C++: черный пояс» на Coursera, соавтором в создании которого был Михаил.
Конференция уже не за горами, а пока ловите интервью с Михаилом, где мы обсуждали его работу в Align Technology, миграцию устаревшего кода, подготовку онлайн-курсов и отчетов, а также особенности C++.
Вопросы задавали Павел Филонов (программный комитет C++ Russia) и Олег Чирухин (журналист JUG Ru Group).
На стыке технологий и медицины
Павел: Расскажите, чем занимается ваша компания.Майкл: Align Technology — пионер и лидер рынка чистой ортодонтии.
Это вещь, которую сейчас делают во всем мире вместо брекетов.
Если раньше для выпрямления зубов использовали металлическую проволоку и люди бегали с ней, то теперь вместо нее надевают прозрачные пластиковые каппы, которые изготавливаются индивидуально для каждого пациента.
Недавно опробовала на себе продукцию нашей компании, было очень забавное ощущение! Павел: Итак, у вас есть такая собачья еда, верно? Майкл: Да, типа того.
На самом деле, если не знать, заметить, что человек носит элайнеры, очень сложно.
Возможно, поначалу по привычке появляются небольшие речевые дефекты, но даже их трудно заметить.
Павел: Причем здесь C++, о котором мы сегодня будем много говорить? Майкл: Отличный вопрос.
Когда компания только начинала свою деятельность, два веселых пакистанца взяли какой-то специальный пластик (не знаю, где они его нашли), который должен был быть нетоксичным и инертным по отношению к слюне и другим веществам во рту.
Затем взяли модель челюсти пациента, которую умели делать уже очень давно.
Например, чтобы сделать коронки, человеку давали кусать что-то вроде специального пластилина.
От зубов оставлен слепок, заполненный материалом.
Вот так была получена копия челюсти, натянута на нее пластик (как-то нагретая) и капа готова.
То есть весь этот рынок буквально 20 лет назад был полностью аналоговым.
Сейчас объем производства составляет около 300-400 тысяч элайнеров в день (оцените масштабы).
Это гигантские производственные мощности, поэтому они полностью автоматизированы.
Для создания элайнера мы печатаем слепки на специальном 3D-принтере.
По сути, это копия челюсти пациента во время лечения.
Моделируем, как будет выглядеть челюсть через неделю, две, месяц, год. Далее приступаем к процессу термоформования – берем пластиковую ленту, нагреваем ее и натягиваем на форму.
Отрезаем его и получаем пластиковый элайнер.
На данный момент слепки пациентов уже никто не делает, а использует трехмерные внутриротовые сканеры.
У нас в соседнем офисе этим занимаются ребята.
Это, наверное, самая «вау» часть нашего производства.
Там в режиме реального времени используется специальная насадка, которая направляет челюсть и выстраивает ее форму.
Информация загружается на серверы компании, обрабатывается и отправляется нашим специалистам (технарям).
Они могут редактировать скан и удалять шум.
Затем лечение планируется с использованием специализированной CAD-системы.
Это очень сложное дело, ведь никто не знает, что такое правильный прикус.
У каждого врача свой взгляд на этот вопрос.
Сейчас мы работаем над формализацией подходов к лечению, но это еще не запущено в производство.
Но вернемся к C++.
Например, есть такая задача.
Формы печатаются на специальном 3D-принтере с использованием технологии лазерной стереолитографии.
Имеется большая чан со специальной фотополимерной жидкостью.
На него светят лазером и он затвердевает. Сначала они освещают самую нижнюю часть печатной модели, затем чуть выше, еще выше и т. д. И так внутри жидкости снизу вверх сквозь слои появляется твердая модель.
С помощью этой технологии было бы непрактично печатать формы по одной.
Чан довольно большой и в него можно поместить около сотни формочек.
Но их нужно компактно расположить.
Форма формы похожа на подкову – то есть невыпуклая и достаточно сложная.
И они все разные.
Это создает интересную задачу по облицовке прямоугольника сложными формами.
Вот и все видео с указанной временной метки вы можете увидеть, как это выглядит. Это всего лишь один пример; есть много задач.
Павел: Ваши описания звучат как высокотехнологичные расчеты.
Такие языки, как Фортран, исторически хорошо зарекомендовали себя в них.
По крайней мере, отголоски этого все еще можно найти.
Почему С++? Майкл: Хорошо, что это не Фортран, это было бы достаточно мощно.
В самом начале разработки основным продуктом была эта весьма специализированная САПР — настольное приложение для Windows. Поэтому нужен был язык для эффективных вычислений и одновременно для разработки самого приложения.
На тот момент выбора особо не было — только C++.
Теперь у нас есть зоопарк языков: JavaScript и TypeScript для веба, Java для мобильных приложений, Go для серверов, Python для автоматизации и еще куча мелочей.
В принципе стандартный стек.
А в наукоемких и вычислительно сложных приложениях C++ остается.
Чем выше должность, тем шире кругозор
Павел: Вы упомянули свою должность – ведущий инженер.И вот я заметил эту странность.
Если бы начинающего C++-разработчика из вашей компании спросить, чем он занимается, он бы сказал, что работает над каким-то суперфреймворком на основе шаблонов, который балансирует серверы на основе booststage, и технологии тут же развалились бы.
Когда вас спрашивают, чем занимается ваша компания, начинается целая история о бизнесе: где деньги, почему это важно и т. д. Это как-то коррелирует с вашей должностью? Это именно такой взгляд на процессы, технологии, инструменты? Майкл: Я думаю да.
Но кроме того, если я сразу начну рассказывать о том, как я пересекаю деревья (хотя сама этого не делаю), то это будет понятно не всем.
Например, ребята из «Яндекса» и «Лаборатории Касперского» могут начать с технологий, поскольку их продукты все знают. Речь идет об элайнерах, о которых знает небольшое количество людей.
Поэтому необходимо объяснить, что это такое.
По поводу того, как это коррелирует с должностью.
В моем классе я должен, по крайней мере, понимать элементы нашего рабочего процесса в современных системах, которые работают вместе.
Ведь если что-то изменится, это может повлиять на производство, сайт врачей, интерфейс, с которым взаимодействуют технические специалисты, врачи и бизнес-аналитики.
Так что да, корреляция есть.
По мере повышения рейтинга вам необходимо лучше видеть, что происходит в компании.
Павел: Задумывались ли вы о том, как внедрение новых технологий, скажем, связанных с C++, повлияет на рабочий процесс? Редко кто смотрит на новые возможности языка.
А если нет, расскажите, как вы внедряли инструменты в последнее время? Майкл: Я ничего не помню о C++ из головы.
Если брать инструменты, то последнее, что мы прикрутили, — это облачная система логирования.
Для этого мы специально используем Splunk. Изначально платформа была для десктопа, сейчас полным ходом идет миграция в облако.
Вот почему мы вводим, в частности, облачное журналирование.
Наш менеджер быстро научился делать запросы, строить красивые дашборды и отображать графики в реальном времени.
Мне было очень приятно.
Я всем разослал и сказал, посмотрите, как у нас разнится время работы такого-то сложного алгоритма, с чем это связано? Начали разбираться и поняли, что многопоточности на тестовых агентах у нас почти нет. Постоянно что-то вводится.
C++, наследие, кроссплатформенность и все-все-все
Олег: Я правильно понимаю, что у вас рендеринг в браузере? Майкл: Да, у меня есть.Олег: Браузерные технологии постоянно меняются.
Имеет ли это какой-либо эффект? Например, новый JS, Язык штриховки , что-то вроде того.
Майкл: Это оказывает влияние, но здесь немного скучновато.
С точки зрения рендеринга наша сцена довольно проста.
У нас нет каких-то невероятных спецэффектов.
Павел: Отлично.
Но вы сказали, что начали с десктопного приложения, где C++ был лучшим решением, сочетающим в себе все преимущества.
Когда бизнес начал расти вместе с продуктом, вы начали исследовать другие платформы.
Часть кода перешла в браузер, часть — на серверную часть, часть — на мобильные телефоны.
Ядро «плюс» сохранилось на всех платформах? Майкл: Переход на другие платформы начался два года назад, и для наших масштабов это небольшой срок.
Поэтому наше первое облачное решение представляло собой десктоп-монолит, из которого, грубо говоря, был выкинут GUI. Около полутора лет назад мы изолировали условное ядро и привязку к нему, чтобы иметь возможность скомпилировать и запустить его под Linux. Это был большой прорыв.
Linux был важен для нас прежде всего потому, что облачные Linux-машины намного дешевле.
Теперь мы хотим отделить вычислительное ядро C++, где будут происходить все сложные вычисления, от бизнес-логики, которая описывает, что и в каком порядке делать, откуда поступил случай, какой тип продукта, что разрешено делать врачу.
а что нет, и всё.
Павел: У вас, наверное, уже есть дорожная карта этого процесса, раз вы так хорошо об этом рассказываете.
Майкл: Мы много раз пытались создать дорожную карту.
Мы понимаем, куда мы, судя по всему, движемся, учитывая 20 лет Легаси (с полкопейки туда не доберешься, надо думать).
Взаимодействие позитивных проектов теперь осуществляется простым способом.
Из них выделяются именно интерфейсы C++, поэтому они собираются только вместе, так что компилятор ровно один.
Всего около 250 проектов, каждый из которых собран в свою динамическую библиотеку.
И мы комбинируем их по-разному для конкретных задач.
Над системой работают около 10 команд. Каждая команда набирает свою часть этих проектов, обычно 50–70 человек.
Сейчас мы движемся в сторону того, что на их основе будет создан какой-то сервис.
Определим для сервиса строгий API (на базе protobuf или чего-то еще) и создадим стандартную схему взаимодействия между сервисами.
Процесс сложно назвать разделением вычислений и логики, но это первые попытки компонентизации.
Моя команда и еще несколько человек уже начали этим заниматься.
Сразу чувствуешь, насколько веселее, когда собираешь монолит не из 250 проектов, а всего лишь из 70. И больше не бывает ситуации, когда кто-то изменил другой модуль, взаимодействующий с, казалось бы, совершенно несвязанными вещами, и у тебя что-то сломалось.
Это имеет классный психологический эффект. А пока мы пытаемся уйти от здорового десктопного монолита, выделив в наши сервисы 10 маленьких монолитов.
Павел: И во время этого процесса задумывались ли вы, могут ли модули, которые они нам собираются загрузить в той или иной форме, помочь ему на каком-то уровне? Майкл: Помогли нам с этим конкретным процессом и процессом перехода на Linux. Конан .
У нас возникла серьезная проблема со сторонним управлением.
О том, как мы использовали Conan, я рассказывал на C++ Russia 2019 в Москве.
Модули «Плюс» помогли бы решить некоторые проблемы со временем компиляции, с чего, собственно, все и началось, почему всем так хочется модулей.
Повторное использование модулей plus для взаимодействия с сервисом глупо, поскольку они будут взаимодействовать на каком-то независимом от языка уровне (protobuf), и это правильно.
Может быть, мы могли бы сделать компонентизацию и не собирать каждый раз наши 250 проектов из исходников, а помещать их в пакеты Konan. И если собирать, скажем, dll по каким-то причинам неудобно, то собрать их в модули — вариант. Но я не могу сказать, что мы ждем какой-то особенности, которая изменит наш подход к разработке.
Павел: Вы упомянули, что Conan помогает вам решать проблемы управления пакетами.
По моему мнению, года 3 назад сообщество C++ только и говорило об этом.
Появились первые отчеты и первые предпосылки.
А теперь вы говорите, что оно уже работает в производстве.
Расскажите о своем опыте развития проекта.
Был ли процесс перехода болезненным и стоило ли оно того? Майкл: Определенно стоит того.
Мы счастливы с Конаном.
Здесь есть некоторые недостатки, но управление зависимостями в C++ — очень сложная задача.
Поэтому очевидно, что простого инструмента для ее решения не будет. С Конаном и процессом мы достигли баланса между сложностью проблемы и решением.
Мы изначально сказали: «Ладно, мы хотим выбрать такой-то набор компиляторов и конфигураций, затем собрать динамические библиотеки по умолчанию (а не статические), сделать некий небольшой набор ограничений» и начали строить систему внутри рамках этого набора ограничений.
У нас есть вики-страница «как создать рецепт Конана для библиотеки», где учтена вся специфика нашей системы.
Страница довольно большая и не очень простая.
Но опять же, мы добились баланса сложности, поэтому я доволен переходом.
Павел: И вот, кстати, на предстоящем C++ Russia 2019 Piter Денис Панин из NVIDIA скажет об альтернативе, представленной vcpkg .
Было бы вам интересно зайти на доклад и послушать, как это делают в других инструментах? Майкл: Да, это было бы интересно.
Я немного использовал vcpkg, но, по моему мнению, в vcpkg очень мало гибкости.
И я не представляю, как мы могли бы с нашими требованиями построить систему на базе vcpkg. Но если мне нужно быстро взять и протестировать какую-то библиотеку, то я не буду ее скачивать и читать Инструкцию по сборке, что там нужно указывать, как прописывать зависимости, весь этот треш.
Посмотрю, есть ли он в портах vcpkg. Если он есть, я быстро устанавливаю его и экспериментирую с ним.
Если все хорошо, то пойду писать для нее рецепт конана.
Павел: Давайте продолжим внедрять новые инструменты и подходы.
Вы когда-нибудь сталкивались с тем, что инженеры с горящими глазами прибегают с конференции, где им рассказали о новой крутой штуке, и они хотят вставить ее в проект? Как вы обычно реагируете на подобные вещи? Или вы так прибегаете после каждой конференции? Майкл: Есть просто отличная история.
Когда я только начал работать в компании, они написали фичу и нужно было создать для нее конфиг.
При этом фича может иметь несколько разных версий, а значения конкретных свойств могут меняться между разными версиями.
И я придумал классную схему на основе YAML, где было наследование и переопределение свойств.
Я писал его около недели и покрывал тестами.
И в самом начале ко мне подошел менеджер и сказал: «Слушай, Михаил, может, не надо сейчас терять время и создать такую гибкую схемуЭ» Но он не смог меня убедить.
Мои глаза были слишком горячими.
Спустя пару лет я смотрю на этот код и не понимаю, почему он должен был быть таким сложным.
Такое случается, но, к счастью, с тех пор я поумнел.
К тому же разработчики обычно очень рациональные люди, с ними можно поговорить.
Бывало, кто-то привнес сомнительные сторонние решения.
Непонятно кем они разрабатывают, последнее обновление было 5 лет назад, под линуксом не проверялось, какие-то отчеты они генерируют в проприетарном формате, который ни во что не конвертируется.
А мы сидим и не понимаем, что с этим делать дальше.
Большинство из этих сторонних были добавлены много лет назад, но случается, что нечто подобное происходит и сейчас.
Поэтому мы придумали достаточно простую вещь — сторонний чек-лист. Если вы хотите привлечь стороннюю, просто пройдите чек-лист: кроссплатформенность, уровень поддержки, лицензия, какие аналоги, уровень поддержки разработки (сколько мейнтейнеров поддерживают, какое сообщество).
Все пункты очевидны, но их довольно много, и набрав стороннее, сразу все не запомнишь.
Ситуация улучшилась, и мы следим за тем, что добавляется.
Что еще круто, так это то, что раньше можно было легко притащить стороннее и собрать его, например, только в релизе под Windows и 32 бита.
Сейчас такой возможности в принципе нет, так как вы обязаны поставить ее в Конан.
А если притащить стороннюю, то придется убедиться или явно указать, что она не встроена в какую-то конфигурацию.
Благодаря этому стало прибавляться гораздо меньше левых третьих партий.
Олег: Что делать с третьими лицами, которые живут очень мало? Например, некоторые левая панель из JavaScript. Он просматривает ваш контрольный список.
Он часто обновляется, поддерживается и упаковывается.
Майкл: Нет таких.
В C++ сторонние программы обычно представляют собой сложную задачу.
А сторонние решения, выполняющие второстепенные функции, не используются.
Ведь в C++ не так-то просто добавить стороннее.
И это не JS, у которого на каждый чих свой модуль.
От нас вытащили около 80 сторонних, половину из которых я никогда не видел.
Или какая-то адская геометрия, которая была написана 15 лет назад в каком-то университете и лежит у нас.
Олег: С Конаном легко добавить стороннее.
Майкл: С Конаном проще, но все же далеко не тот Python, где пишешь pip install и все готово.
У C++ очень сложная экосистема: разные операционные системы, компиляторы, наборы инструментов, библиотеки, стандарты.
Большинство библиотек имеют множество других опций.
Нас любят спрашивать: «Почему вы сами пишете рецепты в библиотеке, а не берете их из Конан-центраЭ» Я периодически просматривала рецепты оттуда, но они нам не подошли.
Мы делаем лучше.
Например, наши рецепты заботятся о символах отладки и добавляют к ним привязки к исходному коду.
Поэтому, когда вы используете отладчик из Visual Studio для доступа к сторонней библиотеке, ваши исходные коды загружаются автоматически.
Так что Конан гораздо лучше, но до других языков по удобству еще далеко.
Олег: Есть ли в самом Конане какие-то недостатки, которые вам хотелось бы улучшить? Майкл: Да, есть недостатки, но они технические.
У Конана есть методы, которые условно отвечают за генерацию пакетов и подключение сгенерированных пакетов к вашему решению.
Идеологически это два разных этапа, и я могу изменить один, не меняя другого.
Когда я меняю способ подключения пакетов, мне не хотелось бы заново создавать бинарные пакеты, потому что они будут точно такими же.
Вы не можете сделать это в Конане, потому что рецепт представляет собой единое целое.
Если изменить рецепт, то формально придется менять версию и генерировать новые бинарники, что неудобно.
Особенности перехода на новые стандарты
Павел: Давайте поговорим о новых стандартах.Кроме того, у вашего продукта уже есть некоторая история.
Теперь мы приезжаем на конференции, где каждые три года нам рассказывают о новых замечательных функциях.
Например, на C++ Russia 2019 Piter будет три доклада о предстоящих изменениях в языке.
Есть ли у вас опыт миграции старой кодовой базы, соответствующей старым стандартам, на ту, которая уже предлагалась или будет предлагаться? Майкл: Да, у меня был такой опыт, я немного рассказывал об этом на C++ Russia 2019. У нас была миграция с Visual Studio 2013 на Visual Studio 2017 и gcc, то есть мы одновременно добавили поддержку Linux и обновили компиляторы от Microsoft. Проблем в коде было гораздо меньше по сравнению с организационными, техническими, инфраструктурными проблемами, CI и прочим инструментарием.
А наши проблемы в коде были связаны в первую очередь с УБ, который начал глючить после обновления компилятора.
Хотя C++ критикуют за многолетнюю обратную совместимость, это помогает. Теперь компилируем всё под C++17. Иногда предупреждения не синхронизируются, когда разработчики компилируют под Windows, забрасывают в CI и только после этого начинают компилировать под Linux. Но никаких существенных проблем не возникло.
В C++17 удалены некоторые устаревшие вещи, но мы потратили на их вырезание всего несколько часов.
Например, библиотека log4cplus использовала в заголовках std::auto_ptr, но в новых версиях он уже заменен на std::unique_ptr, поэтому достаточно было просто обновить библиотеку.
Так что переход на новый стандарт прошел относительно безболезненно.
И, учитывая размер нашей кодовой базы, я удивлен, как мало проблем мы столкнулись.
О коричневых и черных поясах по C++
Павел: Мы уже говорим об отлаженных процессах, где уже работают опытные разработчики.Давайте дадим пищу для размышления начинающим разработчикам, которые только учатся.
С какого стандарта C++ вы бы порекомендовали начать? Майкл: Мы должны немедленно принять новейший стандарт. Вы не будете изучать STL на C++98, поскольку STL без лямбд не имеет смысла.
Если вы посмотрите курсы «Основы разработки на C++: коричневый пояс» И «Основы разработки на C++: черный пояс» на Coursera, то мы уже пишем на C++17. Например, мы используем структурированные привязки.
Павел: Хорошо, что вы упомянули эти курсы.
Насколько я знаю, вы тоже участвовали в их разработке.
Расскажи, как ты стал соавтором и что ты видишь в этом интересного для себя? Майкл: Всем этим занимается Илья Шишков из Яндекса, и мы давно знакомы.
Однажды он спросил меня, хочу ли я создать курс по C++.
У него было много людей из Яндекса, которые хорошо разбирались в C++, но не хватало людей, которые могли бы все просто и понятно объяснить.
Я люблю объяснять, доносить мысли и систематизировать материал, но в таком формате еще не работала.
Я понимал, что это займет на порядок больше времени, чем, скажем, подготовка доклада к конференции.
И вопрос был в том, дадут ли мне рабочее время.
Поэтому я пошел с этой идеей к руководству, объяснил, что от этого мы получим повышение, что я могу наклеить наклейку Align Technology на ноутбук в рамке.
Павел: Вы сказали, что подготовить учебный материал гораздо сложнее, чем подготовить доклад. Почему? Майкл: Во-первых, доклад – это диалог.
Я предполагаю, что у меня будет аудитория.
Если во время выступления я вижу непонимание в глазах аудитории, я останавливаюсь и объясняю более подробно.
А когда ты находишься в студии с прожекторами и на тебя смотрит камера, нужно очень точно подбирать слова, потому что обратной связи нет. Во-вторых, материала больше, и его нужно разбить на короткие, но полноценные фрагменты.
Нужно четко продумать структуру.
В-третьих, на докладе я могу рассказать либо что-то совершенно новое (наш опыт), либо что-то, с чем люди не очень знакомы.
Информация имеет ценность.
И здесь я не сообщаю вам никакой новой информации.
Все это известно давно.
Здесь вся ценность в ясности изложения.
И нам следует обратить на это особое внимание.
Например, на коричневый пояс я сделал серию слайдов, почесал затылок, обсудил с ребятами и решил все переделать.
Кстати, именно по этой же причине я считаю, что обучающие отчеты должны быть самого высокого качества.
Если вы решили объяснить что-то, что уже известно, нужно сделать это хорошо.
Трудно быть оратором
Павел: Кстати, о теме ваших докладов.Обычно вы затрагиваете различные темы, связанные с практическими проблемами.
Как ты вообще придумываешь темы? Майкл: Обычно я беру те темы, которые мне нужно было понять.
Я помню, с чем боролся последний год и о чем будет интересно поговорить.
Павел: На мой взгляд, вам всегда удается сделать свои доклады «прозрачными» для аудитории.
Проблема, инструмент и методы ясны.
Как вам удается сохранять прозрачность и ясность, даже углубляясь в сложные темы? Майкл: Базовая презентация о том, как проводить презентацию, которая предоставляется всем докладчикам, очень полезна.
Также помогает бег.
Просто возьмите на пробежку не знакомого эксперта, а какого-нибудь посредника.
Таким образом, вы будете знать, как отреагирует аудитория.
Мне также помог опыт проведения семинаров по C++ в аспирантуре.
Я подготовил материалы для студентов и прочитал стандарт. И по прошествии времени могу сказать, что семинары были отвратительными.
Было неясно, сложно, большая концентрация на деталях.
Мне до сих пор стыдно перед этими студентами.
В какой-то момент пришло понимание, что этого делать нельзя.
Очень важно понимать, почему вы даете отчет. Тогда мне хотелось понимать всякие хитрости, и не важно, что ученики не поймут, но мне было интересно.
Теперь я хочу, чтобы мой доклад был понят. Поэтому на каждом слайде и предложении я задаю себе вопрос «понятноЭ» В этом помогает обратная связь от аудитории, поэтому важна практика.
Павел.
Вы постоянно участвуете в C++ Russia и даже были самым первым докладчиком.
Какая конференция вам понравилась больше всего? Майкл: С точки зрения организации мне больше всего понравился последний.
Но самый первый, очевидно, был самым интимным.
Там-то я и познакомился с Ильей Шишковым.
Но больше всего мне запомнилась конференция, на которой я бросал мячи в аудиторию .
Павел: Мне кажется, тот доклад запомнился всем участникам.
И если говорить о темах, какие тенденции вы видите? О чем говорили в 2015 году, будут говорить в 2019 и даже в 2020 году? Майкл: Я прагматик, поэтому, когда иду на конференцию, выделяю то, что меня интересует. Я не готов говорить о каких-то тенденциях.
Но меня удивляет, что на конференциях продолжают появляться доклады по основам, которые не приносят ничего нового, а такие доклады действительно интересны.
Даже в докладах, которые я давал, я почти ничего нового не рассказал.
Только о вещах, которые внедряются на практике для решения конкретной задачи.
Я помню отчет с CppCon 2018 о функциях шаблона .
Казалось бы, это всего лишь шаблонные функции, но за час я узнал много нового.
В конце концов, C++ огромен.
А под тем, чем вы пользуетесь много лет, скрыто множество нюансов.
Мой следующий отчет также можно отнести к этой категории.
О новомодных функциях будет немного, но большинство из них — это вещи, существующие уже много лет. Павел: О чем будет ваш доклад? Майкл: Доклад будет посвящен спецификаторам и квалификаторам const, voluty, static, constexpr, inline, extern и тому, как они взаимодействуют друг с другом.
Для глобальных сущностей, членов классов, локальных переменных и т. д. Павел: Будут ли совсем свежие констеваль и констинит? Майкл: Об этом я расскажу в конце репортажа.
Мне это было очень интересно, потому что я этого не особо понимал, поэтому попробовал разобраться.
Признаюсь, за первые 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 «Спецификаторы, квалификаторы и шаблоны» .Теги: #Интервью #программирование #C++ #cpp #C++ РоссияОсталось всего пару дней, билеты можно приобрести на сайте официальный сайт конференции .
-
Темы Приключенческих Игр
19 Oct, 24 -
Неожиданная Встреча. Глава 7
19 Oct, 24 -
Цифровой Диаграммный Счетчик Образца 1890 Г.
19 Oct, 24 -
10 Скриптов Jquery Для Улучшения Интерфейса
19 Oct, 24 -
Августовский Шведский Стол
19 Oct, 24
