Было бы интересно поговорить про плюсы MPX по сравнению с ASAN.
Насколько я понимаю, в ASAN используется инструментация + битмап, в котором помечены валидные для обращения байты. Существенный недостаток — не обрабатывается переполнение буфера внутри структуры (т.е. когда мы перетерли соседние поля в структуре, но за пределы структуры не вылезли).
код функции std:sort() известен априори компилятору C++. А для C это на усмотрение разработчика.
Это утверждение можно прочитать как: «код std::sort зашивается в компилятор, реализовать собственную сортировку разработчик не может», что мягко говоря не правда.
На счет link time code generation — теоретически конечно да, но есть нюанс — любой оптимизатор штука достаточно консервативная, и проводить по собственной инициативе инлайнинг, который приведет к массивному раздуванию кода (что случится в случае оптимизации qsort) он не станет.
В случае плюсовых шаблонов, разработчик «заказывает» такое поведение явно. Ну то есть в стандарте написано, что использование шаблонов потенциально приведет к созданию нескольких реализаций, по одной для каждого используемого сочетания типов. Если разработчик так пишет, значит он знает что делает и то что кода получится дофига — это именно то, что он хочет.
Да где то сделали готовую библиотеку для работы с тем же HTTP но как это связано с самим языком?
Неправильно рассматривать язык отдельно, а библиотеки отдельно.
Это очень удобно, когда вместе с языком ставится стандартная библиотека, которая решает 95% повседневных задач. Как в питоне например.
Давайте проведем эксперимент — посоветуйте мне библиотеку для работы с HTTP в С++?
Я уверен, предложите десяток вариантов. А мне нужен ровно один. И чтобы не было проблем с деплоем.
На всякий случай напомню контекст — Страуструп утверждает, что C++ — разумный выбор, когда требуется написать маленькую одноразовую утилиту («Five Popular Myths about C++; 5. C++ is for large, complicated, programs only»). Так именно на таких задач особенно важна богатая стандартная библиотека.
JavaScript это такой-же язык как любой другой. Возможности зависят от среды выполнения — всегда есть внешние функции (которые сами реализованы не на JS) которые можно вызывать из JS. Например — функции для работы с DOM, CSSOM и объектной моделью самого браузера.
Движок выполнения JS поддерживает внешние функции; конкретные возможности зависят от набора «прокинутых» функций. В браузере JS выполняется в «песочнице», возможности сознательно ограничены.
Node.js — это технология для разработки сервера на JavaScript, там возможности намного шире.
Любопытно кстати, что C++ тоже можно аналогично «кастрировать». У google есть технология NaCl (NativeClient) — выполнение нативного кода в безопасной песочнице в браузере у пользователя, аналогично JS. В первой версии песочница создавалась средствами ОС, а C++ был почти обычный. Это уже потом они сделали компиляцию в промежуточный байткод и другую магию.
Ок, я в последнее время больше связан с линуксами и маками, поэтому пишу про то, что знаю.
В самом деле еще остались системы без пакетных менеджеров? Я слышал для винды что-то в этом плане делалось. Плюс пакетным менеджером возможности не ограничиваются (ссылка на стандартные системы сборки).
И, наконец, какая из версий compose() более эффективная? С++ — потому что ей не надо подсчитывать символы в аргументах и она не использует динамическую память для коротких строк.
Однако Великий слегка гонит — хотя оптимизация аллокаций для коротких строк за счет встроенного в std::string буфера возможна, никто не гарантирует что так и будет. Например в libstdc++ и libc++ это не так (стандартная C++ либа на Linux и новая либа от создателей Clang). Если скорость некоторого куска кода весьма важна, приходится разбираться и лезть в кишки.
С точки зрения самого языка все ОК — ничего не мешает написать контейнер с нужными свойствами. Но ожидать что STL прямо так оптимален для всего наивно. Сложно удовлетворить конфликтующие требования, например оптимизация для коротких строк увеличивает размер объекта и на некоторых задачах это может быть нежелательно.
Жаль, я рассчитывал узнать про «слепые аллокаторы и вызовы/возвраты на стеке». Хотя программировать на си/c++ я начал не совсем вчера, мне это мало что говорит.
сишное решение при прочих равных (если руками написано) будет не много медленнее чем оно же на ASM-е
Например, у интела есть особые инструкции (пруф #1) для быстрого вычисления некоторых хешей.
Plain-C — я называю портабельное решение, которое использует исключительно битовые операции и прочие возможности, которые есть в стандартном Си. Такое решение будет (а) компилироваться подо все (б) тормозить.
Да, можно использовать интринсики, и писать «как-бы» на Си. Это имеет примерно такое же отношение к Plain-C, что и инлайн ассемблер. Последний кстати в gсс просто божественный, так как нормально умеет взаимодействовать с оптимизатором.
Алгоритмы предполагается использовать в целях обучения — в реальных проектах рекомендуется в целях безопасности использовать существующие библиотеки
Кроме безопасности, есть еще одна причина — plain C реализация как правило медленная. Production-grade(sic :) решения затачиваются под конкретное железо (AVX, SSE, и тд.)
gitlabя буду обновлять коментарииНасколько я понимаю, в ASAN используется инструментация + битмап, в котором помечены валидные для обращения байты. Существенный недостаток — не обрабатывается переполнение буфера внутри структуры (т.е. когда мы перетерли соседние поля в структуре, но за пределы структуры не вылезли).
На счет link time code generation — теоретически конечно да, но есть нюанс — любой оптимизатор штука достаточно консервативная, и проводить по собственной инициативе инлайнинг, который приведет к массивному раздуванию кода (что случится в случае оптимизации qsort) он не станет.
В случае плюсовых шаблонов, разработчик «заказывает» такое поведение явно. Ну то есть в стандарте написано, что использование шаблонов потенциально приведет к созданию нескольких реализаций, по одной для каждого используемого сочетания типов. Если разработчик так пишет, значит он знает что делает и то что кода получится дофига — это именно то, что он хочет.
Ближайший аналог шаблонов в Си — макросы.
И вобще, double сортировать стремно, поскольку на этом множестве не определено отношение полного порядка (NaN != NaN и прочие приколы).
Это очень удобно, когда вместе с языком ставится стандартная библиотека, которая решает 95% повседневных задач. Как в питоне например.
Давайте проведем эксперимент — посоветуйте мне библиотеку для работы с HTTP в С++?
Я уверен, предложите десяток вариантов. А мне нужен ровно один. И чтобы не было проблем с деплоем.
На всякий случай напомню контекст — Страуструп утверждает, что C++ — разумный выбор, когда требуется написать маленькую одноразовую утилиту («Five Popular Myths about C++; 5. C++ is for large, complicated, programs only»). Так именно на таких задач особенно важна богатая стандартная библиотека.
Движок выполнения JS поддерживает внешние функции; конкретные возможности зависят от набора «прокинутых» функций. В браузере JS выполняется в «песочнице», возможности сознательно ограничены.
Node.js — это технология для разработки сервера на JavaScript, там возможности намного шире.
Любопытно кстати, что C++ тоже можно аналогично «кастрировать». У google есть технология NaCl (NativeClient) — выполнение нативного кода в безопасной песочнице в браузере у пользователя, аналогично JS. В первой версии песочница создавалась средствами ОС, а C++ был почти обычный. Это уже потом они сделали компиляцию в промежуточный байткод и другую магию.
В самом деле еще остались системы без пакетных менеджеров? Я слышал для винды что-то в этом плане делалось. Плюс пакетным менеджером возможности не ограничиваются (ссылка на стандартные системы сборки).
Если нет, можно сделать make install.
Если библиотека использует ту же систему сборки, что и ваш проект ее можно тривиально включить в сборку (актуально как минимум для CMake и autotools).
Если библиотека вообще не собирается на вашей архитектуре/версии компилятора, то это либо плохая библиотека, либо повод сделать патч :)
Ладно, сложение строковых литералов это боян. Давайте попробуем свежачок.
С точки зрения самого языка все ОК — ничего не мешает написать контейнер с нужными свойствами. Но ожидать что STL прямо так оптимален для всего наивно. Сложно удовлетворить конфликтующие требования, например оптимизация для коротких строк увеличивает размер объекта и на некоторых задачах это может быть нежелательно.
Жаль, я рассчитывал узнать про «слепые аллокаторы и вызовы/возвраты на стеке». Хотя программировать на си/c++ я начал не совсем вчера, мне это мало что говорит.
Вобще говоря, ИМХО вы не правы. Если есть желание, можно обсудить конкретные кейсы. Например, я не понял что вы хотели сказать этим
Например, у интела есть особые инструкции (пруф #1) для быстрого вычисления некоторых хешей.
Plain-C — я называю портабельное решение, которое использует исключительно битовые операции и прочие возможности, которые есть в стандартном Си. Такое решение будет (а) компилироваться подо все (б) тормозить.
Да, можно использовать интринсики, и писать «как-бы» на Си. Это имеет примерно такое же отношение к Plain-C, что и инлайн ассемблер. Последний кстати в gсс просто божественный, так как нормально умеет взаимодействовать с оптимизатором.
Кроме безопасности, есть еще одна причина — plain C реализация как правило медленная. Production-grade(sic :) решения затачиваются под конкретное железо (AVX, SSE, и тд.)
Ваш К.О.