Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Проект LLVM развивает средства для безопасной работы с буферами в C++"	+/–
Сообщение от opennews (?), 06-Окт-22, 11:05
Разработчики проекта LLVM предложили ряд изменений, направленных на усиление безопасности критически важных проектов на языке C++ и предоставление средств для исключения ошибок, вызванных выходом за допустимые границы буферов. Работа сосредоточена в двух направлениях: предоставление  модели разработки, позволяющей безопасно работать с буферами, и проведение работы по усилению защиты стандартной библиотеки функций libc++... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57876
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

2. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
Сообщение от Аноним (2), 06-Окт-22, 11:07
> std::vector будет отслеживаться обращение за пределы выделенной области памяти, в случае выявления которого программа будет аварийно завершаться. Это ещё зачем, глупых растоманов наслушались? vector и так кидает экспешон при выходе за допустимый диапазон индексов.
Ответить | Правка | Наверх | Cообщить модератору

	3. "Проект LLVM развивает средства для безопасной работы с буфер..."	+12 +/–
	Сообщение от Аноним (3), 06-Окт-22, 11:08
	На этапе компиляции.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от bOOster (ok), 06-Окт-22, 13:05
	И после таких вот заявлений растоманы хотят кого-то уверить что у них код быстрее чем сишный работает? При наличии постоянных проверок в рантайме. Не смешите.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от анонимус (??), 06-Окт-22, 13:40
	Так проверки в дебаге. Код может быть местми быстрее из-за большего скоупа для анализа конпелятором. Синтетика иногда тоже такие результаты показывает. Тут главное что есть гарантии валидности
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Проект LLVM развивает средства для безопасной работы с буфер..."	–3 +/–
	Сообщение от Аноним (129), 06-Окт-22, 19:15
	> Так проверки в дебаге Когда индекс массива зависит от внешних данных (а это чуть менее, чем всегда), предлагаешь пользователям поставлять только дебаг-версии?!
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Tita_M (ok), 06-Окт-22, 19:59
	Comdiv, предлагает такое решение этой проблемы для будущих языков http://safe-prog-lang.blogspot.com/2016/12/correctness-state...
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Проект LLVM развивает средства для безопасной работы с буфер..."	–2 +/–
	Сообщение от bOOster (ok), 07-Окт-22, 08:10
	Костыль на костыле, костылем погоняет. А по факту - опыт и чуть больше внимательности.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Проект LLVM развивает средства для безопасной работы с буфер..."	+5 +/–
	Сообщение от Брат Анон (ok), 07-Окт-22, 08:34
	Понятно. Ответить нечего. Правда, там его вариант Оберона по скорости почти не проигрывает чистому Си. А надёжность растёт существенно. https://vostok-space.blogspot.com/2022/09/benchmark-.html#more
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Проект LLVM развивает средства для безопасной работы с буфер..."	–2 +/–
	Сообщение от bOOster (ok), 07-Окт-22, 09:23
	> Понятно. Ответить нечего. Правда, там его вариант Оберона по скорости почти не > проигрывает чистому Си. А надёжность растёт существенно. > https://vostok-space.blogspot.com/2022/09/benchmark-.html#more Где это в повседневной эксплуатации? Кнут тоже аналитику алгоритмов проводил - только по статистике худший случай на  реальных данных из жизни появляется практически в 2 раза чаще чем лучший. Та ерунда которая изучается в статье - #include <stdlib.h> int add(int a, int b) {   if (__builtin_sadd_overflow(a, b, &a)) {     abort();   }   return a; } Из той же оперы что и анализ алгоритмов Кнута. В реальной жизни все значительно хуже. Если бы "священный грааль" в программировании был найден - это бы в течении нескольких месяцев появилось в всех компиляторах да еще и нобелевскую премию дали. А так - очередное узкоспециализированное оправдание лодырей, которые не хотят проявлять внимание, и все ждут что за них все сделает КТО-ТО...
	Ответить | Правка | Наверх | Cообщить модератору

	227. "Проект LLVM развивает средства для безопасной работы с буфер..."	+3 +/–
	Сообщение от Прохожий (??), 08-Окт-22, 08:29
	У тебя с логическим мышлением явные проблемы. Причём здесь алгоритмы, до ошибок в программах?
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Проект LLVM развивает средства для безопасной работы с буфер..."	–4 +/–
	Сообщение от bOOster (ok), 07-Окт-22, 09:40
	> Понятно. Ответить нечего. Правда, там его вариант Оберона по скорости почти не > проигрывает чистому Си. А надёжность растёт существенно. > https://vostok-space.blogspot.com/2022/09/benchmark-.html#more Кстати, С++ в силу своей специфики конструктор/деструктор много безопаснее чем чистый С - так как заставляет вспомнить в каком месте нужно освободить выделенную память. И это глупость со стороны что Linux что BSD - не принимать в ядро модули на C++. Почему? потому что на MacOSX есть возможность писать kext на C++, а система стабильнее даже FreeBSD при том что FreeBSD обычно используется для постоянно-работающего определенного программного обеспечения (серверное применение) а вот MacOSX нет - пользователь может делать на нем что хочет, про Linux даже упоминать не стоит.
	Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

	255. "Проект LLVM развивает средства для безопасной работы с буфер..."	+3 +/–
	Сообщение от Брат Анон (ok), 10-Окт-22, 08:24
	> Кстати, С++ в силу своей специфики конструктор/деструктор много безопаснее чем чистый С Программист вообще не должен думать, когда бы ему память получить, а когда освободить. Ручное управление памятью -- зло.
	Ответить | Правка | Наверх | Cообщить модератору

	256. "Проект LLVM развивает средства для безопасной работы с буфер..."	–2 +/–
	Сообщение от bOOster (ok), 10-Окт-22, 09:32
	>> Кстати, С++ в силу своей специфики конструктор/деструктор много безопаснее чем чистый С > Программист вообще не должен думать, когда бы ему память получить, а когда > освободить. Ручное управление памятью -- зло. Вот это бреднятина, если ты работаешь в 1C, и всяким фронтендом тогда да, но это не программисты - это ремесленники. Но если ты работаешь с ядром операционки или разрабатываешь библиотеки низкого уровня для ремесленников - тогда нет. Программист таких вещей четко должен понимать что и где выделять и удалять.
	Ответить | Правка | Наверх | Cообщить модератору

	262. "Проект LLVM развивает средства для безопасной работы с буфер..."	–2 +/–
	Сообщение от Аноним (-), 12-Окт-22, 12:47
	> Программист вообще не должен думать, когда бы ему память получить, а когда > освободить. Ручное управление памятью -- зло. И ножи запретить, ими же порезаться можно.
	Ответить | Правка | К родителю #255 | Наверх | Cообщить модератору

	80. "Проект LLVM развивает средства для безопасной работы с буфер..."	+4 +/–
	Сообщение от YetAnotherOnanym (ok), 06-Окт-22, 15:03
	Лучше постоянные проверки в рантайме, чем крвх или взлом.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	88. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от bOOster (ok), 06-Окт-22, 15:55
	> Лучше постоянные проверки в рантайме, чем крвх или взлом. Насмешил - имхо rust будут ломать чаще.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Аноним (123), 06-Окт-22, 17:47
	Он для этого и создан если кто не понял. Притянул из интернета пару гигабайт зависимостей для сборки и вуаля. А синтаксис и уровень программистов как-раз распологает к быстрому и незатруднительному ознакомлению со сторонним кодом. Для дураков безопасТно вобщем, в лучших традициях стадостроения.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Проект LLVM развивает средства для безопасной работы с буфер..."	+4 +/–
	Сообщение от Аноним (130), 06-Окт-22, 19:19
	>Притянул из интернета пару гигабайт зависимостей для сборки и вуаля Можно притянуть локально. Кто мешает? >Для дураков безопасТно вобщем, в лучших традициях стадостроения. А мне кажется, что у вас приступ "НИНУЖНА", ибо в плюсах нет нормального менеджера, а значит и у других не должно быть.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от bOOster (ok), 07-Окт-22, 08:23
	>>Притянул из интернета пару гигабайт зависимостей для сборки и вуаля > Можно притянуть локально. Кто мешает? >>Для дураков безопасТно вобщем, в лучших традициях стадостроения. > А мне кажется, что у вас приступ "НИНУЖНА", ибо в плюсах нет > нормального менеджера, а значит и у других не должно быть. Ты давно из исходников собирал что-то, изучая перед этим код - дабы быть уверенным в том что бинарный код соответствует исходному коду? Дай догадаюсь - никогда.. А поэтому и локальный твой код - так же был КОГДА-ТО притянут из интернета.
	Ответить | Правка | Наверх | Cообщить модератору

	212. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (212), 07-Окт-22, 16:32
	Даже если это так, то какая претензия тогда к расту? Скачав библиотеку для крестов с гитхаба тоже можно получить уязвимость.
	Ответить | Правка | Наверх | Cообщить модератору

	215. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от bOOster (ok), 07-Окт-22, 16:57
	> Даже если это так, то какая претензия тогда к расту? Скачав библиотеку > для крестов с гитхаба тоже можно получить уязвимость. Да дело в том что раст ремесленники сродни 1С программистам - зачастую не знают что такое бинарный поиск.
	Ответить | Правка | Наверх | Cообщить модератору

	229. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Прохожий (??), 08-Окт-22, 08:33
	Исходя из чего это следует, о Великий воин супротив Раста?
	Ответить | Правка | Наверх | Cообщить модератору

	228. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Прохожий (??), 08-Окт-22, 08:30
	На основе чего ты пришёл к такому туповатому выводу?
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	133. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от eganru (?), 06-Окт-22, 19:52
	К большому сожалению будут постоянные ошибки в алгоримах, которые точно также приводят к печальным последствиям. В реальном мире жестко заданная учетка встречается чаще чем переполнение буфера. А что методы для проверки в рантайме добавили - ничего плохого в этом нет. Хочешь попроще? - пишешь с проверками.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	138. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Аноним (130), 06-Окт-22, 20:17
	>В реальном мире жестко заданная учетка встречается чаще чем переполнение буфера. А можно какие-нибудь цифры или исследования? Просто анализ от Майкрософта показал, что около 70% уязвимостей происходят из-за проблем с памятью, в том числе и с переполнением буфера.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от bOOster (ok), 07-Окт-22, 08:12
	Майкрософт это не про программирование - это про бизнес. И применять эти сведения к open-source программированию вообще никак нельзя.
	Ответить | Правка | Наверх | Cообщить модератору

	213. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (212), 07-Окт-22, 16:35
	А в open source какие-то особенные люди, которые не допускают ошибок с памятью и при этом отказываются работать с корпорациями? Я бы наоборот допустил, что средний корпоративный разработчик пишет код лучше среднего open source разработчика.
	Ответить | Правка | Наверх | Cообщить модератору

	214. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от bOOster (ok), 07-Окт-22, 16:49
	> А в open source какие-то особенные люди, которые не допускают ошибок с > памятью и при этом отказываются работать с корпорациями? Я бы наоборот > допустил, что средний корпоративный разработчик пишет код лучше среднего open source > разработчика. А серое вещество включить? Или на Майкрософт работаешь? Open source - майнтейнер и пользователи проекта заинтересованы в надежной работе решения, а не выкинуть в его в срок... "А дальше поправим"
	Ответить | Правка | Наверх | Cообщить модератору

	226. "Проект LLVM развивает средства для безопасной работы с буфер..."	–2 +/–
	Сообщение от Прохожий (??), 08-Окт-22, 08:26
	Тебе бы самому не помешало включать серое вещество. Что МС, что другие корпорации гораздо сильнее заинтересованы в качестве продукта (конкуренция, батенька, она такая: будешь делать шлак - клиенты разбегутся), чем программисты опенсоурса, у которых, если подумать, нет абсолютно никакой мотивации, чтобы писать качественный код, кроме чувства собственной важности (ЧСВ). Пользователи опенсорса часто банальные халявщики, и даже если они заинтересованы в качестве, то редко готовы его поддерживать денежкой. А одним ЧСВ (типовой программист опенсорса) долго сыт не будешь.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Брат Анон (ok), 07-Окт-22, 08:38
	> Лучше постоянные проверки в рантайме, чем крвх или взлом. А ещё лучше -- железо спроектированное под эти проверки, и язык, который на 146% использует эти проверки. Например, Оберон.
	Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

	263. "Проект LLVM развивает средства для безопасной работы с буфер..."	–2 +/–
	Сообщение от Аноним (-), 12-Окт-22, 14:20
	> А ещё лучше -- железо спроектированное под эти проверки, Осталось придумать где его такое взять. Интел вообще пытался, но - не зашло. > и язык, который на 146% использует эти проверки. Например, Оберон. Rust с другого бока зашел, ему особое железо толком и не надо, просто компил тайм проверки всего чего можно да разумная аннотация намерений кодера. В целом достаточно разумное сочетание. Синтаксис конечно с закорючками но тут уж аннотация намерений програмера компилеру и анализатору либо есть либо нет.
	Ответить | Правка | Наверх | Cообщить модератору

	278. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Брат Анон (ok), 14-Окт-22, 08:28
	>> А ещё лучше -- железо спроектированное под эти проверки, > Осталось придумать где его такое взять. Интел вообще пытался, но - не > зашло. Нет, Интел даже не пытался. За тебя уже всё придумали. Просто бери и пользуйся. >> и язык, который на 146% использует эти проверки. Например, Оберон. > Rust с другого бока зашел, ему особое железо толком и не надо, Нет. Нет железа под язык. Значит нет никакой безопасности. > просто компил тайм проверки всего чего можно да разумная аннотация намерений > кодера. Нет. Если железо кривое -- это всё для самоуспокоения. От Мельтдауна никакой раст не спасёт. Даже Оберон бесполезен. > В целом достаточно разумное сочетание. Синтаксис конечно с закорючками но > тут уж аннотация намерений програмера компилеру и анализатору либо есть либо > нет. Нет. Вырвиглазный синтаксис помноженный на штатную возможность перехода с алгоритмического уровня на аппаратный. Оставьте себе.
	Ответить | Правка | Наверх | Cообщить модератору

	279. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от alexhz (?), 26-Дек-22, 00:38
	Железо такое есть, эльбрус называется. Там есть специальный режим, в котором процессор изображает из себя виртуальную машину, работающую по спецификации языка C. Прощай выход за границы буферов, приведение несовместимых типов и прочее-прочее. Недостаток - даже в железном исполнении есть потеря производительности, местами более 40%.
	Ответить | Правка | К родителю #263 | Наверх | Cообщить модератору

	280. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от alexhz (?), 26-Дек-22, 00:43
	Хотя чаще до 20%. Ну и ещё проблема, код с хаками не работает. В итоге, только сравнительно недавно смогли заставить в этом режиме работать стандартную GNU libc.
	Ответить | Правка | Наверх | Cообщить модератору

	221. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от anonimous (?), 07-Окт-22, 22:18
	>vector >На этапе компиляции. std::vector<T,Allocator>::at Returns a reference to the element at specified location pos , with bounds checking.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	4. "Проект LLVM развивает средства для безопасной работы с буфер..."	+4 +/–
	Сообщение от topin89 (ok), 06-Окт-22, 11:10
	Только по `.at(i)`, и этой функцией мало кто пользуется.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	6. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от null (??), 06-Окт-22, 11:14
	а вы берете указатель от .data() и дальше используете арифметику с указателем?
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Проект LLVM развивает средства для безопасной работы с буфер..."	+12 +/–
	Сообщение от anonymous (??), 06-Окт-22, 11:20
	operator[] вам о чем-нибудь говорит?
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от null (??), 06-Окт-22, 11:24
	зачем, если есть at?
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Проект LLVM развивает средства для безопасной работы с буфер..."	+13 +/–
	Сообщение от Аноним (19), 06-Окт-22, 11:38
	зачем нужен ты, если есть GPT-3?
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от trolleybus (?), 06-Окт-22, 12:41
	Согласен. Null не нужен, столько багов из-за него.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (84), 06-Окт-22, 15:41
	Давайте разыминуем анона выше !
	Ответить | Правка | Наверх | Cообщить модератору

	264. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (-), 12-Окт-22, 14:41
	> Давайте разыминуем анона выше ! Зачем тебе разыменованный троллейбус?! И что это делает?
	Ответить | Правка | Наверх | Cообщить модератору

5. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
Сообщение от pashev.ru (?), 06-Окт-22, 11:13
Gfortran: -fcheck=all
Ответить | Правка | Наверх | Cообщить модератору

	128. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от qetuo (?), 06-Окт-22, 18:55
	Собственно, уже давно есть GLIBCXX_HARDENED, по умолчанию включенный в Федоре и ряде других дистров. Добавляет примерно то, о чем новость для libc++.
	Ответить | Правка | Наверх | Cообщить модератору

7. "Проект LLVM развивает средства для безопасной работы с буфер..."	–2 +/–
Сообщение от Бывалый смузихлёб (?), 06-Окт-22, 11:14
> Предлагаемая модель безопасного программирования для C++ предполагает   > использование предоставляемых стандартной библиотекой классов > при работе с буферами вместо манипуляций с голыми указателями. > Например, предлагается использовать классы std::array, std::vector и std::span, > в которые будет добавлена проверка выхода за границы выделенной памяти, > производимая во время выполнения Одна небольшая доработка, а целый ЯП, придуманный только для безопасной работы с памятью, уже может лететь на помойку
Ответить | Правка | Наверх | Cообщить модератору

	9. "Проект LLVM развивает средства для безопасной работы с буфер..."	+6 +/–
	Сообщение от гость (?), 06-Окт-22, 11:22
	А что, LLVM в кресты встраивают борроу чекер? Проблем с лайфтаймами больше не будет?
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (18), 06-Окт-22, 11:37
	Если тебе нужен боров в чекере ты его можешь сам присобачить в любой момент. https://www.youtube.com/watch?v=Lj1GppqNr8c
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от анон (?), 06-Окт-22, 14:56
	Ща начнется визг, что ваш 6Ч, не тот бЧ.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Проект LLVM развивает средства для безопасной работы с буфер..."	+4 +/–
	Сообщение от Аноним (40), 06-Окт-22, 12:38
	> боров чекер Давно есть, std::unique_ptr называется.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	11. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Шарп (ok), 06-Окт-22, 11:23
	>производимая во время выполнения Закатывай губу назад.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	30. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Man11300 (?), 06-Окт-22, 12:14
	В том языке аналогичная проверка тоже происходит во время выполнения
	Ответить | Правка | Наверх | Cообщить модератору

10. "Проект LLVM развивает средства для безопасной работы с буфер..."	+7 +/–
Сообщение от Аноним (10), 06-Окт-22, 11:23
Будет короче тормозить еще больше из за постоянных проверок. Голые указатели придумали не просто так. А потому, что проги на асме работали в 10 раз быстрее, чем всякие проги на басике, но хотелось же писать на ЯВУ, а не убивать мозг проблемами аллокешена регистров. Есть простая и тупая вещь. В других языках типа Delphi/Lazarus можно включить проверку границ в отладочном режиме. Есть так же клевые менеджеры памяти типа FastMM, которые в FullDebugMode отслеживают все возможные проблемы с утечками памяти и use-after-free. Это просто Сишники привыкли страдать. А еще говорят, что их язык лучший в мире, ога.
Ответить | Правка | Наверх | Cообщить модератору

	16. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Анусимус (?), 06-Окт-22, 11:37
	сиплюсплюсовцы же
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (10), 06-Окт-22, 11:49
	А еще ассерты есть. И вообще работать с буфферами неявного размера, как это принято в Сях - это плохая идея. Короче это называется культура программирования. Если нанимать индусов на аутсорсе за копейки, то никакие ухищрения не помогут. А в итоге ради так называемой безопасности производительность нативного кода опустят до уровня скряптов. Ну и зачем тогда вообще нужен нативный код? Давайте всех посадим на питон.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Проект LLVM развивает средства для безопасной работы с буфер..."	+3 +/–
	Сообщение от Аноним (23), 06-Окт-22, 11:54
	C и C++ это разные языки.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (129), 06-Окт-22, 19:20
	Не может быть!
	Ответить | Правка | Наверх | Cообщить модератору

	265. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (265), 12-Окт-22, 14:52
	> А еще ассерты есть. И вообще работать с буфферами неявного размера, как > это принято в Сях - это плохая идея. Си разный бывает. В каком-нибудь MISRA например много чего НЕ принято. И это как бы си но как бы здорово другой по надежности если на эти правила не забивать. Всякие void* - ой, вы не указали намерения, как это проверять? Статический анализ в пролете. Туда же массивы неизвестного размера и прочий хлам, где намерения не декларированы. Математика над указателями это вообще зло. Реально легитимных причин это делать есть минимум, типа реализации своего memcpy() или декомпрессора какого. В более приземленном коде это намекает что кодер занимается чем-то не тем. Особенно если в выражение входят разные указатели, нормальные анализаторы на это жутко воют и правильно делают. А если все типизировать нормально - вообще и на сях нормально можно. Чертова куча этого летает в космос, рулит критичными процессами, и в целом факапов можно избежать. Если задаться такой целью. Нет там никаких серебряных пуль, для этого надо всю методологию разработки софта с прицелом под это делать, комплексно. Это назойливо, но вполне эффективно. Если раздолбаить, никакой раст не спасет. И для него эти методологии вообще пока толком не написаны, только-только появляется первое понимание его проблем вообще.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	25. "Проект LLVM развивает средства для безопасной работы с буфер..."	+3 +/–
	Сообщение от _kp (ok), 06-Окт-22, 12:03
	Проверка диапазона не ресурсоёмкая, и на некоторых платформах даже аппаратная. Возможность писать особо быстрый код ни куда не исчезает. Но и у системных программистов не во всяком месте нужен особо быстрый код, в ущерб безопасности или времени его написания. Просто по умолчанию предлагается чуть более безопасный подход.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	67. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от none7 (ok), 06-Окт-22, 14:30
	Не бывает бесплатных проверок, даже за защищённый режим процессора с его виртуальной памятью приходится платить свою цену, реальный режим реально быстрее. У x86 так же есть инструкция bound для проверки соответствия указателя определённому диапазону, но естественно времени она занимает столько же как и пара cmp+j[ab], хотя реализована аппаратнее некуда. Проверки данных по одной границе при изменении оказались дешевле и инструкцию выбросили на свалку истории. Дешевле одной проверки только отсутствие проверки во время выполнения, например мы можем быть уверены, что в результате операции i & 255, i не выйдет за пределы массива длиной 256 байт. Компиляторы Rust и Ada вроде как специализируются на обеспечении таких гарантий и должны бы быть быстрее компиляторов Си... должны бы быть. Проверки это вещь столь бесплатная, что у gcc даже есть флаг -funroll-loops, который разворачивает циклы так, чтобы уменьшить число проверок.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Проект LLVM развивает средства для безопасной работы с буфер..."	–3 +/–
	Сообщение от n00by (ok), 06-Окт-22, 14:52
	> даже за защищённый режим процессора с его виртуальной > памятью приходится платить свою цену, реальный режим реально быстрее. Столько нового и интересного узнаёшь на Опеннете. То есть виртуальная память иногда медленнее, поскольку её размер больше физической и страницы иногда гоняются на медленный накопитель и обратно? На самом деле, в этом случае система работает быстрее - потому что в реальном режиме она бы вообще не работала из-за нехватки памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от none7 (ok), 06-Окт-22, 15:03
	> Столько нового и интересного узнаёшь на Опеннете. То есть виртуальная память иногда > медленнее, поскольку её размер меньше физической и страницы иногда гоняются на > медленный накопитель и обратно? На самом деле, в этом случая система > работает быстрее - потому что в реальном режиме она бы вообще > не работала из-за нехватки памяти. Нет, процессору же приходится гонять виртуальные адреса через таблицу страниц для превращения их в реальные адреса. Или для броска исключения при выходе за пределы зарегистрированных ядром ОС страниц или при неправомерном доступе к ним. Теоретически в процессоре есть блок предназначенный для параллельного сравнения адреса с адресами страниц, только вот блок этот не безразмерный. В нём лежат только страницы к которым обращались недавно. В случае остальных, процессору приходится копаться в огромной таблице в оперативной памяти, а это ой как не быстро.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 06-Окт-22, 16:21
	Исключение потому так и называется, что генерируется в исключительных случаях. Так то да, если запретить ещё и прерывания, то система будет работать «быстрее», не прерываясь на чтение с накопителя и приём пакетов. А если обрабатывать только 64 байта, то не придётся читать из медленного ОЗУ, поскольку хватит линейки кеша. Только почему-то мало кому приходит в голову «оптимизировать» всё это.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (102), 06-Окт-22, 16:34
	> Так то да, если запретить ещё и прерывания, то система будет работать «быстрее», > не прерываясь на чтение с накопителя и приём пакетов. Вот кстати в голодные времена провайдеры вместо Cisco использовали ПК с Linux и отключали прерывания, чтобы увеличить число пакетов перевариваемых роутером за секунду. > А если обрабатывать только 64 байта, то не придётся читать из медленного ОЗУ, > поскольку хватит линейки кеша. Только почему-то мало кому приходит в голову > «оптимизировать» всё это. Те кто воюют за оптимизацию работы процессорного кеша в природе водятся это факт. К сожалению немногим программистам вообще в голову приходит мысль хоть как-то оптимизировать свои программы. Компилятор сам по их мнению справится, а код они пишут для людей, а не машин.
	Ответить | Правка | Наверх | Cообщить модератору

	241. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 08-Окт-22, 16:01
	>> Так то да, если запретить ещё и прерывания, то система будет работать «быстрее», >> не прерываясь на чтение с накопителя и приём пакетов. > Вот кстати в голодные времена провайдеры вместо Cisco использовали ПК с Linux > и отключали прерывания, чтобы увеличить число пакетов перевариваемых роутером за секунду. Осталось написать дату тех времён и характеристики железа - что бы можно было прикинуть, насколько сейчас сократились потери. >> А если обрабатывать только 64 байта, то не придётся читать из медленного ОЗУ, >> поскольку хватит линейки кеша. Только почему-то мало кому приходит в голову >> «оптимизировать» всё это. > Те кто воюют за оптимизацию работы процессорного кеша в природе водятся это > факт. Вот пусть такой человек со мной и спорит. Пока господа теоретики даже не смогли обнаружить, что у меня на гатхабе опубликованы результаты таких оптимизаций, как раз из-за чуть более оптимального использования кеша мой интерпретатор обгоняет скомпилированный код: Интерпретация:     $ time echo 5 | refal lambda.ref     Enter a number:     120     real    2m47,046s     user    2m46,415s     sys     0m0,014s Скомпилировано Рефал-05     $ time echo 5 | ./lambda-05     Enter a number:     120     real    3m32,260s     user    3m30,360s     sys     0m1,193s Это на исходнике, который не я писал. На моём и в 5 раз быстрее получилось. > К сожалению немногим программистам вообще в голову приходит мысль хоть как-то оптимизировать > свои программы. Компилятор сам по их мнению справится, а код они пишут > для людей, а не машин. Как раз быстрый код пишется для людей, Кнут вон несколько талмудов написал.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 06-Окт-22, 15:00
	> У x86 > так же есть инструкция bound для проверки соответствия указателя определённому диапазону, > но естественно времени она занимает столько же как и пара cmp+j[ab], > хотя реализована аппаратнее некуда. А если посмотреть талмуд, то она делает совсем другое - генерирует исключение #BR — BOUND Range Exceeded. Время её выполнения, надо полагать, Вы дадите в ответе на моё сообщение?
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	81. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от none7 (ok), 06-Окт-22, 15:06
	> А если посмотреть талмуд, то она делает совсем другое - генерирует исключение > #BR — BOUND Range Exceeded. Время её выполнения, надо полагать, Вы > дадите в ответе на моё сообщение? Она даёт исключение при выходе за границы проверки, а не всегда.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от n00by (ok), 06-Окт-22, 16:14
	Что бы «естественно времени она занимает столько же как и пара cmp+j[ab]» имело силу, хорошо бы написать времена для обоих случаев. А эти команды даже делают разное.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (102), 06-Окт-22, 16:25
	> Что бы «естественно времени она занимает столько же как и пара cmp+j[ab]» > имело силу, хорошо бы написать времена для обоих случаев. А эти > команды даже делают разное. Естественно ситуация выхода за пределы массива является серьёзной ошибкой и не так уж и важно сколько времени уйдёт на её обработку. В худшем случае она даже может привести к завершению программы. Так, что сравнивать нужно ситуации когда выхода за пределы массива нет.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от n00by (ok), 06-Окт-22, 16:33
	> Так, что сравнивать > нужно ситуации когда выхода за пределы массива нет. Так для этого надо найти старый тадмуд, где указано время исполнения BOUND. Я смутно припоминаю, что она дико медленная, как и все сложные инструкции. Но не я делал заявление на тему «естественно столько же», так что тут есть кому искать тот талмуд. :)
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Аноним (102), 06-Окт-22, 16:42
	> Но не я делал заявление на тему «естественно столько же», > так что тут есть кому искать тот талмуд. :) Этот талмуд идёт в комплекте с masm32 и он у меня под рукой bound - 7 тактов на 486 cmp reg, mem - 2 такта Jxx при пропуске прыжка - 1 такт Ой, bound даже немного медленнее.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (129), 07-Окт-22, 02:37
	> на 486 Сейчас какой год идёт? Не, не так... Какой сейчас век?
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от none7 (ok), 07-Окт-22, 04:18
	> Сейчас какой год идёт? Не, не так... Какой сейчас век? Да без разницы какой год. Основа вычислительного блока в процессорах Intel не меняется. Просто самих блоков стало больше и в местах где можно параллелить инструкции, процессор параллелит. Хотя да, цепочку cmp, ja, cmp, jb можно за счёт спекулятивного выполнения ужать до тактов cmp, ja, если перехода по Jxx не будет. Но вот если будет, то процессор неизвестное количество тактов потратит на откат состояния.
	Ответить | Правка | Наверх | Cообщить модератору

	242. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 08-Окт-22, 16:05
	>> Сейчас какой год идёт? Не, не так... Какой сейчас век? > Да без разницы какой год. Основа вычислительного блока в процессорах Intel не > меняется. Просто самих блоков стало больше и в местах где можно > параллелить инструкции, процессор параллелит. Хотя да, цепочку cmp, ja, cmp, jb > можно за счёт спекулятивного выполнения ужать до тактов cmp, ja, если > перехода по Jxx не будет. Но вот если будет, то процессор > неизвестное количество тактов потратит на откат состояния. Откат будет, внезапно, в случае ошибки в программе! Что Вы там собрались оптимизировать при выходе за пределы буфера?
	Ответить | Правка | Наверх | Cообщить модератору

	269. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (-), 12-Окт-22, 15:46
	> Да без разницы какой год. Основа вычислительного блока в процессорах Intel не меняется. Ага, конечно. Интел не настолько дно в разработках.
	Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

	274. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от none7 (ok), 12-Окт-22, 16:32
	> Ага, конечно. Интел не настолько дно в разработках. У них есть специальная инструкция rdtsc которой можно узнать, сколько тактов занимает та или иная инструкция или блок инструкций. Если работать только с регистрами или с кешем первого уровня, то число тактов на инструкцию совпадает с 486 процессором. Просто кеш стал больше, число ALU стало больше, а конвееры стали хитрее. Наоборот Intel создала RISC процессор под своим CISC процессором, чтобы разбить сложные инструкции на несколько маленьких и примитивных, что позволяет им чуть лучше гнать частоты, так как на нынешнем уровне скорость распространения электрического тока от тактового генератора и до конца каждой используемой инструкции, уже имеет значение. Хотя да, это можно считать за изменение, но число тактов не уменьшилось уж точно.
	Ответить | Правка | Наверх | Cообщить модератору

	275. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 13-Окт-22, 10:27
	>> Ага, конечно. Интел не настолько дно в разработках. > У них есть специальная инструкция rdtsc которой можно узнать, сколько тактов занимает > та или иная инструкция или блок инструкций. В действительности rdtsc читает time stamp counter, и есть нюанс: The RDTSC instruction is not a serializing instruction. It does not necessarily wait until all previous instructions have been executed before reading the counter. Similarly, subsequent instructions may begin execution before the read operation is performed. Время одной инструкции измерить невозможно. В лучшем случае была симуляции конвейера в AMD Code Analyst, но в актуальной uProf такой функциональности нет, как и в инструментах Intel. > Если работать только с > регистрами или с кешем первого уровня, то число тактов на инструкцию > совпадает с 486 процессором. Потрудитесь подтвердить цитатой официальной документации, или прекратите генерировать удивительные гипотезы.
	Ответить | Правка | К родителю #274 | Наверх | Cообщить модератору

	243. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 08-Окт-22, 16:23
	>> на 486 > Сейчас какой год идёт? Не, не так... Какой сейчас век? Да даже для того времени утверждение «времени она занимает столько же» -- неверно, сложите такты. :) А кто скажет «2+1 + 2+1 это почти 7» - тот пусть идёт читает Генри Уоррена младшего, главу 4.1.
	Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

	240. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 08-Окт-22, 15:51
	>> Но не я делал заявление на тему «естественно столько же», >> так что тут есть кому искать тот талмуд. :) > Этот талмуд идёт в комплекте с masm32 и он у меня под > рукой > bound - 7 тактов на 486 > cmp reg, mem - 2 такта > Jxx при пропуске прыжка - 1 такт Данные по cmp и Jxx неактуальны для современного железа. У cmp латентность 1, а пропускная способность 0,25 или 0,33. > Ой, bound даже немного медленнее. То есть согласно даже тем данным, в № 67 написана, мягко говоря, неправда, поскольку опирается на ложное утверждение: Не бывает бесплатных проверок, даже за защищённый режим процессора с его виртуальной памятью приходится платить свою цену, реальный режим реально быстрее. У x86 так же есть инструкция bound для проверки соответствия указателя определённому диапазону, но естественно ***времени она занимает столько же как и пара cmp+j[ab]***, хотя реализована аппаратнее некуда.
	Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

	89. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (89), 06-Окт-22, 15:56
	В защищенном режиме много всякой мути, которая в теории должна жутко тормозить. Виртуальная память, переключение контекстов и т.д. В современных процах все это решается за счет распараллеливания. Т.е. проблему по сути закидывают шапками. Это когда тебе тех процесс позволяет клепать сколько угодно транзисторов, так что можно параллельно просчитывать 100500 инструкций вперед при over9000 ветвлениях. Другое дело, что расплатой за это является возможность атак по сторонним каналам. Так что, как сказал Мэт Дэймон, да, да...
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	98. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (98), 06-Окт-22, 16:29
	Так чтож, теперь отказаться от защищённого режима? Привет, эпоха DOS! Сторонние каналы не требуются, получай достпуп к любым соседним процессам сколько хочешь!
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от n00by (ok), 06-Окт-22, 16:35
	> Привет, эпоха DOS! Сторонние каналы > не требуются, получай достпуп к любым соседним процессам сколько хочешь! И правда, быстрее же. =)
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Tita_M (ok), 06-Окт-22, 20:08
	Существует архитектура Mill в которой нет виртуальной памяти и много чего другого, что есть в классических процессорах усложняющих их и тем не менее многие FLOSS программы и операционки корректно работают на ней после компиляции и  практически без изменений.
	Ответить | Правка | Наверх | Cообщить модератору

	218. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (218), 07-Окт-22, 18:11
	Но в реальном мире, кроме FOSS, ещё браузер загружает страницы с тоннами стороннего JS, которому наплевать на корректное сосуществование с другими просессами в архитектуре без виртуальной памяти.
	Ответить | Правка | Наверх | Cообщить модератору

	272. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (-), 12-Окт-22, 16:10
	> Но в реальном мире, кроме FOSS, ещё браузер загружает страницы с тоннами > стороннего JS, которому наплевать на корректное сосуществование с другими просессами в > архитектуре без виртуальной памяти. И при всем этом там приколы типа ROWHAMMER могут работать. Даже оттуда. Который как оказалось даже в DDR4 все же вылезает в определенных условиях. Сюрприз!
	Ответить | Правка | Наверх | Cообщить модератору

	244. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 08-Окт-22, 16:33
	А ещё есть компьютер Спектрум. Самый быстрый там вариант - самомодифицирующийся код. Но реальный мир - это немного другое.
	Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

	270. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (-), 12-Окт-22, 15:47
	> А ещё есть компьютер Спектрум. Самый быстрый там вариант - самомодифицирующийся код. > Но реальный мир - это немного другое. В реальном мире вооон те игроделы бьют рекорды по скорости декомпресии vs плотность сжатия используя "data to code transformation". Из данных генерится код, это для их случая самый быстрый способ распаковки. Это нишевой случай но так можно было.
	Ответить | Правка | Наверх | Cообщить модератору

	276. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 13-Окт-22, 10:54
	Можно было, конечно, осталось посчитать, сколько играли в тот «Дум» на Спектруме и подумать, почему оно появилось сильно позже чем всякие Dyzzy и почему сорцы всех этих шедевров написаны под PC, который маст дай. ;)
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от _kp (ok), 07-Окт-22, 11:00
	> В защищенном режиме много всякой мути, которая в теории должна жутко тормозить. На счёт "жутко тормозить" это уже слишком безграмотно. Если писать эмулятор 386+, то конечно, софтовая эмуляция защищенного режима требует каких то ресурсов, но не много. А по сравнению с иными издержками, и вовсе не беспокоит. Даже в софтовом виде, без предсказаний и спекулятивных операций. Так же, "грамотно" написанное ПО не спасает никакой самый быстрый процессор. Примеры? Неповоротливые игры на Unity, числодроюильные алгоритмы на Питоне, извращения с компиляцией в Ардуино. Причем, тут и i10 10GHz принципиально не поможет. А проверки диапазонов, есть много где, и почему то, рейтинг тормозного ПО они не занимают. Про инструкцию bound сказано верно. Оптимизированный алгоритм, с учетом архитектуры, часто побеждает, то что предусмотрено разработчиками. Пристномамятная фича - в z80 добавили инструкцию копирования памяти, стало быстрее, чем на 8080, но с учетом специфики z80 применяли програмное копирование, ибо на 90%(!) быстрее работало, чем аппаратное. Это совсем разгромный пример, а с меньшей разницей в скорости, как грязи.
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	245. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от n00by (ok), 08-Окт-22, 16:40
	> Пристномамятная фича - в z80 добавили инструкцию копирования памяти, стало быстрее, чем > на 8080, но с учетом специфики z80 применяли програмное копирование, ибо > на 90%(!) быстрее работало, чем аппаратное. Ну про 90% Вы загнули. LDIR - 21 такт на 1 байт. LDI - 16. Серия последних немного выигрывала по скорости за счёт раздутия кода. Быстрое копирование, насколько помню, выполнялось сериями POP+PUSH - 10+11 на 2 байта. Где-то вдвое быстрее, без учёта дополнительных инструкций. Хотя, может я что-то забыл, да и вариант с генерацией 100 Кб кода для заполнения 6 Кб экрана не рассматриваю. Кстати, в IA32 с была похожая ситуация rep movs, но ныне она ускорена аппаратно с учётом нюансов работы с кешем.
	Ответить | Правка | Наверх | Cообщить модератору

	252. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от _kp (ok), 09-Окт-22, 00:23
	Верно. Вдвое быстрее, плюс издержки, это и есть примерно на 90% быстрее. Прирост зависит от размеров портянки из push/pop в реализации memcpy(). Больше 32..64 пар редкость. Про rep movs тоже в курсе. Я как коллекционер старого железа, сконен и что под них иногда написать, и эмуляторы пишу тоже. Удивлен грамотному комментарию, по столь экзотической теме.
	Ответить | Правка | Наверх | Cообщить модератору

	254. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от n00by (ok), 09-Окт-22, 15:58
	> Верно. > Вдвое быстрее, плюс издержки, это и есть примерно на 90% быстрее. Действительно. Как обычно, я налажал с арифметикой. > Прирост > зависит от размеров портянки из push/pop в реализации memcpy(). Больше 32..64 > пар редкость. > Про rep movs тоже в курсе. > Я как коллекционер старого железа, сконен и что под них иногда написать, > и эмуляторы пишу тоже. > Удивлен грамотному комментарию, по столь экзотической теме. Довелось когда-то покодить для Спека. Вот редактор обратно совместимый с SoundTracker https://github.com/STrusov/CPS Писался для демок, проигрыватель не самый быстрый, но более-менее стабильный по тактам. Про копирование помню немного, поскольку тогда мы искали пути скроллировать весь экран и перепробовали все комбинации, до каких докопались в чужом коде и додумались сами. В итоге удалось лишь хитростью.
	Ответить | Правка | Наверх | Cообщить модератору

	257. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от _kp (ok), 10-Окт-22, 10:46
	Благодарю. Взял в коллекцию. Смотрю. А на Гитхабе меня уже забанили, поэтому ссылками не делюсь.
	Ответить | Правка | Наверх | Cообщить модератору

	258. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 10-Окт-22, 16:34
	Как забанили? Это надо в новости. Тут публика любит, когда кого-то банят. Ну и вроде есть gitflic (что бы изменить там видимость репозитория, надо в службу поддержки написать, как говорят; я не пишу, просто год жду, вдруг заработает).
	Ответить | Правка | Наверх | Cообщить модератору

	259. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от _kp (ok), 11-Окт-22, 10:34
	> Как забанили? Это надо в новости. Уже писали про это. Хотя, банили якобы сотрудничавших с подсанкционными организациями, работавших из Крыма, и вроде как не очень много народу. Но, меня то за что? Даже не отвечают причину в отписках. А вообще, рукописи и репозитории не горят. А кучу чужих добавленных в лайки и форки проектов жалко.
	Ответить | Правка | Наверх | Cообщить модератору

	261. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 11-Окт-22, 14:41
	Если забанили на основании решения властей США - тогда им ничего не стоит указать это в причине (таким образом Микрософт как бы получаются невиновны). Не удивлюсь, что там была ещё опция «стукани на коллегу», и замешаны какие-то неадекваты. Во всяком случае, когда местная шаражка удалила мои репозитории, они точно так же не могли объяснить причину.
	Ответить | Правка | Наверх | Cообщить модератору

	266. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (-), 12-Окт-22, 15:05
	> Не бывает бесплатных проверок, Вообще в компилтайм они условно бесплатные. В том плане что это время потратит компилер 1 раз, при сборке, а не софт в рантайм. Проблема в том что в полном случае это решение нерешаемой задачи. Но в многих частных случаях это все же можно свести к доказуемым на автомате вещам. Что и дает возможность потрепыхаться на тему влезания на елку не обдирая зад.
	Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

	195. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от yet another anonymous (?), 07-Окт-22, 11:12
	> Проверка диапазона не ресурсоёмкая, и на некоторых платформах даже аппаратная. Звон-то конечно слышали, но откуда он, не разобрались. Заканчивайте уже тащить слухи про Рабиновича, выигравшего на бегах два миллиона.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

24. "Проект LLVM развивает средства для безопасной работы с буфер..."	+3 +/–
Сообщение от Аноним (24), 06-Окт-22, 12:02
что за буфера такие? массивы имелись ввиду?
Ответить | Правка | Наверх | Cообщить модератору

	29. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (98), 06-Окт-22, 12:12
	https://ru.wikipedia.org/wiki/Буфер
	Ответить | Правка | Наверх | Cообщить модератору

31. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
Сообщение от Аноним (31), 06-Окт-22, 12:16
В заголовке LLVM, а новость про clang. Непорядок.
Ответить | Правка | Наверх | Cообщить модератору

35. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
Сообщение от darkshvein (ok), 06-Окт-22, 12:24
почему бы сразу не писать на чистом Си?
Ответить | Правка | Наверх | Cообщить модератору

	37. "Проект LLVM развивает средства для безопасной работы с буфер..."	+3 +/–
	Сообщение от Аноним (37), 06-Окт-22, 12:29
	есть же чистый углерод
	Ответить | Правка | Наверх | Cообщить модератору

	267. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (-), 12-Окт-22, 15:06
	> есть же чистый углерод Он невкусный.
	Ответить | Правка | Наверх | Cообщить модератору

	45. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от bOOster (ok), 06-Окт-22, 13:02
	Зачем? Если например от C++ можно использовать только классы/структуры - и код получается более читаемым. И не лезть в шаблоны и иже с ними.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	47. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (37), 06-Окт-22, 13:05
	Вся мощь в шаблонах, а ты их не осилил :\
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Проект LLVM развивает средства для безопасной работы с буфер..."	–2 +/–
	Сообщение от bOOster (ok), 06-Окт-22, 13:08
	> Вся мощь в шаблонах, а ты их не осилил :\ Я их просто не использую. Если в большинстве случаев профессионалу хватает обычного C, то и шаблоны не нужны. Чем и пользуюсь. Но от C++ структур/классов не откажусь.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Аноним (61), 06-Окт-22, 13:43
	Сразу и видно, какой ты профессионал, раз шаблоны не осилил
	Ответить | Правка | Наверх | Cообщить модератору

	196. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от _kp (ok), 07-Окт-22, 11:13
	> Сразу и видно, какой ты профессионал, раз шаблоны не осилил Есть знакомые, которые пишут довольно небольшое ПО, ну скажем под встраиваемые устроства. Код у них на 95% тот же Си, но с небольшим количеством плюшек из С++. Ну и есть положительные особенности компилятора, который больше ругается на сомнительный код. В принципе, от неиспользования шаблонов  подобные и не потеряют ничего, им их часто и применить некуда. Но несмотря, что таки профессионалами в С++ их назвать нельзя, программистами они бывают вполне годными.
	Ответить | Правка | Наверх | Cообщить модератору

	248. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Neon (??), 08-Окт-22, 18:26
	Зато я много видел таких профессионалов любителей шаблонов, ваявших такую хрень, что никто потом не мог понять, как оно работает, даже сами авторы шедевров. С километровыми сообщениями об ошибках. Таких любителей шаблонов надо в детстве компов лишать.)))
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	249. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Neon (??), 08-Окт-22, 18:28
	Любители шаблонов обычно пишут совершенно неподдерживаемый код, который трудно отлаживать и сопровождать. Называется - горе от ума.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	51. "Проект LLVM развивает средства для безопасной работы с буфер..."	–5 +/–
	Сообщение от Аноним (40), 06-Окт-22, 13:15
	Как раз таки классы самое ненужное в цпп. Когнитивная нагрузка раза в 1.5 снижается, когда не нужно думать об иерархиях классов и связях между ними. Бессмысленная вещь, только отнимающая время.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	62. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Аноним (61), 06-Окт-22, 13:44
	Классы позволяют перегружать операторы например и писать vec1 + vec2 + vec3 вместо add_vec(add_vec(vec1, vec2), vec3). А ненужное - это твое никчемное мнение
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Проект LLVM развивает средства для безопасной работы с буфер..."	+4 +/–
	Сообщение от Аноним (-), 06-Окт-22, 14:08
	В нормальных языках пишут vec1.add(vec2).add(vec3) И редактор кода сможет указать где этот метод реализован, а не просто + какой-то
	Ответить | Правка | Наверх | Cообщить модератору

	154. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от ndshu (?), 06-Окт-22, 22:56
	У вас синтаксис подразумевает vec1 += vec2 + vec3 или vec1 + vec2 + vec3 ???
	Ответить | Правка | Наверх | Cообщить модератору

	273. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (-), 12-Окт-22, 16:12
	> У вас синтаксис подразумевает vec1 += vec2 + vec3 или vec1 + > vec2 + vec3 > ??? А у вас сложение не коммутативное чтоли? Когда оно именно так - это всяко отдельный случай требующий отдельного внимания.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Аноним (70), 06-Окт-22, 14:41
	Перегрузка операторов как раз самая отвратительная вещь в плюсах.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	72. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (98), 06-Окт-22, 14:51
	А ничё, что эта вещь не только в Плюсах имеется? Значит, востребована.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от _kp (ok), 07-Окт-22, 11:17
	> Перегрузка операторов как раз самая отвратительная вещь в плюсах. Это если применять куда попало, что бы было. А бывает, что и необходимо, и при этом ещё и изящно.
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	76. "Проект LLVM развивает средства для безопасной работы с буфер..."	–3 +/–
	Сообщение от Аноним (40), 06-Окт-22, 14:56
	Типичный ответ приплюснутой макаки. Ровный пацан для математики оптимизированный код на интрисинках напишет, а не вот это вот.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	250. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Neon (??), 08-Окт-22, 18:30
	Зато потом ровного пацана забивают лопатой, когда код нужно будет перенести на другую архитектуру процессора)))
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (98), 06-Окт-22, 14:49
	Я бы, наоборот, хотел бы найти утилитку, которая анализирует плоскосишный код и строит квази-UML диаграммы.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	190. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от bOOster (ok), 07-Окт-22, 10:28
	> Как раз таки классы самое ненужное в цпп. Когнитивная нагрузка раза в > 1.5 снижается, когда не нужно думать об иерархиях классов и связях > между ними. Бессмысленная вещь, только отнимающая время. А как-же конструкторы/деструкторы - которые, заставляя программиста возвращаться к написанию данных функций - четко понимают что где выделять и что где удалять? На порядок уменьшая количество ошибок с выделением/освобождением памяти и удалением нулевых поинтеров.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	253. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (253), 09-Окт-22, 04:05
	Классы очень полезны, когда они изолированы и не связаны с остальным кодом (как vector или string, илм complex и даже элементы графического интерфейса в какой-то степени). Когда классы проникают в ЛОГИКУ работы прогаммы (в какой-нибудь основной цикл приложения/потока/сервера tcp) - это очень и очень плохо. Нужно от такого избавляться!!! Вынуждает использовать всякие inversion of control (и прочую лабуду), как следствие - логика работы программы разбросана по нескольким разным модулям и работать с таким кодом становится невозможно.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	69. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (69), 06-Окт-22, 14:37
	Ну напиши, скажем, игровой движок на чистом Си. Кармак не просто так к третьему квейку сдался и перешёл на C++.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	75. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (75), 06-Окт-22, 14:56
	Ваще-то просто так.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Аноним (-), 06-Окт-22, 15:45
	просто так. и кармак живой пример что на си можно творить чудеса. досихпор фиг кто понимает его квадратичную ф-ю, не говоря о гениальности остальных решений. ты вообще кармака читал, дитё ? какие могут быть кресты с этим ООП уродством после божественного си кодинга.
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

	97. "Проект LLVM развивает средства для безопасной работы с буфер..."	+3 +/–
	Сообщение от Аноним (69), 06-Окт-22, 16:28
	Просто так, по доброй воле, на плюсы не переходят. Про быстрый обратный корень — вы серьёзно считаете, что Кармак его изобрёл?
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (98), 06-Окт-22, 16:39
	Ага, Кармак изобрёл разложение функции в ряд Тейлора :)
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (69), 06-Окт-22, 16:49
	Ну тут немного другая математика, но весьма тривиальная. Но дело не в этом, а в том, что компьютерная реализация уже давно существовала, Кармак лишь позаимствовал её (и комментарий даже оставил  — «Я ХЗ КАК, но оно работает»).
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (-), 06-Окт-22, 17:43
	Не важно. Поговаривают что комментанрий кстати не его (это про тот что рядом со сдвигом ?). Посмотрите другие файлики, это же гениально ! Но да, послушать тридстартера так перейдя на ООП все станут писать как Кармак. Ну что за бред.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (125), 06-Окт-22, 18:06
	А вообще, Анон, приятно видет что есть еще интересующиеся вопросом. Заходи на офтц в x86, по фану покодим фигню всякую
	Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

	144. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (69), 06-Окт-22, 21:11
	Увы, нет, фан кодинга в прошлом. Да и в прошлом гораздо интереснее был реверсинг, а кому это сейчас нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	246. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 08-Окт-22, 17:10
	Если речь про т.н. «аппаратный алгоритм», то описал его Джон Фон Нейман в First Draft of a Report on the EDVAC в 1945-м году.
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	230. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Онанистмус (?), 08-Окт-22, 13:11
	Кармак сказал что квадратичную функцию списал из какого то журнала по программированию графики а не придумал её. И он часто говорит что не придумывает алгоритмы а сводит воедино то что известно из чужих научных работ по алгоритмам.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	124. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Владимир (??), 06-Окт-22, 17:57
	Держи - https://www.youtube.com/watch?v=LR3THwlv_r4. Не закончено еще, но процесс идет. 663 серии по 2 часа, если осилишь.
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

	127. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (69), 06-Окт-22, 18:54
	И прямо в первом кадре видео — файлы .cpp. Ну ок.
	Ответить | Правка | Наверх | Cообщить модератору

	217. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Владимир (??), 07-Окт-22, 17:29
	> И прямо в первом кадре видео — файлы .cpp. Ну ок. Какой еще срр? Там фильм про любовь должен быть ... Или не та ссылка ...
	Ответить | Правка | Наверх | Cообщить модератору

	134. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от eganru (?), 06-Окт-22, 19:55
	По моему опыту на С++ быстрее писать.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	139. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Аноним (129), 06-Окт-22, 20:33
	> на С++ быстрее писать на С++ быстрее писать ошибки.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Cooler (??), 06-Окт-22, 21:51
	Можно увидеть вашу реализацию быстрой сортировки на чистом Си?
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	160. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (160), 07-Окт-22, 01:51
	Все есть на github
	Ответить | Правка | Наверх | Cообщить модератору

	238. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (238), 08-Окт-22, 15:23
	Современные программисты не могут в Си. Они способны максимум верстать медленные веб-страницы на java на фреймворках фреймворков
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

39. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
Сообщение от Аноним (39), 06-Окт-22, 12:35
>Например, предлагается использовать классы std::array, std::vector и std::span, в которые будет добавлена проверка выхода за границы выделенной памяти, производимая во время выполнения. Кому надо - тот давно их использует.
Ответить | Правка | Наверх | Cообщить модератору

49. "Проект LLVM развивает средства для безопасной работы с буфер..."	+6 +/–
Сообщение от Skullnet (ok), 06-Окт-22, 13:11
Тормозной C++ компилятор будет ещё тормознее.
Ответить | Правка | Наверх | Cообщить модератору

	86. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Аноним (-), 06-Окт-22, 15:47
	Ах, тормознутая сборка на крестах всегда вызывет боль.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Проект LLVM развивает средства для безопасной работы с буфер..."	–2 +/–
	Сообщение от Аноним (129), 06-Окт-22, 19:43
	Какой молоток - такой и Qt :)
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от darkshvein (ok), 06-Окт-22, 21:33
	вы не понимаете, это другое111 шланг всё исправит, и можно будет использовать много шаблонов 111
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	198. "Проект LLVM развивает средства для безопасной работы с буфер..."	–2 +/–
	Сообщение от Аноним (198), 07-Окт-22, 11:21
	Интересно, чего все так наяривают на скорость компиляции? Это вы так черезжoпно код пишете, что после каждой строки проверяет "сейчас скомпилилось? а сейчас? а сейчас?". Или вы из гентушников, для которых компилять это смысл существования? Какая разница сколько оно компилится? Вы делаете это один раз, а запускаете тысячи. И намного важнее насколько будет оптимизирован и быстр код полученный код.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	203. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (203), 07-Окт-22, 12:05
	Как бе дааа… Если ли бы ты написал хоть одну строчку кода в жизни, то знал бы, что без проверки узнать, работает ли всё так, как хотелось, невозможно. А ещё часто бывает доработка на месте, когда ты не знаешь, что нужно дописать, и собрать необходимую информацию можешь только после деплоя и запуска (а то и в несколько итераций, иногда только в проде). Ну и потом, если после каждого изменения ты не будешь проверять, то потом тебе придётся искать баги во всех изменениях и это немало работы, когда это может быть самая тривиальная опечатка. Поэтому доработка->деплой->тестирование это стандартный цикл при разработке софта. Кстати, оптимизированность и скорость не такое и высокое значение имеют, главное -- это способен ли код решать задачу, корректно ли он это делает, и насколько эффективно. Иногда это конечно приводит к печальным последствиям в виде чрезмерно завышенной ресурсоёмкости, но это всё профилируется и потом уже дорабатывается при возникновении такой проблемы, никто никогда в своём уме не будет об этом думать раньше времени.
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Проект LLVM развивает средства для безопасной работы с буфер..."	–2 +/–
	Сообщение от Аноним (198), 07-Окт-22, 12:58
	Ну так ты пишешь все что нужно проверить - функцию, класс, модуль, хз на чем ты пишешь - и один раз запускаешь компиляцию! Зачем ее дергать каждый раз? > А ещё часто бывает доработка на месте, когда ты не знаешь, что нужно дописать... Хе, вот тут у тебя проблема в компетенции или у проекта вообще. Вот тебе варианты: - Заглянул в доку и прочитал что нужно - Поставил breakpoint и посмотрел что нужно Ну а если ситуация "мне бекенд что-то должен ответить, но хз что..." то это проблема явно не компилятора. Тривиальные опечатки исправляются тривиально. А нетривиальные - покрываются тестами (напр. ты не ту переменную на вход послал и оно все скомпилилось) Плюс этот пример вообще не в тему - инкрементальная компиляция решает 99% таких ситуаций.
	Ответить | Правка | Наверх | Cообщить модератору

	260. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (260), 11-Окт-22, 10:56
	Проблема в компетенции тут у тебя. Просто ты манякодер, который не делал никогда, например, промышленные системы.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Аноним (198), 07-Окт-22, 13:03
	> оптимизированность и скорость не такое и высокое значение имеют, главное -- это способен ли код решать задачу, корректно ли он это делает Это абсолютно несвязанные задачи. Любой код должен решать поставленную задачу и делать это корректно, иначе это какой-то говнокoд. Если компилятор смог оптимизировать без твоей работы - это только плюс. > никто никогда в своём уме не будет об этом думать раньше времени Неправда. Ты всегда должен заранее оценивать сложность тех или иных алгоритмов, по имеющимся данным подбирать структуры данных и тд. То что в итоге что-то может быть не учтено - это да, но оставлять все на "а... потом профильну и исправлю" это бред.
	Ответить | Правка | К родителю #203 | Наверх | Cообщить модератору

	208. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (203), 07-Окт-22, 13:32
	Вот так выберешь быструю сортировку вместо сортировки пузырьком, а потом окажется, что пузырьком быстрее и эффективнее (в частности, для gpgpu). Можно делать только равновероятно неверные предположения. Если какой-то код постоянно бесцельно исполняется, то это конечно лишнее. Всё остальное можно узнать только при реальном применении на платформе (и после достаточного увеличения нагрузки). А вот тратить время на, вполне вероятно, бесцельные или ошибочные оптимизации, вот это максимально не эффективно.
	Ответить | Правка | Наверх | Cообщить модератору

60. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
Сообщение от Аноним (61), 06-Окт-22, 13:42
Легче оставить дебаг сборку
Ответить | Правка | Наверх | Cообщить модератору

	141. "Проект LLVM развивает средства для безопасной работы с буфер..."	–2 +/–
	Сообщение от Аноним (129), 06-Окт-22, 20:39
	Чтобы тормозило, как в расте?
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (168), 07-Окт-22, 02:59
	Всего лишь как в спарке.
	Ответить | Правка | Наверх | Cообщить модератору

65. "Проект LLVM развивает средства для безопасной работы с буфер..."	–9 +/–
Сообщение от Alexey Torgashin (?), 06-Окт-22, 14:25
Как только этого плешивого старичка не вытаскивают. И один тул напишут к нему. И другой. И третий. И все равно С++ отвратителен. Своим синтаксисом в первую очередь. Эти гении даже не додумались сделать keyword для функции. Блин.
Ответить | Правка | Наверх | Cообщить модератору

	68. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Аноним (70), 06-Окт-22, 14:36
	А зачем нужен keyword для функции? После пистоновских отступов теряетесь в коде?
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Tita_M (ok), 06-Окт-22, 20:17
	Как минимум это позволяет упростить компилятор. Н. Вирт не зря использовал procedure и function как минимум с паскаля. В Обероне вообще  только procedure осталась.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от U202204161753 (?), 06-Окт-22, 20:38
	Про вместо Function пишут PROCEDURE.   Функции остались ;-)
	Ответить | Правка | Наверх | Cообщить модератору

	169. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (168), 07-Окт-22, 03:01
	Про пишут procedure вместо view. А на функции даже смотреть нет смысла.
	Ответить | Правка | Наверх | Cообщить модератору

	247. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (247), 08-Окт-22, 17:58
	Так они же ненавидят паскаль и Вирта.
	Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

	251. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Neon (??), 08-Окт-22, 18:32
	В результате творения Вирта используют лишь для обучения. Для реальной работы его творения использовать невозможно. Задолбаешься элементарно постоянно писать procedure и function.
	Ответить | Правка | К родителю #137 | Наверх | Cообщить модератору

	151. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Alexey Torgashin (?), 06-Окт-22, 22:18
	1) Для выхватывания глазом функций. 2) для парсеров у всяких редакторов кода. Там УЖАС КАК СЛОЖНО СДЕЛАТЬ НАСТРОЙКУ ФУНКЦИЙ ДЛЯ С.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	167. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (168), 07-Окт-22, 02:57
	Вам гнутые подогнали целый компилятор, а вас парсеры не работают?
	Ответить | Правка | Наверх | Cообщить модератору

	271. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (-), 12-Окт-22, 16:06
	> 1) Для выхватывания глазом функций. 2) для парсеров у всяких редакторов кода. > Там УЖАС КАК СЛОЖНО СДЕЛАТЬ НАСТРОЙКУ ФУНКЦИЙ ДЛЯ С. Настолько сложно что компилер с сделали в 4 функицях, C4 называется.
	Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

	277. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от n00by (ok), 13-Окт-22, 10:59
	>> 1) Для выхватывания глазом функций. 2) для парсеров у всяких редакторов кода. >> Там УЖАС КАК СЛОЖНО СДЕЛАТЬ НАСТРОЙКУ ФУНКЦИЙ ДЛЯ С. > Настолько сложно что компилер с сделали в 4 функицях, C4 называется. Ну вот, сложно же. Для простых языков хватает одной.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Проект LLVM развивает средства для безопасной работы с буфер..."	+7 +/–
	Сообщение от ХрюХрю (?), 06-Окт-22, 14:59
	>:Как только этого плешивого старичка не вытаскивают. И один тул напишут к нему. И другой. И третий. >:И все равно С++ отвратителен. Своим синтаксисом в первую очередь. Эти гении даже не додумались сделать keyword для функции. Блин. Так в расте он еще отвратительней раза в 2))))
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

82. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
Сообщение от хрю (?), 06-Окт-22, 15:33
>>производимая во время выполнения. Шикарно! я считаю. Даже судя по тутошнему вою "медленно, медленно" прогеры станут ещё меньше использовать стандартные контейнеры в угоды указательной арифметике. Быстро же! Тем кому надо и так уже at() используют, а все остальные оптимизаторы убегут от этих рантайм проверок, так что багов меньше не будет. Разруха же не в языке. :D :D :D
Ответить | Правка | Наверх | Cообщить модератору

	87. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Аноним (-), 06-Окт-22, 15:50
	А где ? Если разработчикам надо знать все тонкости вроде не вызываем at() - там нет проверки, в стандарте ничего не сказано, но это же все знают.
	Ответить | Правка | Наверх | Cообщить модератору

90. Скрыто модератором	–3 +/–
Сообщение от РастаГангста (?), 06-Окт-22, 16:07
Плюсам уже ничего не поможет. Их скорый конец лишь дело времени. Раст уже просочился в ядро,  оттуда он просто уничтожит все нержавое. Трепещите,  друзья.
Ответить | Правка | Наверх | Cообщить модератору

	112. Скрыто модератором	+/–
	Сообщение от Аноним (98), 06-Окт-22, 16:58
	Ну придёт Carbon, фундаментально ничего не изменит. Лишь, синтаксис подрихтует.
	Ответить | Правка | Наверх | Cообщить модератору

	119. Скрыто модератором	+/–
	Сообщение от Аноним (98), 06-Окт-22, 17:26
	>Раст уже просочился в ядро,  оттуда он просто уничтожит все нержавое. Как бы он само ядро не уничтожил.
	Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

92. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
Сообщение от Аноним (92), 06-Окт-22, 16:12
Десятое правило Гринспена вас пожрёт.
Ответить | Правка | Наверх | Cообщить модератору

116. "Проект LLVM развивает средства для безопасной работы с буфер..."	+5 +/–
Сообщение от Чел на 939 сокете (?), 06-Окт-22, 17:11
Зачем оно нужно когда есть нативные компиляторы под любую платформу.
Ответить | Правка | Наверх | Cообщить модератору

	186. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (186), 07-Окт-22, 09:14
	Всегда так делаю. Исходный код тот же. Сборку делаю под конкретную платформу на ней же. Три компьютера рядом стоят.
	Ответить | Правка | Наверх | Cообщить модератору

	237. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (238), 08-Окт-22, 15:15
	Любой настоящий программист понимает что оно на самом деле бесполезно
	Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

142. "Проект LLVM развивает средства для безопасной работы с буфер..."	+6 +/–
Сообщение от Чел на 939 сокете (?), 06-Окт-22, 20:47
> исключения ошибок, вызванных выходом за допустимые границы буферов Совсем деградировали современные погромисты. Помню как в своё время на ассемблере в отладчике оптимизировал и экономил каждый такт, каждый байт.
Ответить | Правка | Наверх | Cообщить модератору

	143. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Аноним (69), 06-Окт-22, 21:09
	Никто не мешает вам и сейчас этим заниматься. Думаю, с руками такого специалиста оторвут, который полдня оптимизирует такт, а оставшиеся полдня байт.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (98), 06-Окт-22, 21:12
	Ага, а в Вилабаджио просто поставят 32-битный микроконтроллер и будут праздновать.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Аноним (129), 07-Окт-22, 02:29
	> и будут праздновать ...очередную дыру в проекте.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Проект LLVM развивает средства для безопасной работы с буфер..."	+2 +/–
	Сообщение от Чел на 939 сокете (?), 06-Окт-22, 21:31
	Я уже старый, мне 78, и давно на пенсии, все мои знания устарели, в мире "бизнесменов" и "маркетологов" не востребованы. Максимум с чем имел дело, так это 8086 процессор, 386 и выше уже не застал.
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	194. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Анонн (?), 07-Окт-22, 11:11
	А какой самый большой проект вы тогда писали? Не знаю какую метрику предложить, пусть будут LoC (ну или предложите свою) Поясню к чему это спрашиваю: Целое ядро линукса версии 1.0.0 содержало 176250 строк кода. Версии 5.11 - 30.34 миллионов строк вообще и из них около 14% само ядро, 60% - дрова. Т.е. "чистое ядро" - больше 4 млн. строк кода. Не задумывались ли вы что это не погромисты деградировали, а кодовая база стала настолько, что охватить ее взглядом не может практически никто, даже при мелком дроблении на проекты, подпроекты и тд? И чтобы хоть как-то заставить это работать приходится делать фреймворки, уровни абстраций и тд?
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Аноним (160), 07-Окт-22, 11:35
	Надо было делать микроядро. Тогда бы это был не один монолитный bloat на 30000000 строк, а 300 неблоатов по 100000
	Ответить | Правка | Наверх | Cообщить модератору

	202. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Аноним (218), 07-Окт-22, 12:00
	>Чел на 939 сокете >386 и выше уже не застал Лукавит дедуля
	Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

	204. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Аноним (198), 07-Окт-22, 12:07
	Так может он на 939 только в зуму и солитер играет.
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (186), 07-Окт-22, 09:17
	Тут недавно информация прошла. Одна команда что-то там изучала и упростила задачу со 100 тысяч уравнений до четырех (не тысяч - просто до 4-х). Считаете, они даром потратили время?
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	201. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (160), 07-Окт-22, 11:37
	Современным программистам не понять что такое оптимизировать каждый байт и каждый такт
	Ответить | Правка | Наверх | Cообщить модератору

	211. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (69), 07-Окт-22, 14:25
	Любой каприз за ваши деньги.
	Ответить | Правка | Наверх | Cообщить модератору

	236. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (238), 08-Окт-22, 15:13
	Любой настоящий программист в первую очередь думает об оптимизации
	Ответить | Правка | Наверх | Cообщить модератору

	216. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (69), 07-Окт-22, 17:15
	Они — нет, а оптимизатор байта — да.
	Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

	152. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (152), 06-Окт-22, 22:20
	Раньше время работы компьютера было дороже, чем время работы программиста, да и программы меньше.
	Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

	153. "Проект LLVM развивает средства для безопасной работы с буфер..."	+3 +/–
	Сообщение от Дональд Кнут (?), 06-Окт-22, 22:54
	Л - Логика, сынок а ты не думаешь что программы были меньше именно потому что все писали с "головой", а не качали кучу зависимостей и фреймворков чтобы вывести хеллоу ворд
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (157), 06-Окт-22, 23:10
	Л - Лениво думать.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (160), 07-Окт-22, 02:16
	Описание современных так называемых программистов
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Проект LLVM развивает средства для безопасной работы с буфер..."	+3 +/–
	Сообщение от Аноним (168), 07-Окт-22, 02:55
	Ну дык некогда думать, смузи ждёт.
	Ответить | Правка | Наверх | Cообщить модератору

	173. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Аноним (173), 07-Окт-22, 07:51
	любители смузи совсем разучились думать. думать могут только нелюбитили смузи с опеннет.
	Ответить | Правка | Наверх | Cообщить модератору

	205. "Проект LLVM развивает средства для безопасной работы с буфер..."	–2 +/–
	Сообщение от Аноним (69), 07-Окт-22, 12:57
	Программы были не только меньше, они были ПРОЩЕ. Не все современные программы ограничиваются «hello world», знаете ли.
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

	223. "Проект LLVM развивает средства для безопасной работы с буфер..."	+3 +/–
	Сообщение от Аноним (223), 08-Окт-22, 04:46
	Простота залог надёжности. Гуманитарии, палитесь же, сразу видно человек написавший это не имеет технического образования и соответствующего склада ума.
	Ответить | Правка | Наверх | Cообщить модератору

	235. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (238), 08-Окт-22, 15:11
	Что ещё ожидать от растоманов
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Проект LLVM развивает средства для безопасной работы с буфер..."	–2 +/–
	Сообщение от Аноним (173), 07-Окт-22, 07:49
	Что еще ожидать от современных диградирующих погромистов? Наизобретали всяких там rust, java и других скриптовых языков с проверками границ массива, а теперь и из С делают скриптовый язык. Позор! Настоящим экспертам-программистам с опеннет достаточно только нескритового С и ассемблера чтобы написать всё что угодно.
	Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

148. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
Сообщение от Аноним (148), 06-Окт-22, 21:36
Ввести массивы на уровне языка? Нееее, мы всё в рантайме проверять будем!
Ответить | Правка | Наверх | Cообщить модератору

	158. "Проект LLVM развивает средства для безопасной работы с буфер..."	–7 +/–
	Сообщение от Аноним (158), 06-Окт-22, 23:17
	Уточните пожалуйста что это за конструкция языка С++? int notArray[] = {1, 2, 3};
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Проект LLVM развивает средства для безопасной работы с буфер..."	+4 +/–
	Сообщение от Аноним (129), 07-Окт-22, 02:27
	Не поверишь... Это указатель с гранулярностью размера int.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Аноним (173), 07-Окт-22, 07:37
	#include <iostream> using namespace std; int main() {     int notArray[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};     int* pointer = notArray;     cout<<"not array size: "<<sizeof(notArray)<<endl<<"pointer size: "<<sizeof(pointer)<<endl;     return 0; } not array size: 40 pointer size: 8 Если [] указатель, то почему он такой большой?
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Аноним (173), 07-Окт-22, 08:13
	#include <iostream> using namespace std; int main() {     auto pointerAtNotArray = new int[15];     cout<<"not array size: "<<sizeof(*pointerAtNotArray)<<" :-("<<endl;     delete pointerAtNotArray;     return 0; } not array size: 4 :-(
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (173), 07-Окт-22, 08:16
	И это при том что размер массива сохраняется для оператора delete
	Ответить | Правка | Наверх | Cообщить модератору

	193. "Проект LLVM развивает средства для безопасной работы с буфер..."	+7 +/–
	Сообщение от 0x04070407 (?), 07-Окт-22, 11:09
	delete[], учитель
	Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

	184. "Проект LLVM развивает средства для безопасной работы с буфер..."	+33 +/–
	Сообщение от ХрюХрю (?), 07-Окт-22, 08:52
	int notArray[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; int* pointer = notArray; std::cout<<"not array size: " <<sizeof(notArray) << "\n"; // тут в sizeof передан адрес первого элемента массива и sizeof будет считать размер всех элементов массива: 10 элементов по 4 байта == 40 байт std::cout<<"not array size: " <<sizeof(*notArray) << std::endl; // тут в sizeof передано значение первого элемента массива со значением 1 типа int и размером 4 байта (размер именно элемента массива, а не указателя) (тоже самое что: sizeof(notArray[0]; sizeof(*(notArray+0)) cout<<"pointer size: "<<sizeof(pointer)<<endl; размер указателя в зависимости от битности ОС
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	209. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от minonA (?), 07-Окт-22, 14:12
	int notArray[] = {1, 2, 3} - это статический массив. std::vector - разновидность динамического. И там всё но указателях. Если бы была сущность на уровне языка, да, можно было бы в ряде случаев определять выход за границы статически, или минимизировать количество динамических проверок.
	Ответить | Правка | К родителю #158 | Наверх | Cообщить модератору

	232. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Аноним (232), 08-Окт-22, 13:46
	Опеннет эксперт утверждает что в Си++ нет массивов. На опеннет настоящие программисты и они врать не будут.
	Ответить | Правка | Наверх | Cообщить модератору

	239. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (-), 08-Окт-22, 15:25
	Не будут. Анон сказал же что это указатель с гранулярностью в int (про гранулярность красиво сказано). Спор ниачем развели тут. Да у язык не проверяет границы массива, о чувак но язык же не проверяет выход за границы, хахаха аноны такие эксперты и врать не будут . Это новый уровень дизонанса ?
	Ответить | Правка | Наверх | Cообщить модератору

155. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
Сообщение от Аноним (158), 06-Окт-22, 23:04
Настоящим экспертам-программистам с опеннет проверки не нужны.
Ответить | Правка | Наверх | Cообщить модератору

	156. "Проект LLVM развивает средства для безопасной работы с буфер..."	+6 +/–
	Сообщение от Интеллект (?), 06-Окт-22, 23:06
	Причем тут эксперты, зачем перекладывать на ресурсы процессора то что ты можешь сделать головой зарананее, хотя судя по сутации в мире, думать головой не умеют
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (158), 06-Окт-22, 23:26
	Интеллект с опеннет тут же подтвердил это утверждение. Настоящие программисты осталось только здесь
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Проект LLVM развивает средства для безопасной работы с буфер..."	+1 +/–
	Сообщение от Аноним (198), 07-Окт-22, 10:40
	Ахаха, мы все прекрасно видим как эти головы работают))
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	199. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Аноним (160), 07-Окт-22, 11:26
	Судя по ситуации на опеннет думать головой здесь умеют 3-4 человека
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	224. "Проект LLVM развивает средства для безопасной работы с буфер..."	+3 +/–
	Сообщение от Аноним (223), 08-Окт-22, 04:49
	Шиз, как ты этих 3-4 чела вычислил на анонимной борде
	Ответить | Правка | Наверх | Cообщить модератору

	231. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
	Сообщение от Аноним (232), 08-Окт-22, 13:31
	Дурачку, тут регистрация есть и они зарегистрированы
	Ответить | Правка | Наверх | Cообщить модератору

	219. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от CVE (?), 07-Окт-22, 18:26
	Зашёл CVE на сайт, на котором постят часто новости про CVE, чтобы напомнить, что CVE никуда не денутся из-за языка, который спроектирован так, чтобы человеческий фактор формировать CVE был всю жизнь, а любые методы предотвращения CVE критиковались такими же CVE-создателями.
	Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

	234. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
	Сообщение от Аноним (238), 08-Окт-22, 15:10
	Растоманы и прочие считающие себя программистами персонажи этого не понимают
	Ответить | Правка | Наверх | Cообщить модератору

220. "Проект LLVM развивает средства для безопасной работы с буфер..."	–1 +/–
Сообщение от истина в последней инстанции (?), 07-Окт-22, 18:33
> предлагается использовать классы std::array, std::vector и std::span Сто лет в обед работает. Но да, тем кто не читает про обновление в  стандартах лишний раз ткнуть носом не помешает. Сюда ещё range based loop добавить надо. > корректировки кода, позволяющий заменять переменные с голыми указателями на контейнеры А вот это молодца
Ответить | Правка | Наверх | Cообщить модератору

233. "Проект LLVM развивает средства для безопасной работы с буфер..."	+/–
Сообщение от Аноним (238), 08-Окт-22, 15:08
Зачем добавлять в компилятор лишние проверки замедляющие сбору программ если настоящим программистам они не нужны? Не кому нужны проверки не программисты и должны уйти из профессии.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема