The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



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

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

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=57876

Ответить | Правка | Cообщить модератору

Оглавление

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


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

Это ещё зачем, глупых растоманов наслушались? vector и так кидает экспешон при выходе за допустимый диапазон индексов.

Ответить | Правка | Наверх | Cообщить модератору

3. "Проект LLVM развивает средства для безопасной работы с буфер..."  +12 +/
Сообщение от Анонимemail (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 +/
Сообщение от Анонимemail (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 развивает средства для безопасной работы с буфер..."  +/
Сообщение от Анусимусemail (?), 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 +/
Сообщение от Анонимemail (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 развивает средства для безопасной работы с буфер..."  +/
Сообщение от Анонимemail (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 +/
Сообщение от Анонимemail (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 +/
Сообщение от Skullnetemail (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 +/
Сообщение от Анонимemail (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 
Ответить | Правка | Наверх | 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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру