Сегодня в питерском офисе Яндекса пройдет встреча со специалистами по параллельному программированию. К нам придут Жоэль Фальку из французской Лаборатории исследований в области информатики, Гор Нишанов из Microsoft и Кирк Шуп, который работает над Microsoft Azure. Специально для читателей Хабра мы попросили Гора Нишанова и Кирка Шупа рассказать об их личном опыте, отношении к C++, проблемах и развитии языка.


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

imageГор Нишанов — главный инженер по разработке (Principal Software Design Engineer) в команде C++ разработчиков в Microsoft. Он работает над ‘await’. До того как присоединиться к C++ команде, Гор работал над распределенными системами. В прошлом году выступал на ежегодной конференции CppCon, которую организует Standard C++ Foundation, с докладом C++ Coroutines. A negative overhead abstraction.


Расскажите, как вы начали программировать на C++?

C 1992 года я подрабатывал разработкой программ на C++ для Windows, используя Win32 и MFC. Но этот опыт не был положительным :-) По-настоящему я познакомился с С++, когда поступил в 1996 в аспирантуру в Политехнический институт Ренсселера, где работал Дэйв Мюссер, один из соавторов Александра Степанова. Благодаря нему, computer science department был насыщен духом современного C++, который в то время не был широко известен.

Возможность создавать абстракции без потери эффективности, generic programming и правильное использование RAII сделали C++ для меня очень привлекательным. Мне хотелось попробовать применить современный C++ на большом индустриальном проекте, и Windows NT был отличным кандидатом для этого эксперимента. Я проработал в отделении операционных систем Microsoft 15 лет, где использовал современный С++ во всех проектах, с которыми сталкивался. Опыт оказался успешным, но также накопилось много пожеланий, как можно было бы улучшить язык и библиотеки. Три особо наболевшие проблемы — ошибки в многопоточных программах, очень медленная компиляция и нечитаемые многостраничные ошибки компиляции, связанные с C++ шаблонами, — требовали решения. Я перешел в команду Visual C++ в конце 2013 года, чтобы попробовать помочь решить эти проблемы, а именно, добавить в C++ удобную поддержку многопоточного программирования, модульную систему и систему концепций для шаблонов. Последняя уже была в заключительной стадии разработки Эндрю Саттоном, дело было только за тем, чтобы добавить поддержку в компилятор. С++ сопрограммы, над которыми я сейчас работаю, это часть решения проблем многопоточного программирования. Пока шаблонов нет, наберитесь мужества и говорите себе, что эффективные высокоуровневые абстракции того стоят.

В каких направлениях в первую очередь стоит улучшать C++?

Мой тoп-6 — это Coroutines, Modules, Concepts, Contracts, Reflection, libraries supporting concurrent/async programming. Я думаю, что у каждого программиста есть свой собственный приоритетный список. В данном случае мой топ-6 отражают проблемы, с которыми я сталкивался.

Какие инсайды по грядущим стандартам, которые пока находятся в разработке, на ваш взгляд, наиболее интересны?

Главные три: Coroutines, Modules, Concepts. Две поменьше: default comparisons, unified function call syntax. Библиотеки: Ranges, Executors, Networking Library

Каковы наиболее актуальные проблемы разработки в наше время?

Нерешенная проблема — эффективная поддержка многопоточного программирования. Частичные решения, такие как сопрограммы, executors, networking library, functional reactive programming это все части, но пока они не собраны в когерентное целое.

Планируется ли закончить работу до «окончательного релиза» C++17?
Что войдет С++ 17, станет ясно к концу 2016.

Когда будут executor'ы в STL? Какой их статус сейчас?
В C++20, пока есть несколько предложений, и, скорее всего, консенсус не будет достигнут до того момента, когда С++17 будет закрыт.

Что в итоге будет с std::async, и чем или как он будет заменен?
Пока отсутствуют конкретные предложения.

Как изменится параллельное, многопоточное, конкурентное программирование в C++17? Планируются ли киллер-фичи, написание многопоточных серверов длиной в экран кода при помощи новых фич? Какие участники сообщества или рабочие группы трудятся над этой областью, и где их найти в интернете?

В следующие две конференции по стандартизации станет ясно (http://isocpp.org/, open-std.org/jtc1/sc22/wg21/docs/papers/2015).

Планируется ли расширение библиотеки стандартных элементов?
Optional, variant, string_span, array_span, возможно, войдут в C++17.

Boost известен своими многостраничными сообщениями об ошибках. А какие способы используете Вы для отладки шаблонов C++?
Это одна из моих топ-3 проблем с C++. Концепции Шаблонов должны помочь избавиться от неё. Пока концепций нет, наберитесь мужества и говорите себе, что эффективные высокоуровневые абстракции того стоят.

Что бы вы порекомендовали молодым разработчикам, желающим пойти по Вашим стопам?
Занимайтесь тем, к чему у вас лежит душа и что хорошо получается.

Кирк Шуп пришел в Microsoft стажером в 1993 году. Основное направление, над которым он работает, — Azure Machine Learning. Ещё он участвует в нескольких open source проектах компании: Dash.js, Blink, OpenJDK, Redis. Сейчас Кирк пишет асинхронные библиотеки типа rxcpp, async и transducer. Кирку нравится изучать и применять новые фичи компиляторов, чтобы добиваться большей безопасности и выразительности моих библиотек и моего кода.


Интервью на английском для тех, кому интереснее читать в оригинале
If you would design C++ from scratch, what would you do differently?

C++ is actually a set of several languages; Preprocessor, C, C++, templates – perhaps even Concepts and constexpr are all separate languages. I think that being backward compatible with C was a successful decision and similarly, I would like to have had a C compatible language (subset) to run at compile-time and manipulate and create types to be used at runtime. I have written a lot of template code because most of the problems I want to solve benefit from compile-time code execution, so having a real language with a source debugger with breakpoints to attach to the compiler during a build would a dream come true.

In which directions should C++ be improved in the first place? Your ideas.

I like building types at compile-time. I really would like to build identifier names at compile-time. Another idea I proposed a while ago was to add the ScopeGuard behavior into the lambda syntax. So ‘FILE file = nullptr; auto fileClose = [~](){if (file) fclose(file);}’ would create a function object that put the code-block in the destructor instead of operator()().

What are the most interesting features that are going to appear in the upcoming C++ standards?

The most interesting features that are going to appear in the upcoming C++ standards are co_await, co_yield, co_return are important building blocks for usable async. Concepts are vital for reasonable errors from template libraries. Modules are essential to allow building isolation between components – which will hopefully be used to build a package-manager that will make dependencies between libraries workable.

What are the most actual problems of the software development nowadays?

My focus has always been to build libraries (as opposed to tools) that prevent me from checking in bugs when possible and that prevent me from shipping bugs otherwise. One example: a smart error code class that calls abort() when the error value is changed, but is not checked.

How parallel and concurrent programming is going to change with C++17? Will there be some killer features allowing to write a multithreaded server fitting on a single screen? Which people and working groups are working in this area? Where can one read about them on the Internet?

Once we have asio and some defined async patterns – maybe coawait as well — I hope to see a concurrency STL library added that will provide the algorithms that will remove thread and mutex from concurrent code.

8. What are the new standard ways of developing multithreaded programs in C++? What are the practical issues you usually have?

I advocate using algorithms built on concurrency abstractions that remove thread and lock primitive usage behind the abstraction. The issues with concurrency are code structure (which is improved with algorithms) and debugging.

What would be your recommendations for young developers willing to follow in your footsteps?

Find the things that motivate you, write lots of code and read lots of code. I am motivated to build things that last years after I leave them – they resist being broken, even when changed by people that do not understand them.

When I started programming, I saw all these senior programmers and thought that after 10 years I might finally catch up, but that by then they would be another ten years ahead. After ten years, I saw that I was actually fully caught up. The technologies move on, so I did not learn technologies that fell out of mainstream and at the same time I did learn the new technologies along with the senior programmers.


Если бы вы проектировали C++ с нуля, что бы вы изменили?

C++ на деле — это набор из нескольких языков. Препроцессор, Си, Си++, шаблоны — пожалуй, даже Concepts и constexpr — всё это отдельные языки. Я думаю, что обратная совместимость с Си была удачным решениеи, и по этому подобию я хотел бы иметь совместимый с Си язык (подмножество языка), который исполнялся бы во время компиляции для манипуляций с типизацией. Я написал за свою жизнь много кода на шаблонах, потому что большинство проблем, над которыми я работаю, выигрывают, если часть их решения исполнять во время компиляции. Так что нормальный язык с дебагом и возможностями для отладки, связанный с компилятором, был бы просто мечтой.

В каких направлениях надо прежде всего развивать C++?

Мне нравится создание типов во время компиляции. Было бы здорово иметь возможность определять названия во время компиляции. Другая идея, предложенная некоторое время назад, — добавить ScopeGuard к lambda-синтаксису.

Что интересного должно появиться в новых стандартах C++?

Самые интересные возможности — co_await, co_yield, co_return, — важные составные части для удобного async. Concepts очень важны для нормальных сообщений об ошибках от библиотек на шаблонах. Модули необходимы для того, чтобы создать разделение между компонентами, — что, я надеюсь, будет использовано для создания менеджера пакетов, который поможет разобраться в зависимостях между библиотеками.

Какие проблемы наиболее актуальны сегодня в разработке?

Я всегда был сконцентрирован на разработке библиотек (а не инструментов), которые освободили бы меня от вылавливания ошибок и вообще от их появления. Пример — умный класс для кода ошибки, который вызывает abort(), когда значение ошибки изменилось, но ещё не отработано.

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

Я надеюсь, что когда у нас будет asio и некоторые паттерны с async, а может ещё coawait, мы увидим многопоточность в STL. Это позволит больше не использовать thread и mutex в коде для многопоточного исполнения.

Как сейчас правильно писать многопоточный код на C++?

Я всегда за алгоритмы, построенные на concurrency abstractions, которые убирают примитивное использование thread и lock за уровень абстракции.

Что бы вы посоветовали молодым разработчикам, которые хотят последовать вашему пути?

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

Когда я начинал программировать, смотрел на опытных разработчиков и думал, что через 10 лет я догоню их текущий уровень, но они уже уйдут вперёд на 10 лет. Через десять лет я понял, что на самом деле полностью их догнал. Технологии двигаются вперёд, так что мне не пришлось изучать старые, а новые я узнавал одновременно с ними.

Комментарии (7)


  1. EndUser
    25.02.2016 17:35
    +2

    1998 C++98
    2003 C++03 (5 лет)
    2011 C++11 (8 лет)
    2014 C++14 (3 года)
    2017 C++17 (3 года)

    Не хотят ли они обогнать Chrome/Firefox по номеру версии? ;-)
    Или они готовятся к технологической сингулярности? ;-)


    1. thedsi666
      25.02.2016 20:25
      +3

      Была вроде такая цель — новый стандарт раз в 3 года, причем чередуются небольшие обновления (C++14) с крупными (C++11, C++17).


    1. vladon
      03.03.2016 10:59

      C++98 и C++03 можно назвать одним стандартом буквально, там чисто косметические изменения. Так что до 11-го прошло 13 лет.


  1. devbutch
    25.02.2016 17:45
    +13

    Когда я начинал программировать, смотрел на опытных разработчиков и думал, что через 10 лет я догоню их текущий уровень, но они уже уйдут вперёд на 10 лет. Через десять лет я понял, что на самом деле полностью их догнал. Технологии двигаются вперёд, так что мне не пришлось изучать старые, а новые я узнавал одновременно с ними.

    Мне кажется это сильная циата. Очень чётко подчёркивает характер it индустрии и роль разработчика в ней.


  1. Amomum
    25.02.2016 23:19

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

    Полностью поддерживаю!


  1. semenyakinVS
    26.02.2016 00:42

    Спасибо за интервью! Вот ещё одно (с с Эриком Ниблером) в купу — тоже от Яндекса, кстати. Видны переклички по многим идеями. Модули, решение зависимостей, тут ещё про многопоточность говорили...

    Но мне вот лично, имхо, сильнее всего одна идея горит из перечисленных. Она выражена цитатой:

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

    Вот. Язык, который на этапе сборки позволяет догенерировать программу. В очередной раз выскажу мнение (вот тут уже обсуждалось), что решаться это должно доступом к AST. Причём именно с отладкой, адекватным выводом информации об ошибках, и.т.д. Полноценный язык (функциональный, скорее всего). И всякий шаблонно-макросный ад уйдёт в прошлое, наконец.


  1. Halt
    27.02.2016 12:09
    +2

    У вас перевод вопроса кривой. Не концепций шаблонов, а концептов. Template concepts.