Мне было, наверное, лет 7 (~2001 год) когда дома появился ПК с 98-ой на борту. Точно помню, что знакомый родителей, который нам его привёз, запускал там винрарный Commandos 2 (узнал об этом много позже, тогда это были для меня просто картинки). А я тогда добивал Flashback на Сеге, и поначалу отдавал предпочтение шестнадцатибитной старушке. Но любопытство взяло своё. Парадоксально, но сейчас приятно вспоминать тот страх перед неизвестностью, перед самыми первыми шагами, когда ты представить не можешь, к чему приведёт очередной клик.
Не уверен насчёт Гита, но, например, если юзать Subversion, то есть плагин для Ворда. А если plain text, то скорее всего используют LaTeX (где-то достаточно и Markdown). Так что здесь нет никакой проблемы с удобством.
Плюсанул, но на мой взгляд статья слабовата. По этому поводу написано множество хороших книг, да и на Хабре аналогичных материалов предостаточно. Но посмотрим, что будет дальше.
Да пусть даже код какой-нибудь реализации стандартной библиотеки C++ в котором чёрт ногу сломит. В тоже время с кодом движка DOOM 3, написанном по большому счёту на «Си с классами» нет никаких проблем.
Но вообще, это всё крайности и вкусовщина. Главное, что-бы удобно было лично вам и тем с кем вы работаете.
В дополнение к Antervis и iCpu я лишь могу добавить, что код на Си ведёт себя именно так, как и должен — если программа написана неверно, то не стоит ожидать от неё решения ваших проблем.
Ну и нельзя обойтись без самого детского аргумента о том, что на Си пишут оперрационные системы и ничего, как-то работают.
И я не спорю с тем, что возможно Си не подходит именно под вашу задачу. Но вы говорите о преимуществе одинх языков над другими в целом, а это не выдерживает никакой критики.
Поэтому к Crypto API из юзерспейса можно обратиться через системные вызовы splice/vmsplice, это помогает избежать такого копирования. Подробнее смотрите здесь.
А вообще, возможно, вы подбросили мне идею для ещё одной статьи)
Да, я знаю о том, что gcc может обрезать такие вызовы и чем это черевато. Здесь, по хорошему, стоило занулить массив в простом цикле for, но я не стал этого делать, что бы не усложнять (пришлось бы объяснять почему gcc вырезает memset). Но упомянуть об этом безусловно стоило. В ближайшее время я постараюсь это исправить (или, вы можете предложить свою редакцию на github)
Насчёт второго — нет, я не забыл. Это преобразование избыточно, поскольку, в этом случае, void* автоматически и безопасно приводится к нужному типу. Литература по системному программированию в Linux также рекомендует (и обосновывает это) избегать явного приведения типов в таких случаях.
Достаточно и хидеров.
Спасибо за перевод.
Но вообще, это всё крайности и вкусовщина. Главное, что-бы удобно было лично вам и тем с кем вы работаете.
Затем, что:
при их злоупотреблении приводят к абсолютно нечитабельному коду.
Ну и нельзя обойтись без самого детского аргумента о том, что на Си пишут оперрационные системы и ничего, как-то работают.
И я не спорю с тем, что возможно Си не подходит именно под вашу задачу. Но вы говорите о преимуществе одинх языков над другими в целом, а это не выдерживает никакой критики.
Далеко не это приводит к «ошибкам в доступе к памяти».
А вообще, возможно, вы подбросили мне идею для ещё одной статьи)
memset_s, по крайней мере, точно есть в Visual Studio.
Проверил, при компиляции с -O3 "for" действительно вырезается.
Для Linux нашёл такой вариант надёжного мемсета:
Этот не вырезается даже на O3.
Да, я знаю о том, что gcc может обрезать такие вызовы и чем это черевато. Здесь, по хорошему, стоило занулить массив в простом цикле for, но я не стал этого делать, что бы не усложнять (пришлось бы объяснять почему gcc вырезает memset). Но упомянуть об этом безусловно стоило. В ближайшее время я постараюсь это исправить (или, вы можете предложить свою редакцию на github)
Насчёт второго — нет, я не забыл. Это преобразование избыточно, поскольку, в этом случае, void* автоматически и безопасно приводится к нужному типу. Литература по системному программированию в Linux также рекомендует (и обосновывает это) избегать явного приведения типов в таких случаях.