Comments 43
> Они считали, что, как только удастся создать подходящий язык, можно будет создавать отличные библиотеки. И мы ждем этих библиотек уже 20 лет.
Тут возникает риторический вопрос. Можно ли считать, что люди, которые выбирают плюсы для имплементации большинства своих задач — префекционисты или же язык всё еще не достаточно «подходящий» на данный момент? :)
Тут возникает риторический вопрос. Можно ли считать, что люди, которые выбирают плюсы для имплементации большинства своих задач — префекционисты или же язык всё еще не достаточно «подходящий» на данный момент? :)
У людей, которые осознанно выбирают С++ сейчас, зачастую просто нет выбора в языке. По скорости работы, эффективности использования памяти и при этом широком выборе эффективных библиотек STL/Boost ему нет равных.
не слишком сильно осведомлен о конкретных областях, где есть ситуация «писать на плюсах или писать на чем-то еще». Просто в iOS-деве часто вижу плюсокод, когда он там, IMHO, не нужен (учитывая все его преимущества по скорости и памяти); т. е. вместо того, чтобы воспользоваться чем-то стандартным из UIKit/Foundation/… в пять строчек, лепятся тыщи строчек высокотипизированного, высокоскоростного и высоконизкозатратного по памяти кода на плюсах, в котором всегда есть то, что нужно багфиксить.
но вопрос не в этом.
но вопрос не в этом.
Люди которые осознанно выбирают плюсы выбирают их потому, что их все устраивает. Устраивает современный С++, оптимизации компилятора, разные модели параллелизации и векторизации, поддержка OpenCL/CUDA C/Intel Xeon Phi, поддержка кластеров (MPI), и так далее.
Может у них просто задачи такие?
Ну правда…
Зная плюсы, начать писать на практически любом другом языке очень несложно
(как в том анекдоте про студента — «Методичка есть? Пошли сдавать!»).
Типичные задачи, которые легко решаются на другом языке, обычно на нём и остаются.(например, зайти на сайт энергосбыта и внести показания счётчика можно парой вызовов curl-а через любую оболочку вроде bash. И решение, по сути, этим исчерпано; я сильно сомневаюсь, что кто-то будет писать подобное на плюсах или даже на php). Разве что «сферический перфекционист в вакууме».
А вот достаточно простой потоковый парсер текста (с парой простых замен), написанный на python, легко даёт прирост в совокупности ~30% по скорости за счёт переименования .py в .cpp, расстановки фигурных скобочек и последующей компиляции.
Ну правда…
Зная плюсы, начать писать на практически любом другом языке очень несложно
(как в том анекдоте про студента — «Методичка есть? Пошли сдавать!»).
Типичные задачи, которые легко решаются на другом языке, обычно на нём и остаются.(например, зайти на сайт энергосбыта и внести показания счётчика можно парой вызовов curl-а через любую оболочку вроде bash. И решение, по сути, этим исчерпано; я сильно сомневаюсь, что кто-то будет писать подобное на плюсах или даже на php). Разве что «сферический перфекционист в вакууме».
А вот достаточно простой потоковый парсер текста (с парой простых замен), написанный на python, легко даёт прирост в совокупности ~30% по скорости за счёт переименования .py в .cpp, расстановки фигурных скобочек и последующей компиляции.
Было бы неплохо сделать полностью английскую версию (перевести вопросы) интервью для коллег из других стран.
Очень правильные вопросы и довольно конкретные ответы. Давно не встречал такого хорошего интервью с одним из ведущих экспертов/создателем какого-либо языка. (Если кто встречал, дайте ссылочки.)
За исключением этого слива:
За исключением этого слива:
Возвращаясь к вашему вопросу о выборе между языками: по мне, это решение должно приниматься менеджерами или старшими инженерами. Нужно принимать во внимание, какие цели вы ставите, какова цель ПО, какие сотрудники есть в вашем распоряжении, какая инфраструктура уже выстроена. И все эти вещи нужно пытаться оптимизировать одновременно. Я не даю никаких советов на этот счет, моя работа — понимать C++ и помогать разработчикам эффективнее его использовать. Рассказывать людям о том, стоит ли им применять C++, в мои задачи не входит.
Мне кажется, что в первом вопросе "Move semantics" лучше было перевести как "семантика перемещения" (либо так и оставить "move-семантика") вместо "семантики переноса".
И ещё, второго вопроса из английской версии нету ни в русском варианте, ни в видео-интервью.
И ещё, второго вопроса из английской версии нету ни в русском варианте, ни в видео-интервью.
Мы пытались использовать самый распространённый вариант. Признаю, что в случае с move semantics этот выбор мог быть ещё не вполне окончательным или правильным.
Про вопрос — упс, это ошибка редактирования, его не должно было остаться в англоязычной версии. Я решил, что он по смыслу повторяет другие и не привносит ничего нового.
Про вопрос — упс, это ошибка редактирования, его не должно было остаться в англоязычной версии. Я решил, что он по смыслу повторяет другие и не привносит ничего нового.
А видеозапись с самого тренинга не планируете выложить?
Видеозапись самого тренинга мы не имеем права выкладывать.
На сайте у Скотта можно купить PDF на базе этого же тренинга: www.artima.com/shop/overview_of_the_new_cpp
На сайте у Скотта можно купить PDF на базе этого же тренинга: www.artima.com/shop/overview_of_the_new_cpp
UFO just landed and posted this here
Ключевое слово «auto» это не автоматическое объявление переменных, а автоматическое выведение типов при их объявлении. А то можно подумать, что переменные объявляются при использовании, как в некоторых динамических языках.
это автоматическое объявление переменных
Ох, если бы это и вправду было так, то программисты были бы не нужны.
«Auto» — ключевое слово, переводить его вообщем-то некорректно.
Нужно обновлять комментарии
А вот идея с центральным репозиторием действительно очень здравая. Давно уже думал, что для полного счастья c++ не хватает аналога maven/npm. А там бы уже и библиотеки для графики подтянулись бы, и обёртки для работы сетью и фс.
Лучше как в Go сделано — система сборки, которая умеет забирать пакеты с гитхаба (а возможно и из других хостингов проектов). Причем в импорте (то есть прямо в исходнике) так и пишешь — url проекта на гитхабе.
И никакой централизации.
А вот стандартизировать бы для плюсов систему сборки… Эх…
И никакой централизации.
А вот стандартизировать бы для плюсов систему сборки… Эх…
И никакой централизацииЦентрализация как раз очень сильная — GitHub. При удалении или переименовании там репозитория сломаются все его пользователи. Это не говоря уже о хаосе который может учинить какой-нибудь роскомнадзор (для сравнения, пакетные репозитории большинства дистрибутивов как правило используют массу зеркал).
Также меня в таком подходе всегда пугала возможность автора используемого проекта тихо поломать всё что его использует или встроить злонамеренный код. Скорее всего там есть возможность явно указать hash коммита, но она должна быть обязательной. И в любом случае для этого уже есть git submodule, опять таки не привязанные к одному языку/системе сборки.
А я делаю проще — делаю клон/форк нужного мне репозитория (благо на гитхабе это один клик мышкой) и привязываюсь уже к нему. Всё.
Всё равно у этого подхода остаётся масса проблем.
— банально плодятся бесполезные форки
— всё равно нет защиты от подмены репозитория, и нет автоматической возможности её обнаружить (как было бы с явным указанием хэша или submodule), нет защиты от удаления репозитория
— если у вас есть N проектов использующих какой-то код, этот код будет скачиваться, храниться и, что ещё важнее, компилироваться эти N раз
— если в чужом коде нашлась, например, критическая уязвимость, обновление всего парка его пользователей будет весёлым процессом. А ведь ваш код с обновлённым сторонним надо ещё доставить пользователям
— банально плодятся бесполезные форки
— всё равно нет защиты от подмены репозитория, и нет автоматической возможности её обнаружить (как было бы с явным указанием хэша или submodule), нет защиты от удаления репозитория
— если у вас есть N проектов использующих какой-то код, этот код будет скачиваться, храниться и, что ещё важнее, компилироваться эти N раз
— если в чужом коде нашлась, например, критическая уязвимость, обновление всего парка его пользователей будет весёлым процессом. А ведь ваш код с обновлённым сторонним надо ещё доставить пользователям
Не понял. Это уже мой репозиторий, как мне его подменят или удалят?
Если у меня на машине N проектов, то какой-то код будет скачиваться ОДИН раз и ОДИН раз он в Go компилируется. Для всех проектов.
Если у меня на машине N проектов, то какой-то код будет скачиваться ОДИН раз и ОДИН раз он в Go компилируется. Для всех проектов.
Это уже мой репозиторий, как мне его подменят или удалят?Сам GitHub или тот кто получит доступ к вашему аккаунту.
и ОДИН раз он в Go компилируетсяЭто верно для Go но не для C++, например из-за условной компиляции, разных флагов компилятора в разных проектах и т.д.
Дык если даже сделать единый репозиторий (как в линуксе например), то это не отменит хотелку собрать вот эту вот либу с разными флагами компиляции и так далее.
Однако в большинстве случаев таки в репозитории уже лежат бинари, которые собраны один раз. Так будет и тут — при первом скачивании исходников с гитхаба (или еще чего-то) оно сразу соберется и будет в таком виде присутствовать и использоваться.
Однако в большинстве случаев таки в репозитории уже лежат бинари, которые собраны один раз. Так будет и тут — при первом скачивании исходников с гитхаба (или еще чего-то) оно сразу соберется и будет в таком виде присутствовать и использоваться.
Дык если даже сделать единый репозиторий (как в линуксе например), то это не отменит хотелку собрать вот эту вот либу с разными флагами компиляции и так далее.Почему, header'ы собираются с теми флагами с которыми собирается проект, в этом и фишка.
Так будет и тут — при первом скачивании исходников с гитхаба (или еще чего-то) оно сразу соберется и будет в таком виде присутствовать и использоваться.Хотя тут ещё можно поспорить (одна, но сборка vs. уже собранный пакет, выкачка всей истории vs. только того что нужно), но хорошо — аргумент о необходимости множественной компиляции убираем.
выкачка всей истории
Откройте для себя «git clone --depth 1»
Почему, header'ы собираются с теми флагами с которыми собирается проект, в этом и фишка.
Сама библиотека то останется нетронутой (если распространять в бинарном виде).
Хотелки в виде разных флагов компиляции решаются распределённой компиляцией (силами репозитория или волонтёров) через distcc с последующим кэшированием результата.
> Сама библиотека то останется нетронутой (если распространять в бинарном виде).
Библиотеки бывают и header-only, если что. Но тут речь об наиболее распространённом случае, когда есть и .so'шка собирающаяся один раз, и header'ы чувствительные к локальным флагам.
> Хотелки в виде разных флагов компиляции решаются распределённой компиляцией (силами репозитория или волонтёров) через distcc с последующим кэшированием результата.
Утопия и дыра в безопасности.
Библиотеки бывают и header-only, если что. Но тут речь об наиболее распространённом случае, когда есть и .so'шка собирающаяся один раз, и header'ы чувствительные к локальным флагам.
> Хотелки в виде разных флагов компиляции решаются распределённой компиляцией (силами репозитория или волонтёров) через distcc с последующим кэшированием результата.
Утопия и дыра в безопасности.
Это уже мой репозиторий, как мне его подменят или удалят?GitHub удалит ваш форк без предупреждения, например, если вы входили в организацию, форкнули приватный репозиторий, а потом вас из организации удалили. Все ваши форки приватных репозиториев той организации автоматически удаляются с уведомлением на email постфактум.
Думаю, существуют и другие ситуации, в которых «ваш» форк может быть удалён без предупреждения.
При удалении или переименовании там репозитория сломаются все его пользователи
Пару раз переименовывал проект в GitHub — старые ссылки продолжают работать. Главное в них после этого не заливать ничего, будет плохо.
Он скорее всего имел ввиду указать git репозиторий, но как обычно спутали gh и git. Ржавые как-то так и делают если очень хочется - и репу указать и хэш/ветку/тэг.
Имхо, эти мысли только от отсутствия в некоторых системах центрального пакетного репозитория из которого единообразно доступны любые библиотеки для любых языков.
Под Windows как-то работает NuGet.
Впервые слышу, потому что не работаю в Windows. Выглядит неплохо. Спасибо.
Более того, на базе NuGet, который всегда считался как-бы только .NET, был сделан Chocolatey Nuget, который вообще все. (Ну или очень многое, от броузеров до VisualStudio или Office)Ну то есть реально как какой-нибудь apt-get но для Windows.
И у вас скачан и инсталлирован последний стабильный chrome.
(Я его случайно нашел когда озаботился обновлением редактора Github Atom, в котором не было встроенных служб обновления, но которые посоветовали использовать choco)
Ну и развитием этой идей для первоначальной раскрутки голой установки Windows с применением chocolatey является проект BoxStarter. Видео там очень показательное.
c:\>choco install googlechrome
И у вас скачан и инсталлирован последний стабильный chrome.
(Я его случайно нашел когда озаботился обновлением редактора Github Atom, в котором не было встроенных служб обновления, но которые посоветовали использовать choco)
Ну и развитием этой идей для первоначальной раскрутки голой установки Windows с применением chocolatey является проект BoxStarter. Видео там очень показательное.
А вы сами пишете сейчас код? Если нет, то садитесь и пишите.
Sign up to leave a comment.
Интервью Скотта Мейерса в Яндексе. О настоящем и будущем C++