Mikhail Matrosov（ mmatrosov ）是Align Technology莫斯科研发办公室的首席开发工程师。 他的专业非常不同寻常-他正在开发用于正畸设备设计的专用CAD系统。
自从第一次会议以来，Mikhail就一直参加C ++ Russia。 今年，在C ++ Russia 2019 Piter上，他将发表有关“限定词，限定词和模板”的演讲。 您也可以在Coursera的Yandex的“ C ++开发基础：布朗带”和“ C ++开发基础 ：黑带”的课程中认识他，这是迈克尔与他人合着的。
会议已经临近，但现在，我们接受了Mikhail的采访，我们在会议上讨论了他在Align Technology的工作，遗留代码的移植，在线课程和报告的准备以及C ++的功能。 C ++俄罗斯程序委员会的Pavel Filonov和JUG Ru组的新闻工作者Oleg Chirukhin提出了问题。
在技术与医学的交汇处
帕维尔：告诉我您的公司在做什么。
Michael： Align Technology是清洁正畸领域的先驱和市场领导者。 这种事情现在正在全世界范围内进行，而不是大括号中。 如果早些时候，放置了一根金属线来矫正牙齿，然后就随它一起走了，现在，您不用戴透明的塑料护齿器（衬套）了，这是针对每个患者单独制作的。 最近，我对自己测试了我们公司的产品，感觉非常有趣！
帕维尔：所以你有这样的狗食，事实证明吗？
迈克尔：是的。 实际上，如果您不知道，很难注意到该人在衬里中。 除非一开始是出于习惯，否则会出现小的语音缺陷，但是即使它们也很难被发现。
Pavel： C ++与什么有关，我们今天将讨论很多内容？
迈克尔：好问题。 该公司刚起步时，两个开朗的巴基斯坦人就用了一种特殊的塑料（我不知道他们从哪里找到的），这种塑料应该是无毒的，并且对唾液和其他物质呈惰性。
然后，他们制作了患者下颌的模型，很长时间以来就知道该怎么做。 例如，要制作冠冕，需要给人一口类似特殊橡皮泥的东西。 牙齿上塞满了材料。 因此，他们得到了下颌的副本，然后在其上拉了塑料（以某种方式对其进行了预热），然后牙套已准备就绪。 也就是说，整个市场在20年前实际上是完全模拟的。
现在每天的班轮生产量在300-400,000班轮之间（请评估规模）。 这些都是巨大的制造商，因此它们是完全自动化的。
为了创建衬纸，我们在特殊的3D打印机模具上进行打印。 实际上，这是治疗过程中患者下颌的副本。 我们模拟了一周，两个月，一年中下颌的外观。 然后，我们开始热成型过程-取一个塑料带，加热并将其拉到模具上。 切断并获得塑料衬里。
目前，尚无人在铸造病人，他们使用三维口腔内扫描仪。 我们在附近的办公室里做这些事。 这可能是我们产品中最“令人赞叹的部分”。 在那里，一个实时的特殊喷嘴沿钳口延伸并形成其形状。 信息被上传到公司的服务器，进行处理并发送给我们的专家（技术人员）。 他们可以编辑扫描，消除噪音。
然后在专门的CAD系统中计划治疗。 这是一件非常复杂的事情，因为没人知道正确的咬法是什么。 每一位医生对此都有自己的看法。 我们目前正在努力使治疗方法正规化，但这还没有出现。
但是回到C ++。 例如，存在这样的问题。 使用激光立体光刻技术在特殊的3D打印机上打印模具。 有一个装有特殊光敏聚合物液体的大桶。 他们用激光照在上面，然后变硬。 首先，它们在打印模型的最底部发光，然后更高，甚至更高。 因此，在流体内部，实体模型从下到上分层显示。
一张一张地印刷模具是不切实际的。 缸很大，可以放入一百个模具。 但是它们必须紧凑地排列。 模具的形状类似于马蹄形-即非凸且相当复杂。 他们都是不同的。 事实证明，这是一个有趣的任务，即用复杂的图形拼接一个矩形。
在此视频中，从指定的时间戳记中可以看到它的外观。
这只是一个例子，有很多任务。
帕维尔：您的描述就像高科技的计算。 像Fortran这样的语言在历史上一直表现出色。 至少您仍然可以看到回声。 为什么要使用C ++？
迈克尔：嗯，不是Fortran，它会非常强大。 在开发之初，主要产品就是这个非常专业的CAD系统-Windows的桌面应用程序。 因此，需要一种语言来进行有效的计算并同时开发应用程序本身。 当时没有太多选择，只有C ++。
现在，我们有了许多语言：用于网络的JavaScript和TypeScript，用于移动应用程序的Java，用于服务器的Go，用于自动化的Python，还有很多小事情。 基本上是标准堆栈。 在科学密集型和计算复杂的应用程序中，C ++仍然存在。
位置越高，视野越广。
帕维尔：您提到您担任首席工程师的职位。 因此，我注意到了一个奇怪的地方。 如果问到贵公司的C ++新手开发人员在做什么，他会说他正在旋转某种基于模板的超级框架，该模板基于booststage进行服务器平衡，技术将立即失效。
当被问到您的公司在做什么时，有关该业务的整个故事就开始了：钱在哪里，为什么重要？ 这是否与您的职位相关？ 对流程，技术，工具的看法是什么？
迈克尔：是的，也许。 但是除此之外，如果我立即开始讲述我如何越树（尽管我自己不做），那么每个人都不清楚。 例如，卡巴斯基实验室Yandex的帅哥可以从技术入手，因为每个人都知道他们的产品。 我们谈论的是班轮，少数人知道。 因此，有必要解释它是什么。
关于这与帖子之间的关系。 在我的成绩上，我至少必须了解当前可以协同工作的系统的工作流程要素。 毕竟，如果发生某些变化，那么这可能会影响生产，医生的位置以及与技术人员，医生和业务分析师互动的界面。 也就是说，是的，存在相关性。 随着等级的增长，您需要更好地了解公司中正在发生的事情。
帕维尔：您是否认为新技术（例如与C ++相关的技术）的引入将如何影响工作流程？ 很少有人关注该语言的新功能。 如果没有，请告诉我们您最近如何实施工具？
迈克尔：我不记得有关C ++的知识。 如果我们使用这些工具，那么最后要搞砸的就是基于云的日志记录系统。 我们专门为此使用Splunk。 最初，该平台位于台式机下，并且向云的迁移现已全面展开。 因此，我们尤其要紧固基于云的日志记录。 我们的经理很快学会了发出请求并建立漂亮的仪表板，显示实时图表。 我很高兴。 我发给所有人说，看看我们如何改变这种复杂算法的运行时间，这是什么原因？ 他们开始了解，我们意识到测试代理几乎没有多线程。 不断引入一些东西。
C ++，旧版，跨平台等等
奥列格（Oleg）：我是否正确理解您已在浏览器中进行渲染？
迈克尔：是的，有。
奥列格（Oleg）：浏览器技术在不断变化。 它会以某种方式影响吗？ 例如，新的JS， 着色语言 ，诸如此类。
迈克尔：影响，但是这里有点无聊。 在渲染方面，场景非常简单。 我们没有任何令人难以置信的特殊效果。
帕维尔：好。 但是您说过，您是从桌面应用程序开始的，其中C ++是结合了所有优点的最佳解决方案。 当业务随着产品发展而壮大时，您便开始开发其他平台。 一些代码进入浏览器，一些代码进入后端，一些代码进入手机。 “正”核心是否仍然存在于所有平台上？
迈克尔：两年前开始向其他平台迁移，对于我们来说，这是一个短暂的时期。 因此，我们的第一个云解决方案是桌面整体，从大致上讲，从中抛出了GUI。 大约一年半以前，我们隔离了条件内核及其周围的绑定，因此我们已经能够在Linux下编译并运行它。 这是一个重大突破。 Linux对我们很重要，主要是因为云Linux机器便宜得多。
现在我们想将C ++的计算核心与所有执行复杂计算的地方分开，从描述要做什么，按什么顺序，案例来自何处，什么类型的产品，医生有权做什么以及什么不应该做什么的业务逻辑中分离出来，以及仅此而已。
帕维尔：您可能已经有了这个过程的路线图，因为您谈论得很好。
迈克尔：我们曾多次尝试制定路线图。 考虑到Legacy的20年历史，我们了解了我们似乎可以移动的地方（半美元买不到，您需要考虑一下）。
积极项目的互动现在可以通过简单的方式完成。 其中，突出显示的是C ++接口，因此它们只有在一起才能确保有一个编译器。 总共约有250个项目，每个项目都进入其自己的动态库。 并且我们以不同的方式将它们组合在一起以完成特定任务。
该系统上大约有10个团队。 每个团队都会招募这些项目的一部分，通常为50-70。 现在，我们正在朝着将在其基础上创建一些服务的方向发展。 我们为服务定义了严格的API（基于protobuf或其他），并制定了服务之间交互的标准方案。 很难将流程称为计算和逻辑的分离，但这是组件化的首次尝试。
我的团队和其他几个团队已经开始这样做。 当您从250个项目中，而不是从70个项目中收集巨石时，您会立即感到很有趣。再也不会出现这样的情况：有人更改了另一个模块，该模块与看似完全不相关的事物进行交互，而某些事物坏了。 它具有很酷的心理作用。 并且，当我们尝试通过有条件地为我们的服务分配10个小型整体而摆脱健康的桌面整体时。
Pavel：在此过程中，您没有考虑过将要以某种形式加载的模块是否可以在任何级别上帮助他？
迈克尔： 柯南帮助我们完成了这个过程和Linux迁移过程。 我们在管理第三方方面遇到了严重问题。 我谈到了我们如何在莫斯科的C ++ Russia 2019中使用Conan。
“ plus”模块将有助于解决一些编译时的问题，事实上，这一切都是从编译开始的，为什么每个人都希望使用这些模块。 重复使用肯定的模块与服务进行交互是愚蠢的，因为它们将在某种语言不可知的级别（protobuf）进行通信，这是正确的。 也许我们可以执行组件化工作，而不必每次都从源代码构建250个项目，而是将它们放在Conan的软件包中。 并且，例如，由于某些原因，折叠dll不方便，则可以选择组装成模块。
但是我不能说我们正在等待某些功能会改变我们的开发方法。
Pavel：您提到了Conan帮助您解决程序包管理问题。 在我看来，大约3年前，C ++社区只谈论过这一点。 出现了第一个报告，第一个先决条件。 现在您说它已经在生产中起作用。
告诉我们您的项目发展经验。 过渡过程令人痛苦并且值得吗？
迈克尔：绝对值得。 我们对柯南感到满意。 那里有一些缺陷，但是在C ++中管理依赖项是一项非常困难的任务。 因此，很明显，没有简单的工具可以解决它。
借助柯南及其上的流程，我们实现了任务和解决方案复杂性之间的平衡。 我们最初说过：“好吧，我们要突出显示这么多的编译器和配置集，然后默认情况下构建动态库（而不是静态库），并进行少量限制，”然后我们开始在这组限制内构建系统。 我们有一个Wiki页面“如何为库创建柯南食谱”，其中考虑了我们系统的所有细节。 该页面很大，不是很简单。 但是，我们再次达到了复杂性的平衡，因此我对过渡感到满意。
帕维尔：顺便说一下，在即将到来的C ++ Russia 2019 Piter上，NVIDIA的Denis Panin 将讨论 vcpkg代表的替代方案。 您去看一下报告，听听他们在其他工具中的表现，对您来说会很有趣吗？
迈克尔：是的，这很有趣。 我曾经使用过vcpkg，但是在我看来，vcpkg几乎没有灵活性。 我无法想象如何根据vcpkg的要求构建系统。 但是，如果我需要快速上手并测试某种类型的库，那么我就不会下载它并阅读构建说明，在那儿您需要指定如何注册依赖项，这就是垃圾。 我将查看它是否在vcpkg端口中。 如果有的话，那就快放上去，尝试一下。 如果一切顺利，我将为她写一个柯南食谱。
Pavel：让我们继续介绍新的工具和方法。 您是否遇到过这样的事实，即工程师们在会议上奔忙不已，他们被告知有新奇的事物，他们想将其插入项目中？ 您通常对这些事情有何反应？ 还是在每次会议后都求助？
迈克尔：有一个很棒的故事。 当我刚开始在公司工作时，他们编写了一项功能，因此有必要对其进行配置。 此外，一个功能可以具有多个不同的版本，并且特定属性的值可以在不同的版本之间翻阅。 我想出了一个很酷的基于YAML的方案，其中存在继承和重新定义的属性。 他写了大约一周的时间，并进行了测试。 在一开始，经理就对我说：“听着，迈克尔，也许您现在不需要浪费时间来制定这样一个灵活的计划？” 但是他无法说服我。 我的眼睛太烫了。
几年后，我看了一下这段代码，却不明白为什么如此困难。 发生这种情况，但是幸运的是，从那时起，我变得更聪明了。 另外，通常开发人员是非常理性的人，可以与他们交谈。
过去曾经有人提出可疑的第三方决定。 目前尚不清楚他们是谁开发的，最新的更新是在5年前，尚未验证它是否可以在Linux下运行，他们以专有格式生成任何报告，而您不能将其转换为任何内容。 我们坐在那里，不知道下一步该怎么做。 这些第三方大多数是在多年前添加的，但是现在发生了类似的事情。
因此，我们想出了一个相当简单的东西-第三方清单。 如果要拖动第三方，只需检查以下清单项目：跨平台，支持级别，许可，类似物，开发支持水平（有多少维护者支持，哪个社区）。 所有要点都很明显，但是要点很多，当您键入第三方时，您不会马上记住所有内容。 情况已经好转，我们正在关注增加的内容。
同样很酷的是，例如，仅在“ Windows”和32位以下的版本中，拖动第三方并进行组装很容易。 现在，原则上不再有这种可能性，因为您必须将其放入柯南。 而且，如果您拖动第三方，则必须确保或明确指示在某些配置中它不会这样做。 由于这个原因，剩下的第三方的添加开始减少了。
奥列格（Oleg）：那么，生活很少的第三方呢？ 例如，JavaScript的一些左键 。 他在您的清单上。 它通常由软件包进行更新，维护和制作。
迈克尔：没有这样的事情。 在C ++中，第三方通常是一件很棘手的事情。 并且不使用执行小功能的第三方解决方案。 确实，在C ++中添加第三方并不是那么简单。 这不是JS，其中每个人都有自己的模块。
我们有条件地撤消了80个第三方，其中有一半我从未见过。 或是15年前某所大学写的某种地狱般的几何图形，现在我们有了。
奥列格（Oleg）：使用柯南，添加第三方很容易。
迈克尔：柯南更容易，但与编写pip install并完成的Python仍然相去甚远。 C ++具有非常复杂的生态系统：不同的操作系统，编译器，工具链，库，标准。 大多数库都有很多选择。
他们喜欢问我们：“您为什么要编写图书馆食谱，却不从柯南中心获取它们？” 我从那里定期查看食谱，但它们不适合我们。 我们做得更好。 例如，我们的食谱会处理借记符号，并为其中的来源添加绑定。 因此，当您从Visual Studio的调试器中获取第三方库时，将自动加载源。
因此，用柯南来更好，但与其他语言的便利性相去甚远。
奥列格（Oleg）：我想纠正柯南本身中的任何缺陷吗？
迈克尔：是的，有缺点，但是技术上。
Conan的方法有条件地负责生成程序包并将生成的程序包连接到您的解决方案。 从意识形态上讲，这是两个不同的阶段，我可以改变一个而不必改变另一个。 当我更改程序包的连接方式时，我不想重新生成二进制程序包，因为它们将完全相同。 您无法在柯南中执行此操作，因为配方是一个实体。 如果您更改了配方，则必须正式更改版本并生成新的二进制文件，这很不方便。
向新标准过渡的特点
帕维尔：让我们谈谈新标准。 此外，您的产品已经有一些历史记录。
现在我们来参加会议，每三年他们会告诉我们新的奇妙功能。 例如，在C ++ Russia 2019 Piter上，将有三份有关语言即将进行的更改的报告。 您是否有将旧代码库（与旧标准相对应）迁移到已提供或将要提供的内容的经验？
Mikhail：是的，我有过这样的经验，在C ++ Russia 2019上做了一些介绍。我们从Visual Studio 2013迁移到Visual Studio 2017和gcc，也就是说，我们同时添加了Linux支持和Microsoft的更新编译器。
与组织，技术，基础架构问题，CI和其余调整相比，代码中的问题要少得多。 我们的代码中的问题主要与UB有关，而UB在更新了编译器之后便开始触发。 尽管C ++多年来一直向后兼容，但它们仍在传播。 现在，我们在C ++ 17下编译所有内容。
当开发人员在Windows下收集，推入CI并仅在他们开始在Linux下进行组装时，投票不会同步。 但是没有重大问题。
在C ++ 17中，删除了一些过时的内容，但是我们只花了几个小时就将它们删除了。 例如，log4cplus库在标头中使用std :: auto_ptr，但是在新版本中，它已经被std :: unique_ptr取代，因此足以简单地更新该库。
因此，向新标准的迁移相对容易。 考虑到我们代码库的大小，我惊讶地发现我们遇到的问题很少。
关于C ++中的棕色和黑色腰带
Pavel：您和我已经在谈论现有流程，有经验的开发人员已经在其中工作。 让我们为刚刚学习的新手开发人员提供思想上的帮助。 您建议从哪种C ++标准开始？
迈克尔：我们必须立即采用最新标准。 您将不会在同一C ++ 98中学习STL，因为没有lambda的STL没有意义。 如果您看Coursera上的“ C ++开发基础 ：布朗带”和“ C ++开发基础 ：黑带”课程，那么我们已经在那儿编写了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-.
: , : , , .
: Visual Studio , . , 2010 : , . Microsoft .
: . : const, constexpr, constinit, consteval , , final. final , , constfinal?
: final, , . . , constfinal, .
: , , , , . ?
: , , . , , .
: ?
: , JUG Ru Group , ().
: . ?
: , — . , , , . .
: . , ?
: , . , ().
C++ Russia 2019 Piter «, » . , .