Comments 41
> Они считали, что, как только удастся создать подходящий язык, можно будет создавать отличные библиотеки. И мы ждем этих библиотек уже 20 лет.

Тут возникает риторический вопрос. Можно ли считать, что люди, которые выбирают плюсы для имплементации большинства своих задач — префекционисты или же язык всё еще не достаточно «подходящий» на данный момент? :)
У людей, которые осознанно выбирают С++ сейчас, зачастую просто нет выбора в языке. По скорости работы, эффективности использования памяти и при этом широком выборе эффективных библиотек STL/Boost ему нет равных.
не слишком сильно осведомлен о конкретных областях, где есть ситуация «писать на плюсах или писать на чем-то еще». Просто в iOS-деве часто вижу плюсокод, когда он там, IMHO, не нужен (учитывая все его преимущества по скорости и памяти); т. е. вместо того, чтобы воспользоваться чем-то стандартным из UIKit/Foundation/… в пять строчек, лепятся тыщи строчек высокотипизированного, высокоскоростного и высоконизкозатратного по памяти кода на плюсах, в котором всегда есть то, что нужно багфиксить.

но вопрос не в этом.
Люди которые осознанно выбирают плюсы выбирают их потому, что их все устраивает. Устраивает современный С++, оптимизации компилятора, разные модели параллелизации и векторизации, поддержка OpenCL/CUDA C/Intel Xeon Phi, поддержка кластеров (MPI), и так далее.
Может у них просто задачи такие?
Ну правда…
Зная плюсы, начать писать на практически любом другом языке очень несложно
(как в том анекдоте про студента — «Методичка есть? Пошли сдавать!»).
Типичные задачи, которые легко решаются на другом языке, обычно на нём и остаются.(например, зайти на сайт энергосбыта и внести показания счётчика можно парой вызовов curl-а через любую оболочку вроде bash. И решение, по сути, этим исчерпано; я сильно сомневаюсь, что кто-то будет писать подобное на плюсах или даже на php). Разве что «сферический перфекционист в вакууме».
А вот достаточно простой потоковый парсер текста (с парой простых замен), написанный на python, легко даёт прирост в совокупности ~30% по скорости за счёт переименования .py в .cpp, расстановки фигурных скобочек и последующей компиляции.
Было бы неплохо сделать полностью английскую версию (перевести вопросы) интервью для коллег из других стран.
Вы имеете в виду видео? Да, наверное вы правы. Сделаем.
Но и сейчас расшифровка, включающая вопросы, есть прямо в посте под спойлером.
Да, я имею в виду перевод только текста вопросов из видео, не транскрипцию. Ну и если на то пошло, добавьте еще на youtube к названию видео, что-то вроде Interview with Scott Meyers охватите большую аудиторию.
Добавили заголовок и перевод вопросов включаемыми субтитрами.
Очень правильные вопросы и довольно конкретные ответы. Давно не встречал такого хорошего интервью с одним из ведущих экспертов/создателем какого-либо языка. (Если кто встречал, дайте ссылочки.)

За исключением этого слива:
Возвращаясь к вашему вопросу о выборе между языками: по мне, это решение должно приниматься менеджерами или старшими инженерами. Нужно принимать во внимание, какие цели вы ставите, какова цель ПО, какие сотрудники есть в вашем распоряжении, какая инфраструктура уже выстроена. И все эти вещи нужно пытаться оптимизировать одновременно. Я не даю никаких советов на этот счет, моя работа — понимать C++ и помогать разработчикам эффективнее его использовать. Рассказывать людям о том, стоит ли им применять C++, в мои задачи не входит.
Мне кажется, что в первом вопросе "Move semantics" лучше было перевести как "семантика перемещения" (либо так и оставить "move-семантика") вместо "семантики переноса".

И ещё, второго вопроса из английской версии нету ни в русском варианте, ни в видео-интервью.
Мы пытались использовать самый распространённый вариант. Признаю, что в случае с move semantics этот выбор мог быть ещё не вполне окончательным или правильным.

Про вопрос — упс, это ошибка редактирования, его не должно было остаться в англоязычной версии. Я решил, что он по смыслу повторяет другие и не привносит ничего нового.
Как-то английский вариант не очень соответствует русскому.

Do you think that C++ still has a great future or will everybody be using managed languages in ten years?
Это какая-то ложная дихотомия, кроме С++ все языки управляемые что ли?
Дихотомия ложная, вы совершенно правы. Вопрос был, конечно, о том насколько ценна будет вся та близость к железу, в том числе за которую так ценен C++.
Ключевое слово «auto» это не автоматическое объявление переменных, а автоматическое выведение типов при их объявлении. А то можно подумать, что переменные объявляются при использовании, как в некоторых динамических языках.
Мне казалось, что это и так понятно, но поправил формулировку, чтобы было ещё точнее. Спасибо.
это автоматическое объявление переменных

Ох, если бы это и вправду было так, то программисты были бы не нужны.
«Auto» — ключевое слово, переводить его вообщем-то некорректно.
Нужно обновлять комментарии

А вот идея с центральным репозиторием действительно очень здравая. Давно уже думал, что для полного счастья c++ не хватает аналога maven/npm. А там бы уже и библиотеки для графики подтянулись бы, и обёртки для работы сетью и фс.
Лучше как в Go сделано — система сборки, которая умеет забирать пакеты с гитхаба (а возможно и из других хостингов проектов). Причем в импорте (то есть прямо в исходнике) так и пишешь — url проекта на гитхабе.

И никакой централизации.

А вот стандартизировать бы для плюсов систему сборки… Эх…
И никакой централизации
Централизация как раз очень сильная — GitHub. При удалении или переименовании там репозитория сломаются все его пользователи. Это не говоря уже о хаосе который может учинить какой-нибудь роскомнадзор (для сравнения, пакетные репозитории большинства дистрибутивов как правило используют массу зеркал).

Также меня в таком подходе всегда пугала возможность автора используемого проекта тихо поломать всё что его использует или встроить злонамеренный код. Скорее всего там есть возможность явно указать hash коммита, но она должна быть обязательной. И в любом случае для этого уже есть git submodule, опять таки не привязанные к одному языку/системе сборки.
А я делаю проще — делаю клон/форк нужного мне репозитория (благо на гитхабе это один клик мышкой) и привязываюсь уже к нему. Всё.
Всё равно у этого подхода остаётся масса проблем.
— банально плодятся бесполезные форки
— всё равно нет защиты от подмены репозитория, и нет автоматической возможности её обнаружить (как было бы с явным указанием хэша или submodule), нет защиты от удаления репозитория
— если у вас есть N проектов использующих какой-то код, этот код будет скачиваться, храниться и, что ещё важнее, компилироваться эти N раз
— если в чужом коде нашлась, например, критическая уязвимость, обновление всего парка его пользователей будет весёлым процессом. А ведь ваш код с обновлённым сторонним надо ещё доставить пользователям
Не понял. Это уже мой репозиторий, как мне его подменят или удалят?

Если у меня на машине N проектов, то какой-то код будет скачиваться ОДИН раз и ОДИН раз он в Go компилируется. Для всех проектов.
Это уже мой репозиторий, как мне его подменят или удалят?
Сам GitHub или тот кто получит доступ к вашему аккаунту.

и ОДИН раз он в Go компилируется
Это верно для Go но не для C++, например из-за условной компиляции, разных флагов компилятора в разных проектах и т.д.
Дык если даже сделать единый репозиторий (как в линуксе например), то это не отменит хотелку собрать вот эту вот либу с разными флагами компиляции и так далее.

Однако в большинстве случаев таки в репозитории уже лежат бинари, которые собраны один раз. Так будет и тут — при первом скачивании исходников с гитхаба (или еще чего-то) оно сразу соберется и будет в таком виде присутствовать и использоваться.
Дык если даже сделать единый репозиторий (как в линуксе например), то это не отменит хотелку собрать вот эту вот либу с разными флагами компиляции и так далее.
Почему, header'ы собираются с теми флагами с которыми собирается проект, в этом и фишка.

Так будет и тут — при первом скачивании исходников с гитхаба (или еще чего-то) оно сразу соберется и будет в таком виде присутствовать и использоваться.
Хотя тут ещё можно поспорить (одна, но сборка vs. уже собранный пакет, выкачка всей истории vs. только того что нужно), но хорошо — аргумент о необходимости множественной компиляции убираем.
При чём тут я? Вопрос в том чтобы это умели системы зависимостей типа той что используется в go.
Почему, header'ы собираются с теми флагами с которыми собирается проект, в этом и фишка.

Сама библиотека то останется нетронутой (если распространять в бинарном виде).

Хотелки в виде разных флагов компиляции решаются распределённой компиляцией (силами репозитория или волонтёров) через distcc с последующим кэшированием результата.
> Сама библиотека то останется нетронутой (если распространять в бинарном виде).

Библиотеки бывают и header-only, если что. Но тут речь об наиболее распространённом случае, когда есть и .so'шка собирающаяся один раз, и header'ы чувствительные к локальным флагам.

> Хотелки в виде разных флагов компиляции решаются распределённой компиляцией (силами репозитория или волонтёров) через distcc с последующим кэшированием результата.

Утопия и дыра в безопасности.
header'ы чувствительные к локальным флагам

Не могу понять о чём вы. Если в хидере нет кода, а только объявления классов и прототипы функций, то флаги компиляции на него ну никак не повлияют.
Это уже мой репозиторий, как мне его подменят или удалят?
GitHub удалит ваш форк без предупреждения, например, если вы входили в организацию, форкнули приватный репозиторий, а потом вас из организации удалили. Все ваши форки приватных репозиториев той организации автоматически удаляются с уведомлением на email постфактум.

Думаю, существуют и другие ситуации, в которых «ваш» форк может быть удалён без предупреждения.
При удалении или переименовании там репозитория сломаются все его пользователи

Пару раз переименовывал проект в GitHub — старые ссылки продолжают работать. Главное в них после этого не заливать ничего, будет плохо.
Имхо, эти мысли только от отсутствия в некоторых системах центрального пакетного репозитория из которого единообразно доступны любые библиотеки для любых языков.
Ну не любые, обязательно найдутся библиотеки, которых там нет или есть только устаревшие версии (или, наоборот, слишком новые, без обратной совместимости)
Впервые слышу, потому что не работаю в Windows. Выглядит неплохо. Спасибо.
Более того, на базе NuGet, который всегда считался как-бы только .NET, был сделан Chocolatey Nuget, который вообще все. (Ну или очень многое, от броузеров до VisualStudio или Office)Ну то есть реально как какой-нибудь apt-get но для Windows.
c:\>choco install googlechrome

И у вас скачан и инсталлирован последний стабильный chrome.
(Я его случайно нашел когда озаботился обновлением редактора Github Atom, в котором не было встроенных служб обновления, но которые посоветовали использовать choco)

Ну и развитием этой идей для первоначальной раскрутки голой установки Windows с применением chocolatey является проект BoxStarter. Видео там очень показательное.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

23 October 1997

Location

Россия

Employees

over 10,000 employees

Registered

9 August 2008

Habr blog