Rsa97, Ладно, фиг с ними с инструкциями ассемблера. Я могу представить, что там на выходе будет. Просто сейчас в мире такая шумиха по поводу безопасности, я и думаю что там такого в коде должно быть, чтобы не приводить как минимум к ошибкам при работе с памятью ну или там к эксплойтам.
И вот про такие функции как strcpy, которые не проверяют ничего. Если к примеру размер буфера будет только во время выполнения известен, то проверка нужна обязательно в таких случаях? Это же распространенный случай, когда на момент компиляции что-то не известно.
Василий Дёмин, Ну я вопрос в общем виде задавал. Потому, что в большинстве случаев это имеет отношение именно к компиляторам. В данном случае у меня MS Visual C++. Там только заголовочные файлы в библиотеке из исходного кода. От Майкрософт исходники открыты, чтобы скачать? Или смотреть сразу GNU Compiler Collection?
И мне не исходный код нужен, а код, который процессор выполнять будет. Мне надо посмотреть неужели какая-то одна инструкция обеспечивает прям полную защиту от хакинга с буфером.
Василий Дёмин, В C++ будет делать проверки, если Вы используете at(). И мне нужно видеть какие именно инструкции машинного кода используются для этого. Я ожидаю что-то наподобие jmpcc инструкций. Лишние инструкции снижают производительность, а bound check elimination компилятор не всегда делает. И не понятно для каких паттернов выражений это будет работать. И надежды на fusion микрооперации в процессоре нет. Они не для всех инструкций реализованы и когда две инструкции в конвейере, то первая сработает, а вторая нет. (Это из описания этих микроопераций)
Спасибо.
Можно вопрос?
А какое различие у функций вообще, если в одной тип параметра &Box и в него мы передаем b, который имеет тип Box от параметра просто &i32? Я имею ввиду какой предпочтительней? Ну я понимаю, что в &i32 можно передать как i32 так и Box, а в первый вариант только Box получается? Надеюсь понятно написал ^^.
И если надо просто адрес проверить, то есть вывести на экран, то лучше использовать "{:p}" для этого? И не мучиться с системой типов? А то там вечно as_ptr() разбросаны по библиотеке и еще компилятор жалуется.
mayton2019, Логичный вопрос. У таких языков есть системные методы, чтобы в объект положить что-нибудь во время выполнения. Прям функции такие есть.
Тут вообще получается, что после изменения иерархии надо еще будет забыть о предыдущей иерархии, переделать объекты под новую и начать использовать объекты в соответствии с новой. Трудно поддерживать.
А еще некоторые языки позволяют изменять системные переменные...
mayton2019, Вообще-то это я задаю вопрос "Зачем это надо?" Ну я привел маленький конкретный пример. Для общего случая не знаю. Да и шаблоны, насколько мне известно, созданы для статически типизированных языков. В динамически типизированных там во многих паттернах надобности нет.
Видимо имелось в виду изменение отношений класс <- подкласс. То есть класс A является базовым классом для класса B. Это в исходном коде. А потом во время выполнения: Отсоединяем класс B от класса A и делаем класс B подклассом класса C. Одиночное наследование. Я только могу представить применение этому как в каком-нибудь фреймворке, к примеру. Конструктор для исходного кода и там ты в работающей программе меняешь ее код. Ну наподобие Smalltalk.
Это потому, что в сигнатуре метода есть заимствование по изменяемой ссылке? И поэтому включается as_mut()? А ссылка на массив это срез на массив. И у него уже есть метод get_unchecked_mut? Так ведь? Я про свой пример
mayton2019, Что тут делает unsafe код как раз понятно. Вопрос был в другом. Я не нашел описание этого метода для массива. Он для другого типа числится. Пример взят из Rust Playground. Там если на знак вопроса нажать выскочит документация. Это для инструмента Miri. Он вроде как должен отлавливать такие вещи. А вообще для Rust есть множество крейтов, у которых в коде используются вставки на ассемблере, к примеру. Пример нашёл сам. Я пока изучаю. Вообще хотел бы быть там, где используют C/C++, Rust. Где с памятью вручную можно работать. Уж не знаю потяну ли написание ядер операционных систем, у них до сих пор C используется и очень низкоуровневый код, но к примеру игровые движки попробовал бы разрабатывать. О компьютерной графике представление отличное. Я ее с 14 лет изучал.
Ну как я понимаю в примере с Матлабом там внутри встроено решение систем линейных уравнений. Задал систему, написал x = A / b и ответ готов.
А про Haskell Вы написали, то о чем я и говорил. Сами пишите алгоритм(вычисление). Это не декларативно.
Понимаете, в определении понятия Декларативная парадигма я вижу противоречие из-за строчки, что в этой парадигме предполагается задать только условие задачи, а не ее ход решения. Это даже не связано с лямбда исчислением. Это как будто речь просто об автоматизации идет. Кто это написал? Тогда уж лучше противопоставлять императивное и функциональное. У них разные формальные системы в основе.
Пример с Матлабом выглядит декларативно, а Хаскелл нет, просто функционально.
Или тогда уж слова о автоматическом решении в определении надо убрать, а то противоречие получается.
Оставить его для логических систем, доказывающих теоремы самостоятельно. https://news.ycombinator.com/item?id=16424083 https://softwareengineering.stackexchange.com/ques...
Какое-то определение термина получается немного ошибочное из-за этого.
А так понятно. Спасибо за ответ
И вот про такие функции как strcpy, которые не проверяют ничего. Если к примеру размер буфера будет только во время выполнения известен, то проверка нужна обязательно в таких случаях? Это же распространенный случай, когда на момент компиляции что-то не известно.