Забавно, не ожидал таких результатов. 4 из 6, в остальных двух выбрал 320.
Наушники и USB DAC. Плюс постоянные наводки из-за работающего солнечного инвертора. Я не ожидал что смогу отличить WAV от MP3-320. Аж удивительно. Но на самом деле это ни на что не повлияет. Я все равно буду слушать пережатую музыку в Spotify/Google Music. Не в нюансах звучания щастье.
Я бы конечно мог сказать, что пока либа делает такую фигню только у себя в потрохах, то это внутренние проблемы либы. Но не буду я так говорить, ибо это уже goalpost moving.
catch_unwind не только существует, но к нему еще и существуют правила его использования. И основная его цель - это недопустить пролет растовской паники за пределы FFI. Это не замена try/catch. Документация явно об этом говорит.
Потому что нет Rust ABI. Нет его. Есть стандартный системный ABI который описывает как вызывать функции и как возвращать значения.
Что вы вообще так уцепились за эти исключения? Я говорил о том что С++ ABI не существует и в качестве одного примера сказал что нельзя бросаться исключениями.
Напоминаю, что все началось с вот этого комментария:
На C++ (как и на C) можно написать библиотеку и использовать её в десятках других ЯП. Rust так умеет?)
На что я совершенно резонно заметил что никакого С++ ABI нет. Все равно на стыках надо реализовывать всем понятный C-style ABI и соответственно никаких преимуществ у C++ перед C, Rust или там Fortran нет.
На всякий случай - я знаю что сейчас это невозможно/затруднено. Но если бы это был гипотетический unsafe javascript с возможностью гулять по всей памяти процесса - то было бы как я написал.
Не просто так. Они еще и написали когда это стоит использовать, а когда - не стоит. Но кто ж читает документацию, правда?
It is currently undefined behavior to unwind from Rust code into foreign code, so this function is particularly useful when Rust is called from another language (normally C). This can run arbitrary Rust code, capturing a panic and allowing a graceful handling of the error.
It is not recommended to use this function for a general try/catch mechanism. The Result type is more appropriate to use for functions that can fail on a regular basis. Additionally, this function is not guaranteed to catch all panics, see the “Notes” section below.
Если код в Rust кидает панику, значит он обнаружил где-то нарушение инварианта и состояние программы больше не консистентно. Ловить панику чтобы потом продолжить работу - не имеет смысла.
Ага, копайте дальше, в микроархитектуру процессора. Вы бы видели какие костыли городили в разных компонентах, начиная с ядра линукса и заканчивая прошивками чтобы митигировать Spectre и его друзей.
Ну это да. Помнится, в виндах тоже было что-то такое, хоть и менее навороченное. Но оно никак не мапится в собственно язык. Обычным try/catch такое не поймаешь, насколько я знаю. Разве что runtime library будет ловить вот такое системное исключение, заворачивать в соответствующий класс и бросать уже как исключение языка.
Потому что у математиков может подгореть от такого. "Сумма двух периодических сигналов - это всегда периодический сигнал" - правда.
А вот банально sin(x) + sin(x) = 2sin(x)
2sin(x) - это уже не синусоида. Это уже удвоенная синусоида. А если попробовать построить график чего-то более сложного то синусоиды вы там вообще не увидите:
Проблема в том, что вы не понимаете как оно работает. Но почему-то высказываете какие-то дикие теории.
Я написал "в первую очередь" потому что есть вы вдруг решите заменить USB3.0 кабель с помощью сетевой витой пары (где тоже как-бы есть 4 дифференциальные пары) то у вас скорее всего он не заработает.
А может сразу начинать с того, что качественно явление таки есть, но мы считаем, что количественно оно не стоит тех денег?
Окей, чем по вашему "качественный" USB кабель от "некачественного"? Как это будет влиять на звук?
"Другая история", потому что это влияет на зарядку. Там, знаете, токи большие ходят. Толщина провода на это прямо влияет.
Ну блин, из пайтона я тоже могу открыть /dev/mem , дернуть mmap и пойти гулять по памяти как захочу. По вообще всей память компьютера, заметьте. И что он теперь, небезопасный?
С# позволяет кастить сырые данные к управляемым объектам и обратно. Что, он тоже небезопасный?
Про яву не знаю, но думаю что тоже можно, если захочется.
Окей, считайте что "безопасные" это такое сокращение от "безопасные при работе с памятью". Так лучше? Собственно, это и имелось в виду, когда этот термин придумывали. Просто англоговорящие обожают все сокращать.
А Rust еще и дает нефиговые гарантии для многопоточности...
Ну я надеюсь вы не будете отрицать, что ошибки при работе с памятью не исключают логических ошибок? Вы же не утверждаете, если бы все писали все исключительно на C, то учетки никто не тырил бы и платежные данные не утекали б, правда?
Небезопасные языки добавляют еще один очень веселый класс ошибок, но никак не уменьшают количество других типов ошибок. Вот если бы все писали на Coq, например... Тогда да.
Забавно, не ожидал таких результатов. 4 из 6, в остальных двух выбрал 320.
Наушники и USB DAC. Плюс постоянные наводки из-за работающего солнечного инвертора. Я не ожидал что смогу отличить WAV от MP3-320. Аж удивительно. Но на самом деле это ни на что не повлияет. Я все равно буду слушать пережатую музыку в Spotify/Google Music. Не в нюансах звучания щастье.
Оставим это на совести авторов rustfmt.
Я бы конечно мог сказать, что пока либа делает такую фигню только у себя в потрохах, то это внутренние проблемы либы. Но не буду я так говорить, ибо это уже goalpost moving.
А что, в C++ по-другому разве? Move constructor точно так же копирует все данные из одного объекта в другой.
catch_unwindне только существует, но к нему еще и существуют правила его использования. И основная его цель - это недопустить пролет растовской паники за пределы FFI. Это не замена try/catch. Документация явно об этом говорит.Потому что нет Rust ABI. Нет его. Есть стандартный системный ABI который описывает как вызывать функции и как возвращать значения.
Что вы вообще так уцепились за эти исключения? Я говорил о том что С++ ABI не существует и в качестве одного примера сказал что нельзя бросаться исключениями.
Напоминаю, что все началось с вот этого комментария:
На что я совершенно резонно заметил что никакого С++ ABI нет. Все равно на стыках надо реализовывать всем понятный C-style ABI и соответственно никаких преимуществ у C++ перед C, Rust или там Fortran нет.
На всякий случай - я знаю что сейчас это невозможно/затруднено. Но если бы это был гипотетический unsafe javascript с возможностью гулять по всей памяти процесса - то было бы как я написал.
Не просто так. Они еще и написали когда это стоит использовать, а когда - не стоит. Но кто ж читает документацию, правда?
Если код в Rust кидает панику, значит он обнаружил где-то нарушение инварианта и состояние программы больше не консистентно. Ловить панику чтобы потом продолжить работу - не имеет смысла.
Паника, это такой
assert(false)на стероидах. Соответственно и дергать ее надо когда вы, как программист, обнаружили нарушенный инвариант.Ага, копайте дальше, в микроархитектуру процессора. Вы бы видели какие костыли городили в разных компонентах, начиная с ядра линукса и заканчивая прошивками чтобы митигировать Spectre и его друзей.
Ну это да. Помнится, в виндах тоже было что-то такое, хоть и менее навороченное. Но оно никак не мапится в собственно язык. Обычным try/catch такое не поймаешь, насколько я знаю. Разве что runtime library будет ловить вот такое системное исключение, заворачивать в соответствующий класс и бросать уже как исключение языка.
Легко! Ибо в Rust нет исключений.
И давно у С++ появилось стабильное ABI? Где бы об этом почитать?
Мне вот сильно интересно как поймать в Java исключение выброшенное из С++ либы.
Ну да, просто джаваскрипт от очередной веб-статискики/банера/etc сдампит ваши куки/вводимые пароли/номера карточек. Ничего страшного.
Потому что у математиков может подгореть от такого. "Сумма двух периодических сигналов - это всегда периодический сигнал" - правда.
А вот банально sin(x) + sin(x) = 2sin(x)
2sin(x) - это уже не синусоида. Это уже удвоенная синусоида. А если попробовать построить график чего-то более сложного то синусоиды вы там вообще не увидите:
https://www.desmos.com/calculator/2n72guvuk9
Сильно это похоже на синусоиду?
Проблема в том, что вы не понимаете как оно работает. Но почему-то высказываете какие-то дикие теории.
Я написал "в первую очередь" потому что есть вы вдруг решите заменить USB3.0 кабель с помощью сетевой витой пары (где тоже как-бы есть 4 дифференциальные пары) то у вас скорее всего он не заработает.
Окей, чем по вашему "качественный" USB кабель от "некачественного"? Как это будет влиять на звук?
"Другая история", потому что это влияет на зарядку. Там, знаете, токи большие ходят. Толщина провода на это прямо влияет.
Ну блин, из пайтона я тоже могу открыть
/dev/mem, дернутьmmapи пойти гулять по памяти как захочу. По вообще всей память компьютера, заметьте. И что он теперь, небезопасный?С# позволяет кастить сырые данные к управляемым объектам и обратно. Что, он тоже небезопасный?
Про яву не знаю, но думаю что тоже можно, если захочется.
Окей, считайте что "безопасные" это такое сокращение от "безопасные при работе с памятью". Так лучше? Собственно, это и имелось в виду, когда этот термин придумывали. Просто англоговорящие обожают все сокращать.
А Rust еще и дает нефиговые гарантии для многопоточности...
Или добавить еще два плюсика и получится C#
Или взять следующую букву алфавита и получится D. Который типа и является "безопасным С++", правда, не таким безопасным как Rust.
Ну я надеюсь вы не будете отрицать, что ошибки при работе с памятью не исключают логических ошибок? Вы же не утверждаете, если бы все писали все исключительно на C, то учетки никто не тырил бы и платежные данные не утекали б, правда?
Небезопасные языки добавляют еще один очень веселый класс ошибок, но никак не уменьшают количество других типов ошибок. Вот если бы все писали на Coq, например... Тогда да.