Разработчики проекта LLVM предложили ряд изменений, направленных на усиление безопасности критически важных проектов на языке C++ и предоставление средств для исключения ошибок, вызванных выходом за допустимые границы буферов. Работа сосредоточена в двух направлениях: предоставление модели разработки, позволяющей безопасно работать с буферами, и проведение работы по усилению защиты стандартной библиотеки функций libc++...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57876
> std::vector будет отслеживаться обращение за пределы выделенной области памяти, в случае выявления которого программа будет аварийно завершаться.Это ещё зачем, глупых растоманов наслушались? vector и так кидает экспешон при выходе за допустимый диапазон индексов.
На этапе компиляции.
И после таких вот заявлений растоманы хотят кого-то уверить что у них код быстрее чем сишный работает? При наличии постоянных проверок в рантайме.
Не смешите.
Так проверки в дебаге. Код может быть местми быстрее из-за большего скоупа для анализа конпелятором. Синтетика иногда тоже такие результаты показывает. Тут главное что есть гарантии валидности
> Так проверки в дебагеКогда индекс массива зависит от внешних данных (а это чуть менее, чем всегда), предлагаешь пользователям поставлять только дебаг-версии?!
Comdiv, предлагает такое решение этой проблемы для будущих языков
http://safe-prog-lang.blogspot.com/2016/12/correctness-state...
Костыль на костыле, костылем погоняет.
А по факту - опыт и чуть больше внимательности.
Понятно. Ответить нечего. Правда, там его вариант Оберона по скорости почти не проигрывает чистому Си. А надёжность растёт существенно.https://vostok-space.blogspot.com/2022/09/benchmark-.html#more
> Понятно. Ответить нечего. Правда, там его вариант Оберона по скорости почти не
> проигрывает чистому Си. А надёжность растёт существенно.
> 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;
}Из той же оперы что и анализ алгоритмов Кнута. В реальной жизни все значительно хуже. Если бы "священный грааль" в программировании был найден - это бы в течении нескольких месяцев появилось в всех компиляторах да еще и нобелевскую премию дали. А так - очередное узкоспециализированное оправдание лодырей, которые не хотят проявлять внимание, и все ждут что за них все сделает КТО-ТО...
У тебя с логическим мышлением явные проблемы. Причём здесь алгоритмы, до ошибок в программах?
> Понятно. Ответить нечего. Правда, там его вариант Оберона по скорости почти не
> проигрывает чистому Си. А надёжность растёт существенно.
> https://vostok-space.blogspot.com/2022/09/benchmark-.html#moreКстати, С++ в силу своей специфики конструктор/деструктор много безопаснее чем чистый С - так как заставляет вспомнить в каком месте нужно освободить выделенную память. И это глупость со стороны что Linux что BSD - не принимать в ядро модули на C++. Почему? потому что на MacOSX есть возможность писать kext на C++, а система стабильнее даже FreeBSD при том что FreeBSD обычно используется для постоянно-работающего определенного программного обеспечения (серверное применение) а вот MacOSX нет - пользователь может делать на нем что хочет, про Linux даже упоминать не стоит.
> Кстати, С++ в силу своей специфики конструктор/деструктор много безопаснее чем чистый СПрограммист вообще не должен думать, когда бы ему память получить, а когда освободить. Ручное управление памятью -- зло.
>> Кстати, С++ в силу своей специфики конструктор/деструктор много безопаснее чем чистый С
> Программист вообще не должен думать, когда бы ему память получить, а когда
> освободить. Ручное управление памятью -- зло.Вот это бреднятина, если ты работаешь в 1C, и всяким фронтендом тогда да, но это не программисты - это ремесленники. Но если ты работаешь с ядром операционки или разрабатываешь библиотеки низкого уровня для ремесленников - тогда нет. Программист таких вещей четко должен понимать что и где выделять и удалять.
> Программист вообще не должен думать, когда бы ему память получить, а когда
> освободить. Ручное управление памятью -- зло.И ножи запретить, ими же порезаться можно.
Лучше постоянные проверки в рантайме, чем крвх или взлом.
> Лучше постоянные проверки в рантайме, чем крвх или взлом.Насмешил - имхо rust будут ломать чаще.
Он для этого и создан если кто не понял. Притянул из интернета пару гигабайт зависимостей для сборки и вуаля. А синтаксис и уровень программистов как-раз распологает к быстрому и незатруднительному ознакомлению со сторонним кодом. Для дураков безопасТно вобщем, в лучших традициях стадостроения.
>Притянул из интернета пару гигабайт зависимостей для сборки и вуаляМожно притянуть локально. Кто мешает?
>Для дураков безопасТно вобщем, в лучших традициях стадостроения.
А мне кажется, что у вас приступ "НИНУЖНА", ибо в плюсах нет нормального менеджера, а значит и у других не должно быть.
>>Притянул из интернета пару гигабайт зависимостей для сборки и вуаля
> Можно притянуть локально. Кто мешает?
>>Для дураков безопасТно вобщем, в лучших традициях стадостроения.
> А мне кажется, что у вас приступ "НИНУЖНА", ибо в плюсах нет
> нормального менеджера, а значит и у других не должно быть.Ты давно из исходников собирал что-то, изучая перед этим код - дабы быть уверенным в том что бинарный код соответствует исходному коду? Дай догадаюсь - никогда..
А поэтому и локальный твой код - так же был КОГДА-ТО притянут из интернета.
Даже если это так, то какая претензия тогда к расту? Скачав библиотеку для крестов с гитхаба тоже можно получить уязвимость.
> Даже если это так, то какая претензия тогда к расту? Скачав библиотеку
> для крестов с гитхаба тоже можно получить уязвимость.Да дело в том что раст ремесленники сродни 1С программистам - зачастую не знают что такое бинарный поиск.
Исходя из чего это следует, о Великий воин супротив Раста?
На основе чего ты пришёл к такому туповатому выводу?
К большому сожалению будут постоянные ошибки в алгоримах, которые точно также приводят к печальным последствиям.В реальном мире жестко заданная учетка встречается чаще чем переполнение буфера.
А что методы для проверки в рантайме добавили - ничего плохого в этом нет. Хочешь попроще? - пишешь с проверками.
>В реальном мире жестко заданная учетка встречается чаще чем переполнение буфера.А можно какие-нибудь цифры или исследования? Просто анализ от Майкрософта показал, что около 70% уязвимостей происходят из-за проблем с памятью, в том числе и с переполнением буфера.
Майкрософт это не про программирование - это про бизнес. И применять эти сведения к open-source программированию вообще никак нельзя.
А в open source какие-то особенные люди, которые не допускают ошибок с памятью и при этом отказываются работать с корпорациями? Я бы наоборот допустил, что средний корпоративный разработчик пишет код лучше среднего open source разработчика.
> А в open source какие-то особенные люди, которые не допускают ошибок с
> памятью и при этом отказываются работать с корпорациями? Я бы наоборот
> допустил, что средний корпоративный разработчик пишет код лучше среднего open source
> разработчика.А серое вещество включить? Или на Майкрософт работаешь? Open source - майнтейнер и пользователи проекта заинтересованы в надежной работе решения, а не выкинуть в его в срок... "А дальше поправим"
Тебе бы самому не помешало включать серое вещество. Что МС, что другие корпорации гораздо сильнее заинтересованы в качестве продукта (конкуренция, батенька, она такая: будешь делать шлак - клиенты разбегутся), чем программисты опенсоурса, у которых, если подумать, нет абсолютно никакой мотивации, чтобы писать качественный код, кроме чувства собственной важности (ЧСВ). Пользователи опенсорса часто банальные халявщики, и даже если они заинтересованы в качестве, то редко готовы его поддерживать денежкой. А одним ЧСВ (типовой программист опенсорса) долго сыт не будешь.
> Лучше постоянные проверки в рантайме, чем крвх или взлом.А ещё лучше -- железо спроектированное под эти проверки, и язык, который на 146% использует эти проверки. Например, Оберон.
> А ещё лучше -- железо спроектированное под эти проверки,Осталось придумать где его такое взять. Интел вообще пытался, но - не зашло.
> и язык, который на 146% использует эти проверки. Например, Оберон.
Rust с другого бока зашел, ему особое железо толком и не надо, просто компил тайм проверки всего чего можно да разумная аннотация намерений кодера. В целом достаточно разумное сочетание. Синтаксис конечно с закорючками но тут уж аннотация намерений програмера компилеру и анализатору либо есть либо нет.
>> А ещё лучше -- железо спроектированное под эти проверки,
> Осталось придумать где его такое взять. Интел вообще пытался, но - не
> зашло.Нет, Интел даже не пытался. За тебя уже всё придумали. Просто бери и пользуйся.
>> и язык, который на 146% использует эти проверки. Например, Оберон.
> Rust с другого бока зашел, ему особое железо толком и не надо,Нет. Нет железа под язык. Значит нет никакой безопасности.
> просто компил тайм проверки всего чего можно да разумная аннотация намерений
> кодера.Нет. Если железо кривое -- это всё для самоуспокоения. От Мельтдауна никакой раст не спасёт. Даже Оберон бесполезен.
> В целом достаточно разумное сочетание. Синтаксис конечно с закорючками но
> тут уж аннотация намерений програмера компилеру и анализатору либо есть либо
> нет.Нет. Вырвиглазный синтаксис помноженный на штатную возможность перехода с алгоритмического уровня на аппаратный. Оставьте себе.
Железо такое есть, эльбрус называется. Там есть специальный режим, в котором процессор изображает из себя виртуальную машину, работающую по спецификации языка C. Прощай выход за границы буферов, приведение несовместимых типов и прочее-прочее. Недостаток - даже в железном исполнении есть потеря производительности, местами более 40%.
Хотя чаще до 20%. Ну и ещё проблема, код с хаками не работает. В итоге, только сравнительно недавно смогли заставить в этом режиме работать стандартную GNU libc.
>vector
>На этапе компиляции.std::vector<T,Allocator>::at
Returns a reference to the element at specified location pos , with bounds checking.
Только по `.at(i)`, и этой функцией мало кто пользуется.
а вы берете указатель от .data() и дальше используете арифметику с указателем?
operator[] вам о чем-нибудь говорит?
зачем, если есть at?
зачем нужен ты, если есть GPT-3?
Согласен. Null не нужен, столько багов из-за него.
Давайте разыминуем анона выше !
> Давайте разыминуем анона выше !Зачем тебе разыменованный троллейбус?! И что это делает?
Gfortran: -fcheck=all
Собственно, уже давно есть GLIBCXX_HARDENED, по умолчанию включенный в Федоре и ряде других дистров. Добавляет примерно то, о чем новость для libc++.
> Предлагаемая модель безопасного программирования для C++ предполагает
> использование предоставляемых стандартной библиотекой классов
> при работе с буферами вместо манипуляций с голыми указателями.
> Например, предлагается использовать классы std::array, std::vector и std::span,
> в которые будет добавлена проверка выхода за границы выделенной памяти,
> производимая во время выполненияОдна небольшая доработка, а целый ЯП, придуманный только для безопасной работы с памятью, уже может лететь на помойку
А что, LLVM в кресты встраивают борроу чекер? Проблем с лайфтаймами больше не будет?
Если тебе нужен боров в чекере ты его можешь сам присобачить в любой момент. https://www.youtube.com/watch?v=Lj1GppqNr8c
Ща начнется визг, что ваш 6Ч, не тот бЧ.
> боров чекерДавно есть, std::unique_ptr называется.
>производимая во время выполненияЗакатывай губу назад.
В том языке аналогичная проверка тоже происходит во время выполнения
Будет короче тормозить еще больше из за постоянных проверок. Голые указатели придумали не просто так. А потому, что проги на асме работали в 10 раз быстрее, чем всякие проги на басике, но хотелось же писать на ЯВУ, а не убивать мозг проблемами аллокешена регистров. Есть простая и тупая вещь. В других языках типа Delphi/Lazarus можно включить проверку границ в отладочном режиме. Есть так же клевые менеджеры памяти типа FastMM, которые в FullDebugMode отслеживают все возможные проблемы с утечками памяти и use-after-free. Это просто Сишники привыкли страдать. А еще говорят, что их язык лучший в мире, ога.
сиплюсплюсовцы же
А еще ассерты есть. И вообще работать с буфферами неявного размера, как это принято в Сях - это плохая идея. Короче это называется культура программирования. Если нанимать индусов на аутсорсе за копейки, то никакие ухищрения не помогут. А в итоге ради так называемой безопасности производительность нативного кода опустят до уровня скряптов. Ну и зачем тогда вообще нужен нативный код? Давайте всех посадим на питон.
C и C++ это разные языки.
Не может быть!
> А еще ассерты есть. И вообще работать с буфферами неявного размера, как
> это принято в Сях - это плохая идея.Си разный бывает. В каком-нибудь MISRA например много чего НЕ принято. И это как бы си но как бы здорово другой по надежности если на эти правила не забивать.
Всякие void* - ой, вы не указали намерения, как это проверять? Статический анализ в пролете.
Туда же массивы неизвестного размера и прочий хлам, где намерения не декларированы.
Математика над указателями это вообще зло. Реально легитимных причин это делать есть минимум, типа реализации своего memcpy() или декомпрессора какого. В более приземленном коде это намекает что кодер занимается чем-то не тем. Особенно если в выражение входят разные указатели, нормальные анализаторы на это жутко воют и правильно делают.А если все типизировать нормально - вообще и на сях нормально можно. Чертова куча этого летает в космос, рулит критичными процессами, и в целом факапов можно избежать. Если задаться такой целью. Нет там никаких серебряных пуль, для этого надо всю методологию разработки софта с прицелом под это делать, комплексно. Это назойливо, но вполне эффективно. Если раздолбаить, никакой раст не спасет. И для него эти методологии вообще пока толком не написаны, только-только появляется первое понимание его проблем вообще.
Проверка диапазона не ресурсоёмкая, и на некоторых платформах даже аппаратная.Возможность писать особо быстрый код ни куда не исчезает.
Но и у системных программистов не во всяком месте нужен особо быстрый код, в ущерб безопасности или времени его написания.
Просто по умолчанию предлагается чуть более безопасный подход.
Не бывает бесплатных проверок, даже за защищённый режим процессора с его виртуальной памятью приходится платить свою цену, реальный режим реально быстрее. У x86 так же есть инструкция bound для проверки соответствия указателя определённому диапазону, но естественно времени она занимает столько же как и пара cmp+j[ab], хотя реализована аппаратнее некуда. Проверки данных по одной границе при изменении оказались дешевле и инструкцию выбросили на свалку истории. Дешевле одной проверки только отсутствие проверки во время выполнения, например мы можем быть уверены, что в результате операции i & 255, i не выйдет за пределы массива длиной 256 байт. Компиляторы Rust и Ada вроде как специализируются на обеспечении таких гарантий и должны бы быть быстрее компиляторов Си... должны бы быть.
Проверки это вещь столь бесплатная, что у gcc даже есть флаг -funroll-loops, который разворачивает циклы так, чтобы уменьшить число проверок.
> даже за защищённый режим процессора с его виртуальной
> памятью приходится платить свою цену, реальный режим реально быстрее.Столько нового и интересного узнаёшь на Опеннете. То есть виртуальная память иногда медленнее, поскольку её размер больше физической и страницы иногда гоняются на медленный накопитель и обратно? На самом деле, в этом случае система работает быстрее - потому что в реальном режиме она бы вообще не работала из-за нехватки памяти.
> Столько нового и интересного узнаёшь на Опеннете. То есть виртуальная память иногда
> медленнее, поскольку её размер меньше физической и страницы иногда гоняются на
> медленный накопитель и обратно? На самом деле, в этом случая система
> работает быстрее - потому что в реальном режиме она бы вообще
> не работала из-за нехватки памяти.Нет, процессору же приходится гонять виртуальные адреса через таблицу страниц для превращения их в реальные адреса. Или для броска исключения при выходе за пределы зарегистрированных ядром ОС страниц или при неправомерном доступе к ним. Теоретически в процессоре есть блок предназначенный для параллельного сравнения адреса с адресами страниц, только вот блок этот не безразмерный. В нём лежат только страницы к которым обращались недавно. В случае остальных, процессору приходится копаться в огромной таблице в оперативной памяти, а это ой как не быстро.
Исключение потому так и называется, что генерируется в исключительных случаях. Так то да, если запретить ещё и прерывания, то система будет работать «быстрее», не прерываясь на чтение с накопителя и приём пакетов. А если обрабатывать только 64 байта, то не придётся читать из медленного ОЗУ, поскольку хватит линейки кеша. Только почему-то мало кому приходит в голову «оптимизировать» всё это.
> Так то да, если запретить ещё и прерывания, то система будет работать «быстрее»,
> не прерываясь на чтение с накопителя и приём пакетов.Вот кстати в голодные времена провайдеры вместо Cisco использовали ПК с Linux
и отключали прерывания, чтобы увеличить число пакетов перевариваемых роутером за секунду.> А если обрабатывать только 64 байта, то не придётся читать из медленного ОЗУ,
> поскольку хватит линейки кеша. Только почему-то мало кому приходит в голову
> «оптимизировать» всё это.Те кто воюют за оптимизацию работы процессорного кеша в природе водятся это факт.
К сожалению немногим программистам вообще в голову приходит мысль хоть как-то оптимизировать
свои программы. Компилятор сам по их мнению справится, а код они пишут для людей, а не машин.
>> Так то да, если запретить ещё и прерывания, то система будет работать «быстрее»,
>> не прерываясь на чтение с накопителя и приём пакетов.
> Вот кстати в голодные времена провайдеры вместо Cisco использовали ПК с Linux
> и отключали прерывания, чтобы увеличить число пакетов перевариваемых роутером за секунду.Осталось написать дату тех времён и характеристики железа - что бы можно было прикинуть, насколько сейчас сократились потери.
>> А если обрабатывать только 64 байта, то не придётся читать из медленного ОЗУ,
>> поскольку хватит линейки кеша. Только почему-то мало кому приходит в голову
>> «оптимизировать» всё это.
> Те кто воюют за оптимизацию работы процессорного кеша в природе водятся это
> факт.Вот пусть такой человек со мной и спорит. Пока господа теоретики даже не смогли обнаружить, что у меня на гатхабе опубликованы результаты таких оптимизаций, как раз из-за чуть более оптимального использования кеша мой интерпретатор обгоняет скомпилированный код:
Интерпретация:
$ time echo 5 | refal lambda.ref
Enter a number:
120real 2m47,046s
user 2m46,415s
sys 0m0,014sСкомпилировано Рефал-05
$ time echo 5 | ./lambda-05
Enter a number:
120real 3m32,260s
user 3m30,360s
sys 0m1,193sЭто на исходнике, который не я писал. На моём и в 5 раз быстрее получилось.
> К сожалению немногим программистам вообще в голову приходит мысль хоть как-то оптимизировать
> свои программы. Компилятор сам по их мнению справится, а код они пишут
> для людей, а не машин.Как раз быстрый код пишется для людей, Кнут вон несколько талмудов написал.
> У x86
> так же есть инструкция bound для проверки соответствия указателя определённому диапазону,
> но естественно времени она занимает столько же как и пара cmp+j[ab],
> хотя реализована аппаратнее некуда.А если посмотреть талмуд, то она делает совсем другое - генерирует исключение #BR — BOUND Range Exceeded. Время её выполнения, надо полагать, Вы дадите в ответе на моё сообщение?
> А если посмотреть талмуд, то она делает совсем другое - генерирует исключение
> #BR — BOUND Range Exceeded. Время её выполнения, надо полагать, Вы
> дадите в ответе на моё сообщение?Она даёт исключение при выходе за границы проверки, а не всегда.
Что бы «естественно времени она занимает столько же как и пара cmp+j[ab]» имело силу, хорошо бы написать времена для обоих случаев. А эти команды даже делают разное.
> Что бы «естественно времени она занимает столько же как и пара cmp+j[ab]»
> имело силу, хорошо бы написать времена для обоих случаев. А эти
> команды даже делают разное.Естественно ситуация выхода за пределы массива является серьёзной ошибкой и не так уж и важно сколько времени уйдёт на её обработку. В худшем случае она даже может привести к завершению программы. Так, что сравнивать нужно ситуации когда выхода за пределы массива нет.
> Так, что сравнивать
> нужно ситуации когда выхода за пределы массива нет.Так для этого надо найти старый тадмуд, где указано время исполнения BOUND. Я смутно припоминаю, что она дико медленная, как и все сложные инструкции. Но не я делал заявление на тему «естественно столько же», так что тут есть кому искать тот талмуд. :)
> Но не я делал заявление на тему «естественно столько же»,
> так что тут есть кому искать тот талмуд. :)Этот талмуд идёт в комплекте с masm32 и он у меня под рукой
bound - 7 тактов на 486
cmp reg, mem - 2 такта
Jxx при пропуске прыжка - 1 такт
Ой, bound даже немного медленнее.
> на 486Сейчас какой год идёт? Не, не так... Какой сейчас век?
> Сейчас какой год идёт? Не, не так... Какой сейчас век?Да без разницы какой год. Основа вычислительного блока в процессорах Intel не меняется. Просто самих блоков стало больше и в местах где можно параллелить инструкции, процессор параллелит. Хотя да, цепочку cmp, ja, cmp, jb можно за счёт спекулятивного выполнения ужать до тактов cmp, ja, если перехода по Jxx не будет. Но вот если будет, то процессор неизвестное количество тактов потратит на откат состояния.
>> Сейчас какой год идёт? Не, не так... Какой сейчас век?
> Да без разницы какой год. Основа вычислительного блока в процессорах Intel не
> меняется. Просто самих блоков стало больше и в местах где можно
> параллелить инструкции, процессор параллелит. Хотя да, цепочку cmp, ja, cmp, jb
> можно за счёт спекулятивного выполнения ужать до тактов cmp, ja, если
> перехода по Jxx не будет. Но вот если будет, то процессор
> неизвестное количество тактов потратит на откат состояния.Откат будет, внезапно, в случае ошибки в программе! Что Вы там собрались оптимизировать при выходе за пределы буфера?
> Да без разницы какой год. Основа вычислительного блока в процессорах Intel не меняется.Ага, конечно. Интел не настолько дно в разработках.
> Ага, конечно. Интел не настолько дно в разработках.У них есть специальная инструкция rdtsc которой можно узнать, сколько тактов занимает та или иная инструкция или блок инструкций. Если работать только с регистрами или с кешем первого уровня, то число тактов на инструкцию совпадает с 486 процессором. Просто кеш стал больше, число ALU стало больше, а конвееры стали хитрее. Наоборот Intel создала RISC процессор под своим CISC процессором, чтобы разбить сложные инструкции на несколько маленьких и примитивных, что позволяет им чуть лучше гнать частоты, так как на нынешнем уровне скорость распространения электрического тока от тактового генератора и до конца каждой используемой инструкции, уже имеет значение.
Хотя да, это можно считать за изменение, но число тактов не уменьшилось уж точно.
>> Ага, конечно. Интел не настолько дно в разработках.
> У них есть специальная инструкция 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 процессором.Потрудитесь подтвердить цитатой официальной документации, или прекратите генерировать удивительные гипотезы.
>> на 486
> Сейчас какой год идёт? Не, не так... Какой сейчас век?Да даже для того времени утверждение «времени она занимает столько же» -- неверно, сложите такты. :) А кто скажет «2+1 + 2+1 это почти 7» - тот пусть идёт читает Генри Уоррена младшего, главу 4.1.
>> Но не я делал заявление на тему «естественно столько же»,
>> так что тут есть кому искать тот талмуд. :)
> Этот талмуд идёт в комплекте с 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]***, хотя реализована аппаратнее некуда.
В защищенном режиме много всякой мути, которая в теории должна жутко тормозить. Виртуальная память, переключение контекстов и т.д. В современных процах все это решается за счет распараллеливания. Т.е. проблему по сути закидывают шапками. Это когда тебе тех процесс позволяет клепать сколько угодно транзисторов, так что можно параллельно просчитывать 100500 инструкций вперед при over9000 ветвлениях. Другое дело, что расплатой за это является возможность атак по сторонним каналам. Так что, как сказал Мэт Дэймон, да, да...
Так чтож, теперь отказаться от защищённого режима? Привет, эпоха DOS! Сторонние каналы не требуются, получай достпуп к любым соседним процессам сколько хочешь!
> Привет, эпоха DOS! Сторонние каналы
> не требуются, получай достпуп к любым соседним процессам сколько хочешь!И правда, быстрее же. =)
Существует архитектура Mill в которой нет виртуальной памяти и много чего другого, что есть в классических процессорах усложняющих их и тем не менее многие FLOSS программы и операционки корректно работают на ней после компиляции и практически без изменений.
Но в реальном мире, кроме FOSS, ещё браузер загружает страницы с тоннами стороннего JS, которому наплевать на корректное сосуществование с другими просессами в архитектуре без виртуальной памяти.
> Но в реальном мире, кроме FOSS, ещё браузер загружает страницы с тоннами
> стороннего JS, которому наплевать на корректное сосуществование с другими просессами в
> архитектуре без виртуальной памяти.И при всем этом там приколы типа ROWHAMMER могут работать. Даже оттуда. Который как оказалось даже в DDR4 все же вылезает в определенных условиях. Сюрприз!
А ещё есть компьютер Спектрум. Самый быстрый там вариант - самомодифицирующийся код. Но реальный мир - это немного другое.
> А ещё есть компьютер Спектрум. Самый быстрый там вариант - самомодифицирующийся код.
> Но реальный мир - это немного другое.В реальном мире вооон те игроделы бьют рекорды по скорости декомпресии vs плотность сжатия используя "data to code transformation". Из данных генерится код, это для их случая самый быстрый способ распаковки. Это нишевой случай но так можно было.
Можно было, конечно, осталось посчитать, сколько играли в тот «Дум» на Спектруме и подумать, почему оно появилось сильно позже чем всякие Dyzzy и почему сорцы всех этих шедевров написаны под PC, который маст дай. ;)
> В защищенном режиме много всякой мути, которая в теории должна жутко тормозить.На счёт "жутко тормозить" это уже слишком безграмотно.
Если писать эмулятор 386+, то конечно, софтовая эмуляция защищенного режима требует каких то ресурсов, но не много. А по сравнению с иными издержками, и вовсе не беспокоит. Даже в софтовом виде, без предсказаний и спекулятивных операций.Так же, "грамотно" написанное ПО не спасает никакой самый быстрый процессор.
Примеры? Неповоротливые игры на Unity, числодроюильные алгоритмы на Питоне, извращения с компиляцией в Ардуино.
Причем, тут и i10 10GHz принципиально не поможет.
А проверки диапазонов, есть много где, и почему то, рейтинг тормозного ПО они не занимают.Про инструкцию bound сказано верно. Оптимизированный алгоритм, с учетом архитектуры, часто побеждает, то что предусмотрено разработчиками.
Пристномамятная фича - в z80 добавили инструкцию копирования памяти, стало быстрее, чем на 8080, но с учетом специфики z80 применяли програмное копирование, ибо на 90%(!) быстрее работало, чем аппаратное.
Это совсем разгромный пример, а с меньшей разницей в скорости, как грязи.
> Пристномамятная фича - в z80 добавили инструкцию копирования памяти, стало быстрее, чем
> на 8080, но с учетом специфики z80 применяли програмное копирование, ибо
> на 90%(!) быстрее работало, чем аппаратное.Ну про 90% Вы загнули. LDIR - 21 такт на 1 байт. LDI - 16. Серия последних немного выигрывала по скорости за счёт раздутия кода. Быстрое копирование, насколько помню, выполнялось сериями POP+PUSH - 10+11 на 2 байта. Где-то вдвое быстрее, без учёта дополнительных инструкций. Хотя, может я что-то забыл, да и вариант с генерацией 100 Кб кода для заполнения 6 Кб экрана не рассматриваю.
Кстати, в IA32 с была похожая ситуация rep movs, но ныне она ускорена аппаратно с учётом нюансов работы с кешем.
Верно.
Вдвое быстрее, плюс издержки, это и есть примерно на 90% быстрее. Прирост зависит от размеров портянки из push/pop в реализации memcpy(). Больше 32..64 пар редкость.Про rep movs тоже в курсе.
Я как коллекционер старого железа, сконен и что под них иногда написать, и эмуляторы пишу тоже.Удивлен грамотному комментарию, по столь экзотической теме.
> Верно.
> Вдвое быстрее, плюс издержки, это и есть примерно на 90% быстрее.Действительно. Как обычно, я налажал с арифметикой.
> Прирост
> зависит от размеров портянки из push/pop в реализации memcpy(). Больше 32..64
> пар редкость.
> Про rep movs тоже в курсе.
> Я как коллекционер старого железа, сконен и что под них иногда написать,
> и эмуляторы пишу тоже.
> Удивлен грамотному комментарию, по столь экзотической теме.Довелось когда-то покодить для Спека. Вот редактор обратно совместимый с SoundTracker https://github.com/STrusov/CPS
Писался для демок, проигрыватель не самый быстрый, но более-менее стабильный по тактам.
Про копирование помню немного, поскольку тогда мы искали пути скроллировать весь экран и перепробовали все комбинации, до каких докопались в чужом коде и додумались сами. В итоге удалось лишь хитростью.
Благодарю. Взял в коллекцию. Смотрю.
А на Гитхабе меня уже забанили, поэтому ссылками не делюсь.
Как забанили? Это надо в новости. Тут публика любит, когда кого-то банят. Ну и вроде есть gitflic (что бы изменить там видимость репозитория, надо в службу поддержки написать, как говорят; я не пишу, просто год жду, вдруг заработает).
> Как забанили? Это надо в новости.Уже писали про это. Хотя, банили якобы сотрудничавших с подсанкционными организациями, работавших из Крыма, и вроде как не очень много народу. Но, меня то за что? Даже не отвечают причину в отписках.
А вообще, рукописи и репозитории не горят. А кучу чужих добавленных в лайки и форки проектов жалко.
Если забанили на основании решения властей США - тогда им ничего не стоит указать это в причине (таким образом Микрософт как бы получаются невиновны). Не удивлюсь, что там была ещё опция «стукани на коллегу», и замешаны какие-то неадекваты. Во всяком случае, когда местная шаражка удалила мои репозитории, они точно так же не могли объяснить причину.
> Не бывает бесплатных проверок,Вообще в компилтайм они условно бесплатные. В том плане что это время потратит компилер 1 раз, при сборке, а не софт в рантайм. Проблема в том что в полном случае это решение нерешаемой задачи. Но в многих частных случаях это все же можно свести к доказуемым на автомате вещам. Что и дает возможность потрепыхаться на тему влезания на елку не обдирая зад.
> Проверка диапазона не ресурсоёмкая, и на некоторых платформах даже аппаратная.Звон-то конечно слышали, но откуда он, не разобрались.
Заканчивайте уже тащить слухи про Рабиновича, выигравшего на бегах два миллиона.
что за буфера такие? массивы имелись ввиду?
https://ru.wikipedia.org/wiki/Буфер
В заголовке LLVM, а новость про clang.Непорядок.
почему бы сразу не писать на чистом Си?
есть же чистый углерод
> есть же чистый углеродОн невкусный.
Зачем? Если например от C++ можно использовать только классы/структуры - и код получается более читаемым. И не лезть в шаблоны и иже с ними.
Вся мощь в шаблонах, а ты их не осилил :\
> Вся мощь в шаблонах, а ты их не осилил :\Я их просто не использую. Если в большинстве случаев профессионалу хватает обычного C, то и шаблоны не нужны. Чем и пользуюсь. Но от C++ структур/классов не откажусь.
Сразу и видно, какой ты профессионал, раз шаблоны не осилил
> Сразу и видно, какой ты профессионал, раз шаблоны не осилилЕсть знакомые, которые пишут довольно небольшое ПО, ну скажем под встраиваемые устроства. Код у них на 95% тот же Си, но с небольшим количеством плюшек из С++. Ну и есть положительные особенности компилятора, который больше ругается на сомнительный код.
В принципе, от неиспользования шаблонов подобные и не потеряют ничего, им их часто и применить некуда. Но несмотря, что таки профессионалами в С++ их назвать нельзя, программистами они бывают вполне годными.
Зато я много видел таких профессионалов любителей шаблонов, ваявших такую хрень, что никто потом не мог понять, как оно работает, даже сами авторы шедевров. С километровыми сообщениями об ошибках. Таких любителей шаблонов надо в детстве компов лишать.)))
Любители шаблонов обычно пишут совершенно неподдерживаемый код, который трудно отлаживать и сопровождать. Называется - горе от ума.
Как раз таки классы самое ненужное в цпп. Когнитивная нагрузка раза в 1.5 снижается, когда не нужно думать об иерархиях классов и связях между ними. Бессмысленная вещь, только отнимающая время.
Классы позволяют перегружать операторы например и писать vec1 + vec2 + vec3 вместо add_vec(add_vec(vec1, vec2), vec3). А ненужное - это твое никчемное мнение
В нормальных языках пишут vec1.add(vec2).add(vec3)
И редактор кода сможет указать где этот метод реализован, а не просто + какой-то
У вас синтаксис подразумевает vec1 += vec2 + vec3 или vec1 + vec2 + vec3
???
> У вас синтаксис подразумевает vec1 += vec2 + vec3 или vec1 +
> vec2 + vec3
> ???А у вас сложение не коммутативное чтоли? Когда оно именно так - это всяко отдельный случай требующий отдельного внимания.
Перегрузка операторов как раз самая отвратительная вещь в плюсах.
А ничё, что эта вещь не только в Плюсах имеется? Значит, востребована.
> Перегрузка операторов как раз самая отвратительная вещь в плюсах.Это если применять куда попало, что бы было.
А бывает, что и необходимо, и при этом ещё и изящно.
Типичный ответ приплюснутой макаки. Ровный пацан для математики оптимизированный код на интрисинках напишет, а не вот это вот.
Зато потом ровного пацана забивают лопатой, когда код нужно будет перенести на другую архитектуру процессора)))
Я бы, наоборот, хотел бы найти утилитку, которая анализирует плоскосишный код и строит квази-UML диаграммы.
> Как раз таки классы самое ненужное в цпп. Когнитивная нагрузка раза в
> 1.5 снижается, когда не нужно думать об иерархиях классов и связях
> между ними. Бессмысленная вещь, только отнимающая время.А как-же конструкторы/деструкторы - которые, заставляя программиста возвращаться к написанию данных функций - четко понимают что где выделять и что где удалять? На порядок уменьшая количество ошибок с выделением/освобождением памяти и удалением нулевых поинтеров.
Классы очень полезны, когда они изолированы и не связаны с остальным кодом (как vector или string, илм complex и даже элементы графического интерфейса в какой-то степени).Когда классы проникают в ЛОГИКУ работы прогаммы (в какой-нибудь основной цикл приложения/потока/сервера tcp) - это очень и очень плохо. Нужно от такого избавляться!!! Вынуждает использовать всякие inversion of control (и прочую лабуду), как следствие - логика работы программы разбросана по нескольким разным модулям и работать с таким кодом становится невозможно.
Ну напиши, скажем, игровой движок на чистом Си. Кармак не просто так к третьему квейку сдался и перешёл на C++.
Ваще-то просто так.
просто так. и кармак живой пример что на си можно творить чудеса. досихпор фиг кто понимает его квадратичную ф-ю, не говоря о гениальности остальных решений. ты вообще кармака читал, дитё ? какие могут быть кресты с этим ООП уродством после божественного си кодинга.
Просто так, по доброй воле, на плюсы не переходят.
Про быстрый обратный корень — вы серьёзно считаете, что Кармак его изобрёл?
Ага, Кармак изобрёл разложение функции в ряд Тейлора :)
Ну тут немного другая математика, но весьма тривиальная. Но дело не в этом, а в том, что компьютерная реализация уже давно существовала, Кармак лишь позаимствовал её (и комментарий даже оставил — «Я ХЗ КАК, но оно работает»).
Не важно. Поговаривают что комментанрий кстати не его (это про тот что рядом со сдвигом ?). Посмотрите другие файлики, это же гениально ! Но да, послушать тридстартера так перейдя на ООП все станут писать как Кармак. Ну что за бред.
А вообще, Анон, приятно видет что есть еще интересующиеся вопросом. Заходи на офтц в x86, по фану покодим фигню всякую
Увы, нет, фан кодинга в прошлом.
Да и в прошлом гораздо интереснее был реверсинг, а кому это сейчас нужно.
Если речь про т.н. «аппаратный алгоритм», то описал его Джон Фон Нейман в First Draft of a Report on the EDVAC в 1945-м году.
Кармак сказал что квадратичную функцию списал из какого то журнала по программированию графики а не придумал её. И он часто говорит что не придумывает алгоритмы а сводит воедино то что известно из чужих научных работ по алгоритмам.
Держи - https://www.youtube.com/watch?v=LR3THwlv_r4. Не закончено еще, но процесс идет. 663 серии по 2 часа, если осилишь.
И прямо в первом кадре видео — файлы .cpp. Ну ок.
> И прямо в первом кадре видео — файлы .cpp. Ну ок.Какой еще срр? Там фильм про любовь должен быть ... Или не та ссылка ...
По моему опыту на С++ быстрее писать.
> на С++ быстрее писатьна С++ быстрее писать ошибки.
Можно увидеть вашу реализацию быстрой сортировки на чистом Си?
Все есть на github
Современные программисты не могут в Си. Они способны максимум верстать медленные веб-страницы на java на фреймворках фреймворков
>Например, предлагается использовать классы std::array, std::vector и std::span, в которые будет добавлена проверка выхода за границы выделенной памяти, производимая во время выполнения.Кому надо - тот давно их использует.
Тормозной C++ компилятор будет ещё тормознее.
Ах, тормознутая сборка на крестах всегда вызывет боль.
Какой молоток - такой и Qt :)
вы не понимаете, это другое111
шланг всё исправит, и можно будет использовать много шаблонов 111
Интересно, чего все так наяривают на скорость компиляции?Это вы так черезжoпно код пишете, что после каждой строки проверяет "сейчас скомпилилось? а сейчас? а сейчас?".
Или вы из гентушников, для которых компилять это смысл существования?Какая разница сколько оно компилится? Вы делаете это один раз, а запускаете тысячи. И намного важнее насколько будет оптимизирован и быстр код полученный код.
Как бе дааа… Если ли бы ты написал хоть одну строчку кода в жизни, то знал бы, что без проверки узнать, работает ли всё так, как хотелось, невозможно.А ещё часто бывает доработка на месте, когда ты не знаешь, что нужно дописать, и собрать необходимую информацию можешь только после деплоя и запуска (а то и в несколько итераций, иногда только в проде).
Ну и потом, если после каждого изменения ты не будешь проверять, то потом тебе придётся искать баги во всех изменениях и это немало работы, когда это может быть самая тривиальная опечатка.
Поэтому доработка->деплой->тестирование это стандартный цикл при разработке софта.
Кстати, оптимизированность и скорость не такое и высокое значение имеют, главное -- это способен ли код решать задачу, корректно ли он это делает, и насколько эффективно. Иногда это конечно приводит к печальным последствиям в виде чрезмерно завышенной ресурсоёмкости, но это всё профилируется и потом уже дорабатывается при возникновении такой проблемы, никто никогда в своём уме не будет об этом думать раньше времени.
Ну так ты пишешь все что нужно проверить - функцию, класс, модуль, хз на чем ты пишешь - и один раз запускаешь компиляцию! Зачем ее дергать каждый раз?> А ещё часто бывает доработка на месте, когда ты не знаешь, что нужно дописать...
Хе, вот тут у тебя проблема в компетенции или у проекта вообще. Вот тебе варианты:
- Заглянул в доку и прочитал что нужно
- Поставил breakpoint и посмотрел что нужноНу а если ситуация "мне бекенд что-то должен ответить, но хз что..." то это проблема явно не компилятора.
Тривиальные опечатки исправляются тривиально.
А нетривиальные - покрываются тестами (напр. ты не ту переменную на вход послал и оно все скомпилилось)
Плюс этот пример вообще не в тему - инкрементальная компиляция решает 99% таких ситуаций.
Проблема в компетенции тут у тебя. Просто ты манякодер, который не делал никогда, например, промышленные системы.
> оптимизированность и скорость не такое и высокое значение имеют, главное -- это способен ли код решать задачу, корректно ли он это делаетЭто абсолютно несвязанные задачи. Любой код должен решать поставленную задачу и делать это корректно, иначе это какой-то говнокoд.
Если компилятор смог оптимизировать без твоей работы - это только плюс.> никто никогда в своём уме не будет об этом думать раньше времени
Неправда. Ты всегда должен заранее оценивать сложность тех или иных алгоритмов, по имеющимся данным подбирать структуры данных и тд.
То что в итоге что-то может быть не учтено - это да, но оставлять все на "а... потом профильну и исправлю" это бред.
Вот так выберешь быструю сортировку вместо сортировки пузырьком, а потом окажется, что пузырьком быстрее и эффективнее (в частности, для gpgpu). Можно делать только равновероятно неверные предположения. Если какой-то код постоянно бесцельно исполняется, то это конечно лишнее. Всё остальное можно узнать только при реальном применении на платформе (и после достаточного увеличения нагрузки). А вот тратить время на, вполне вероятно, бесцельные или ошибочные оптимизации, вот это максимально не эффективно.
Легче оставить дебаг сборку
Чтобы тормозило, как в расте?
Всего лишь как в спарке.
Как только этого плешивого старичка не вытаскивают. И один тул напишут к нему. И другой. И третий.И все равно С++ отвратителен. Своим синтаксисом в первую очередь. Эти гении даже не додумались сделать keyword для функции. Блин.
А зачем нужен keyword для функции? После пистоновских отступов теряетесь в коде?
Как минимум это позволяет упростить компилятор. Н. Вирт не зря использовал procedure и function как минимум с паскаля. В Обероне вообще только procedure осталась.
Про вместо Function пишут PROCEDURE.Функции остались ;-)
Про пишут procedure вместо view. А на функции даже смотреть нет смысла.
Так они же ненавидят паскаль и Вирта.
В результате творения Вирта используют лишь для обучения. Для реальной работы его творения использовать невозможно. Задолбаешься элементарно постоянно писать procedure и function.
1) Для выхватывания глазом функций. 2) для парсеров у всяких редакторов кода. Там УЖАС КАК СЛОЖНО СДЕЛАТЬ НАСТРОЙКУ ФУНКЦИЙ ДЛЯ С.
Вам гнутые подогнали целый компилятор, а вас парсеры не работают?
> 1) Для выхватывания глазом функций. 2) для парсеров у всяких редакторов кода.
> Там УЖАС КАК СЛОЖНО СДЕЛАТЬ НАСТРОЙКУ ФУНКЦИЙ ДЛЯ С.Настолько сложно что компилер с сделали в 4 функицях, C4 называется.
>> 1) Для выхватывания глазом функций. 2) для парсеров у всяких редакторов кода.
>> Там УЖАС КАК СЛОЖНО СДЕЛАТЬ НАСТРОЙКУ ФУНКЦИЙ ДЛЯ С.
> Настолько сложно что компилер с сделали в 4 функицях, C4 называется.Ну вот, сложно же. Для простых языков хватает одной.
>:Как только этого плешивого старичка не вытаскивают. И один тул напишут к нему. И другой. И третий.
>:И все равно С++ отвратителен. Своим синтаксисом в первую очередь. Эти гении даже не додумались сделать keyword для функции. Блин.Так в расте он еще отвратительней раза в 2))))
>>производимая во время выполнения.Шикарно! я считаю. Даже судя по тутошнему вою "медленно, медленно" прогеры станут ещё меньше использовать стандартные контейнеры в угоды указательной арифметике. Быстро же!
Тем кому надо и так уже at() используют, а все остальные оптимизаторы убегут от этих рантайм проверок, так что багов меньше не будет. Разруха же не в языке. :D :D :D
А где ? Если разработчикам надо знать все тонкости вроде не вызываем at() - там нет проверки, в стандарте ничего не сказано, но это же все знают.
Плюсам уже ничего не поможет. Их скорый конец лишь дело времени. Раст уже просочился в ядро, оттуда он просто уничтожит все нержавое. Трепещите, друзья.
Ну придёт Carbon, фундаментально ничего не изменит. Лишь, синтаксис подрихтует.
>Раст уже просочился в ядро, оттуда он просто уничтожит все нержавое.Как бы он само ядро не уничтожил.
Десятое правило Гринспена вас пожрёт.
Зачем оно нужно когда есть нативные компиляторы под любую платформу.
Всегда так делаю. Исходный код тот же. Сборку делаю под конкретную платформу на ней же. Три компьютера рядом стоят.
Любой настоящий программист понимает что оно на самом деле бесполезно
> исключения ошибок, вызванных выходом за допустимые границы буферовСовсем деградировали современные погромисты. Помню как в своё время на ассемблере в отладчике оптимизировал и экономил каждый такт, каждый байт.
Никто не мешает вам и сейчас этим заниматься. Думаю, с руками такого специалиста оторвут, который полдня оптимизирует такт, а оставшиеся полдня байт.
Ага, а в Вилабаджио просто поставят 32-битный микроконтроллер и будут праздновать.
> и будут праздновать...очередную дыру в проекте.
Я уже старый, мне 78, и давно на пенсии, все мои знания устарели, в мире "бизнесменов" и "маркетологов" не востребованы. Максимум с чем имел дело, так это 8086 процессор, 386 и выше уже не застал.
А какой самый большой проект вы тогда писали?
Не знаю какую метрику предложить, пусть будут LoC (ну или предложите свою)Поясню к чему это спрашиваю:
Целое ядро линукса версии 1.0.0 содержало 176250 строк кода.
Версии 5.11 - 30.34 миллионов строк вообще и из них около 14% само ядро, 60% - дрова. Т.е. "чистое ядро" - больше 4 млн. строк кода.
Не задумывались ли вы что это не погромисты деградировали, а кодовая база стала настолько, что охватить ее взглядом не может практически никто, даже при мелком дроблении на проекты, подпроекты и тд?
И чтобы хоть как-то заставить это работать приходится делать фреймворки, уровни абстраций и тд?
Надо было делать микроядро.
Тогда бы это был не один монолитный bloat на 30000000 строк, а 300 неблоатов по 100000
>Чел на 939 сокете
>386 и выше уже не засталЛукавит дедуля
Так может он на 939 только в зуму и солитер играет.
Тут недавно информация прошла. Одна команда что-то там изучала и упростила задачу со 100 тысяч уравнений до четырех (не тысяч - просто до 4-х). Считаете, они даром потратили время?
Современным программистам не понять что такое оптимизировать каждый байт и каждый такт
Любой каприз за ваши деньги.
Любой настоящий программист в первую очередь думает об оптимизации
Они — нет, а оптимизатор байта — да.
Раньше время работы компьютера было дороже, чем время работы программиста, да и программы меньше.
Л - Логика, сынок а ты не думаешь что программы были меньше именно потому что все писали с "головой", а не качали кучу зависимостей и фреймворков чтобы вывести хеллоу ворд
Л - Лениво думать.
Описание современных так называемых программистов
Ну дык некогда думать, смузи ждёт.
любители смузи совсем разучились думать.
думать могут только нелюбитили смузи с опеннет.
Программы были не только меньше, они были ПРОЩЕ. Не все современные программы ограничиваются «hello world», знаете ли.
Простота залог надёжности. Гуманитарии, палитесь же, сразу видно человек написавший это не имеет технического образования и соответствующего склада ума.
Что ещё ожидать от растоманов
Что еще ожидать от современных диградирующих погромистов?
Наизобретали всяких там rust, java и других скриптовых языков с проверками границ массива, а теперь и из С делают скриптовый язык. Позор!
Настоящим экспертам-программистам с опеннет достаточно только нескритового С и ассемблера чтобы написать всё что угодно.
Ввести массивы на уровне языка? Нееее, мы всё в рантайме проверять будем!
Уточните пожалуйста что это за конструкция языка С++?
int notArray[] = {1, 2, 3};
Не поверишь... Это указатель с гранулярностью размера int.
#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Если [] указатель, то почему он такой большой?
#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 :-(
И это при том что размер массива сохраняется для оператора delete
delete[], учитель
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; размер указателя в зависимости от битности ОС
int notArray[] = {1, 2, 3} - это статический массив. std::vector - разновидность динамического. И там всё но указателях. Если бы была сущность на уровне языка, да, можно было бы в ряде случаев определять выход за границы статически, или минимизировать количество динамических проверок.
Опеннет эксперт утверждает что в Си++ нет массивов. На опеннет настоящие программисты и они врать не будут.
Не будут. Анон сказал же что это указатель с гранулярностью в int (про гранулярность красиво сказано). Спор ниачем развели тут. Да у язык не проверяет границы массива, о чувак но язык же не проверяет выход за границы, хахаха аноны такие эксперты и врать не будут . Это новый уровень дизонанса ?
Настоящим экспертам-программистам с опеннет проверки не нужны.
Причем тут эксперты, зачем перекладывать на ресурсы процессора то что ты можешь сделать головой зарананее, хотя судя по сутации в мире, думать головой не умеют
Интеллект с опеннет тут же подтвердил это утверждение.
Настоящие программисты осталось только здесь
Ахаха, мы все прекрасно видим как эти головы работают))
Судя по ситуации на опеннет думать головой здесь умеют 3-4 человека
Шиз, как ты этих 3-4 чела вычислил на анонимной борде
Дурачку, тут регистрация есть и они зарегистрированы
Зашёл CVE на сайт, на котором постят часто новости про CVE, чтобы напомнить, что CVE никуда не денутся из-за языка, который спроектирован так, чтобы человеческий фактор формировать CVE был всю жизнь, а любые методы предотвращения CVE критиковались такими же CVE-создателями.
Растоманы и прочие считающие себя программистами персонажи этого не понимают
> предлагается использовать классы std::array, std::vector и std::spanСто лет в обед работает. Но да, тем кто не читает про обновление в стандартах лишний раз ткнуть носом не помешает. Сюда ещё range based loop добавить надо.
> корректировки кода, позволяющий заменять переменные с голыми указателями на контейнеры
А вот это молодца
Зачем добавлять в компилятор лишние проверки замедляющие сбору программ если настоящим программистам они не нужны?
Не кому нужны проверки не программисты и должны уйти из профессии.