Любой язык программирования и его возможности — это всего лишь инструмент.

Согласен, однако инструменты для одних и тех же целей могут быть с разной степенью безопасности. Циркулярная пила, например, может быть без защитного кожуха, а может быть и с ним.

Моя личная позиция по этому поводу: если можно сделать язык безопаснее на уровне базовых концепций — это должно быть сделано.

Длина массива, как известно, в C/C++ в функцию не передаётся

Именно поэтому в С++ для динамических массивов надежнее пользоваться std::vector<T> а для статических std::array<T, N> (начиная с С++11).

Ну и конечно же не нужно в ручную заботиться о выделении/освобождении памяти.

А получите-ка, сударь, минус в карму за множественные оскорбления в адрес присутствующих, а так же за попытку разжигания национальной розни =)

Искренне ваш.

Спасибо за замечание. Давно не живу в русскоязычной среде — забыл как правильно.

Статья познавательная, но есть пара замечаний:

1. Пропущен вопрос того, как инстанциируются шаблоны в С++ (а по умолчанию они инстанциируются для каждой единицы компиляции и это вопрос можно частично решить с помощью extern template из С++11)
2. Оптимизация процесса линковки тоже не описана, ведь как минимум в MSVS существуют разные варианты оптимизации на этом уровне, например Whole Program Optimization не позволяет делать инкрементальную линковку, что очень неприятно когда при изменении одной строки кода приходится ждать несколько минут на линковке. По моему опыту, полученному из ряда эксперименов, при включеном WPO файлы компилируются быстрее, но время с лихвой съедается за счет линковки в случае большого проекта. При выключеном — компиляция удлинняется, зато линковка почти мгновенная.

Во-вторых, не раз и не два видел, как ради скорости, народ плюет на готовые решения и пишет небольшие ОС, выполняющие только те задачи, которые нужно.

Чем более ограниченой является задача, тем проще заниматься оптимизацией кода под нее.

Может =)

А можно ссылочку на документацию? Меня интересует эта тема.

Возможно имелись какие-то конкретные функции, которые возвращают Option, но вообще заменой исключениям в большинстве случаев являются https://doc.rust-lang.org/std/result/ .

Тоже бросилось в глаза, но вы уже написали про это.

#define TRUE FALSE //Happy debugging suckers

Это слишком просто, здесь есть на много больше интересного.

Rust решает проблему зомби крайне просто с точки зрения разработчика — код просто не скомпилируется при попытке использования перемещенной переменной.

Просто интересно как? Для меня проблема решается трек-поинтом.

Это ваше мнение? Может быть он просто заменил какой-то «влобный» алгоритм чуть более продвинутой оптимизацией? Я согласен с предыдущим комментатором, что ускорить в два раза, чтобы было понятно всем — это совершенно другая задача.

Я видел лично этот процесс т.к хотел научиться лучшему. Сидел рядом и смотрел как смещения в массиве подбираются путем перебора.
А насчет того, что было стелано — решены проблемы CPU кэшинга, что реально очень важно там, где миллисекунды идут на счет.

Что делали мы: замена всего что можно на SIMD и переписывание кривого С++ интерфейса сторонней библиотеки, т.к. С++ интерфейс допускал лишние вызовы тяжелых С функций.

Если # просто замена /, то %s#^/\.*\s##g — удаляет последовательность точек, а то что вы написали — удаляет последовательность любых символов до последнего пробела.

удаление строк содержащих заданный шаблон

В Vim для этого проще всего воспользоваться g/pattern/d либо для удаления строк не подходяших под шаблон моджно v/pattern/d. Лично я польуюсь последним когда мне нужно отфильтровать логи по какому-то логическому принципу, например, оставить только полученные команды и переходы состояний.

Но, вместо d что является командой к удалению, можно использовать другие команды, например связав с заменой по регулярному выражению g/pattern/s/some_other_pattern/replacement/.

Мне это кажется удобным.

Стоит отметить, что это фичи текстового редактора, которые я считаю удобными.

Все правильно, время на ревью должно учитываться во времени разработки, собственно из-за того, что на ревью не выделяется положенное время, на него начинают забивать ибо своих дел полно.