The OpenNET Project / Index page

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



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

"Оценка эффективности применения MiraclePtr для предотвращения уязвимостей в Chrome "  +/
Сообщение от opennews (??), 23-Янв-24, 16:23 
Компания Google проанализировала эффективность использования в коде на языке С++ типа MiraclePtr (raw_ptr‹T›) вместо обычных указателей для защиты от  уязвимостей, вызванных обращением к уже освобождённым областям памяти (use-after-free). MiraclePtr предоставляет обвязку над указателями, выполняющую дополнительные проверки и аварийно завершающую работу в случае обнаружения обращения к освобождённым областям памяти. Поддержка MiraclePtr была включена по умолчанию на платформах Windows и Android в мае 2022 года (в Chrome 102), а на платформах ChromeOS, Linux и macOS в июне 2023 года. Защита на базе MiraclePtr в  Chrome применяется для всех процессов, кроме процесса, отвечающего за отрисовку (renderer)...

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

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

Оглавление

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


1. "Оценка эффективности применения MiraclePtr для предотвращени..."  +9 +/
Сообщение от Аноним (-), 23-Янв-24, 16:23 
В общем Чуда не произошло.
Накладные расходы в 5.5-8% потребления памяти и торможение на 1.5% думаю допустимы, но неприятны.
Особенно учитывая улучшение 'немного лучше 50%' - "защиту от 57% уязвимостей класса use-after-free"

Может после этого попросят андроид команду поделиться опытом испроьзования Rust.

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

4. "Оценка эффективности применения MiraclePtr для предотвращени..."  –5 +/
Сообщение от _kp (ok), 23-Янв-24, 16:50 
А в Rust безопасный код типа только при компиляции проверяется?
Ответить | Правка | Наверх | Cообщить модератору

39. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (39), 23-Янв-24, 23:08 
Можно было уже прочитать хотя бы википодию.
Ответить | Правка | Наверх | Cообщить модератору

69. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от 12yoexpert (ok), 24-Янв-24, 22:59 
не читайте во время еды, там есть примеры синтаксиса
Ответить | Правка | Наверх | Cообщить модератору

76. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (76), 25-Янв-24, 03:23 
Если бы ты сам почитал хотя бы википедию, то знал бы, что во время выполнения программы также выполняются некоторые проверки безопасности. Например, при обращении к срезам (slices) или использовании небезопасных функций и блоков кода, Rust может проверять индексы, границы массивов и другие условия безопасности. Естественно, небесплатно.
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

24. "Оценка эффективности применения MiraclePtr для предотвращени..."  +2 +/
Сообщение от Аноним (24), 23-Янв-24, 20:08 
> Может после этого попросят андроид команду поделиться опытом испроьзования Rust.

Так поделились же год назад. Надо свежЕе? Предполагаю не сильно статистика поменялась. Кратко: в андроидовском раст-коде ошибок работы с памятью (это не только use-after-free, но и всякие выходы за границы буфера, двойное освобождение и прочее ) - ровно ноль. Это в 1.5 млн строк кода разных системных компонент, 21% всего нового нативного кода системы. Собираются и дальше выкидывать си/плюсы и внедрять больше раста. Уже даже посматривают и облизываются на раст-подсистему, создаваемую в линукс-ядре. Короче, очень довольны растом:

https://security.googleblog.com/2022/12/memory-safe-language...

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

25. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (-), 23-Янв-24, 20:19 
Не, рамарка была про "андроид команда своими программерами делиться не захочет, а своих еще переучить нужно или новых набрать".

С другой стороны, я видел их отчет по поводу "Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022"
и там людей с переучивали весьма быстро.

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

73. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Прадед (?), 25-Янв-24, 02:11 
Вообщетики двойное освобождение тоже юз афта фри
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

26. "Оценка эффективности применения MiraclePtr для предотвращени..."  +2 +/
Сообщение от Аноним (26), 23-Янв-24, 20:24 
57% это даже не стакан на половину пуст, а пуст на 7 % меньше чем на половину
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

34. "Оценка эффективности применения MiraclePtr для предотвращени..."  +2 +/
Сообщение от Минона (ok), 23-Янв-24, 22:27 
Fields Medal этому господину!
Ответить | Правка | Наверх | Cообщить модератору

55. "Оценка эффективности применения MiraclePtr для предотвращени..."  +1 +/
Сообщение от n00by (ok), 24-Янв-24, 11:51 
> стакан на половину пуст

Стакан априори пуст (с завода-изготовителя). Если в нём что-то есть, значит, его наполняли. То есть единственно верная оценка: стакан наполовину полон. Кто заявляет обратное, у того проблемы с пониманием проходящего.

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

70. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от 12yoexpert (ok), 24-Янв-24, 23:00 
> Может после этого попросят андроид команду поделиться опытом испроьзования Rust.

думаю, просто перейдут на firefox

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

81. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Бывалый смузихлёб (?), 25-Янв-24, 10:47 
> внедрение MiraclePtr предоставило защиту от 57% уязвимостей класса use-after-free
> для указателей требуется хранить дополнительные 4 байта со счётчиком ссылок

Ну вообще-то, очень неплохо. Весьма незначительными изменениями сделали раст наполовину не нужным даже теоретически.
Такими темпами может оказаться, что на него и даром не надо ничего переписывать, ведь сверхъестественными способностями он не обладает

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

2. "Оценка эффективности применения MiraclePtr для предотвращени..."  +8 +/
Сообщение от anonymmm (?), 23-Янв-24, 16:34 
The owner of the memory must free it when the time is right, don‘t assume raw_ptr<T> will free it for you (it won’t). Unlike std::unique_ptr<T>, base::scoped_refptr<T>, etc., it does not manage ownership or lifetime of an allocated object.
if the pointer is the owner of the memory, consider using an alternative smart pointer.


Так я не понял, а почему они просто std::unique_ptr и прочие smart указатели из стандартной библиотеки не используют.

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

5. "Оценка эффективности применения MiraclePtr для предотвращени..."  –1 +/
Сообщение от topin89 (ok), 23-Янв-24, 16:53 
Как ни странно, даже unique_ptr'ы небесплатные: https://youtu.be/rHIkrotSwcc?t=1054
Ответить | Правка | Наверх | Cообщить модератору

38. "Оценка эффективности применения MiraclePtr для предотвращени..."  +1 +/
Сообщение от Аноним (38), 23-Янв-24, 23:08 
А миракл птр бесплатное?
Ответить | Правка | Наверх | Cообщить модератору

57. "Оценка эффективности применения MiraclePtr для предотвращени..."  –2 +/
Сообщение от n00by (ok), 24-Янв-24, 11:55 
Это психологический треннинг? Если пример кода (на 19:32) поместить в реальный мир, то foo() будет встроена, с соответствующей оптимизацией.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

71. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от 12yoexpert (ok), 24-Янв-24, 23:07 
ну да, нафиг стандарты. аноним гарантирует, что "будет встроена"
Ответить | Правка | Наверх | Cообщить модератору

78. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от n00by (ok), 25-Янв-24, 10:10 
Аноним пусть делает, что хочет. Я велосипедил std::unique_ptr<> до принятия в стандарт и очень внимательно изучал генерируемые MSVC 7-й версии листинги. Потому для себя выводы сделал ещё тогда, а с тех пор оптимизаторы шагнули вперёд. Пользуясь случаем, передаю привет секте свидетелей экономии углеродного следа за счёт разделяемых библиотек.
Ответить | Правка | Наверх | Cообщить модератору

6. "Оценка эффективности применения MiraclePtr для предотвращени..."  +1 +/
Сообщение от 12yoexpert (ok), 23-Янв-24, 16:56 
это аналоги обычных std-шных указателей, только с тормозными проверками, принудительным падением и крешдампом
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

18. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от unix greybeard (?), 23-Янв-24, 19:22 
Вероятно для этого придется переписывать слишком много кода. А так можно просто заменить обычные указатели на raw_ptr и заиметь Профит.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

43. "Оценка эффективности применения MiraclePtr для предотвращени..."  +1 +/
Сообщение от mister_0 (?), 23-Янв-24, 23:52 
но если всё переписать на unique, shared и weak ptrs, то double free и use after free станут невозможными, разве это не профит???
Ответить | Правка | Наверх | Cообщить модератору

50. "Оценка эффективности применения MiraclePtr для предотвращени..."  +2 +/
Сообщение от 12yoexpert (ok), 24-Янв-24, 00:51 
разыменовывать нулевые smart pointers законом запретили? кажется, я что-то пропустил
Ответить | Правка | Наверх | Cообщить модератору

59. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от anonymmm (?), 24-Янв-24, 12:08 
такое разименование легко заменить, процесс грохнется с pagefault, проблема же, что используются адреса, по которым уже освобождён объект и состояние памяти в неизвестном состоянии.
Ответить | Правка | Наверх | Cообщить модератору

61. "Оценка эффективности применения MiraclePtr для предотвращени..."  –1 +/
Сообщение от n00by (ok), 24-Янв-24, 12:17 
> используются адреса, по которым уже освобождён объект

Очень хочется увидеть пример кода для unique_ptr<>.

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

60. "Оценка эффективности применения MiraclePtr для предотвращени..."  –1 +/
Сообщение от n00by (ok), 24-Янв-24, 12:15 
> разыменовывать нулевые smart pointers законом запретили?

20.11.1.2.4  Observers  [unique.ptr.single.observers]

add_lvalue_reference_t<T> operator*() const;

1 Preconditions: get() != nullptr.

2 Returns: *get().


16.5.4.11  Expects paragraph  [res.on.expects]

1 Violation of any preconditions specified in a function’s Preconditions: element results in undefined behavior.

> кажется, я что-то пропустил

Совершенно точно. Момент, когда программистов заменили на пользователей библиотек и упаковщиков кода.

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

62. "Оценка эффективности применения MiraclePtr для предотвращени..."  +1 +/
Сообщение от 12yoexpert (ok), 24-Янв-24, 12:32 
> 1 Violation of any preconditions specified in a function’s Preconditions: element results in undefined behavior.

ты такой остряк, в квн не пробовал выступать?

специально для тебя разжую: что мешает ошибочно или специально разыменовать нулевой автоматический указатель? выше написано "то double free и use after free станут невозможными," - в каком месте use after free станет невозможным?

с появлением поколения "тред не читал, комментить побежал" мы и заимели electron и rust

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

66. "Оценка эффективности применения MiraclePtr для предотвращени..."  –2 +/
Сообщение от n00by (ok), 24-Янв-24, 17:23 
>> 1 Violation of any preconditions specified in a function’s Preconditions: element results in undefined behavior.
> ты такой остряк, в квн не пробовал выступать?
> специально для тебя разжую: что мешает ошибочно или специально разыменовать нулевой автоматический
> указатель?

Тебе ничего не мешает. Я могу это запретить - мне это разрешил стандарт:

3.30  [defns.undefined]  undefined behavior

behavior for which this document imposes no requirements

[Note 1 to entry: Undefined behavior may be expected when this document omits any explicit definition of
behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior
ranges from ignoring the situation completely with unpredictable results, to behaving during translation or
program execution in a documented manner characteristic of the environment (with or without the issuance
of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed.
Evaluation of a constant expression never exhibits behavior explicitly specified as undefined in Clause 4
through Clause 15 of this document (7.7). — end note]

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

68. "Оценка эффективности применения MiraclePtr для предотвращени..."  +1 +/
Сообщение от 12yoexpert (ok), 24-Янв-24, 20:38 
> Тебе ничего не мешает. Я могу это запретить - мне это разрешил стандарт:

ясно, ты тугенький на отсутствующий ум. даже не знаю, можно ли такому овощу слив засчитать

> в каком месте use after free станет невозможным?

у тебя ещё со зрением проблемы, сходи в военкомат проверь. маленькие дети так любят выцепить что-то из контекста и спорить с тем, что им нравится, а не с тем, что написано, мама дорогая

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

79. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от n00by (ok), 25-Янв-24, 10:25 
>>>> разыменовывать нулевые smart pointers законом запретили?
>>> 1 Preconditions: get() != nullptr.
>> в каком месте use after free станет невозможным?
> у тебя ещё со зрением проблемы

Прекрасно вижу, что ты принялся подменять _свой_ тезис, оказавшись в неудобном положении.

И передёргивать #43 ты принялся совершенно напрасно, поскольку автор, в отличие от тебя, умеет читать стандарт:

20.11.1.2.5  Modifiers  [unique.ptr.single.modifiers]

pointer release() noexcept;

1 Postconditions: get() == nullptr.

2 Returns: The value get() had at the start of the call to release.

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

80. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от anonymous (??), 25-Янв-24, 10:41 
Им раньше shared/unique ptr использовать религия не позволяла. Им их совсем недавно разрешили использовать (где-то в конце 2010-х).
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "Оценка эффективности применения MiraclePtr для предотвращени..."  –2 +/
Сообщение от Аноним (3), 23-Янв-24, 16:38 
Эффективность оценили, а приемлемость? Веб приложения и так работают небыстро.
Ответить | Правка | Наверх | Cообщить модератору

7. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (-), 23-Янв-24, 16:59 
"Просто обновите себе комп", как говорил Тодд-купи-скайрим-Говард)
С учетом развития железа, просто поставят в новый хромбук процессор на 5% мощнее.
Ну и скажут 'минимум 8/16 гигов оперативки'.
Ответить | Правка | Наверх | Cообщить модератору

33. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (33), 23-Янв-24, 22:27 
> просто поставят в новый хромбук процессор на 5% мощнее

На 3%, не более: жирный софт должен тормозить.

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

11. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (11), 23-Янв-24, 17:43 
> Веб приложения и так работают небыстро.

Можешь конкретные урлы назвать или так, от пацанов во дворе слышал?

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

15. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Самый Лучший Гусь (?), 23-Янв-24, 19:06 
Веб приложения работают достаточно быстро на современном железе. Я имею в виду железо хотя бы не старше 2014 года (Lenovo ThinkPad T440p)
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

8. Скрыто модератором  +7 +/
Сообщение от Mr.Who (?), 23-Янв-24, 17:26 
Ответить | Правка | Наверх | Cообщить модератору

9. Скрыто модератором  +/
Сообщение от Аноним (9), 23-Янв-24, 17:38 
Ответить | Правка | Наверх | Cообщить модератору

10. Скрыто модератором  –1 +/
Сообщение от Аноним (-), 23-Янв-24, 17:42 
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

23. Скрыто модератором  +3 +/
Сообщение от Аноним (23), 23-Янв-24, 19:46 
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

13. "Оценка эффективности применения MiraclePtr для предотвращени..."  +2 +/
Сообщение от ox (?), 23-Янв-24, 18:43 
> для защиты от уязвимостей, вызванных обращением к уже освобождённым областям памяти

Может, учебник по С++ почитать?

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

14. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (9), 23-Янв-24, 19:01 
какой посоветуете?
Ответить | Правка | Наверх | Cообщить модератору

46. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от 12yoexpert (ok), 24-Янв-24, 00:44 
How to program c++, Харви Дейтел, Пол Дейтел (одно из первых изданий, жёлтая обложка), там хорошо объясняются актуальные до сих основы языка и вообще программирования (у меня до сих пор переводы систем счисления от зубов отскакивают), чего нет в новых изданиях

Deitel P., Deite H. C++20 for Programmers 3ed 2021

Худшее, что видел - все книги скотта мейерса, бесполезный набор букв, и все книги от o'really - бесполезный мусор (не только по плюсам)

Потом можно по приколу почитать александреску, страуструпа по плюсам или всяких кнутов по алгоритмам, но, скорее всего, ты уже начнёшь кодить и будешь сам знать, что тебе читать.

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

16. "Оценка эффективности применения MiraclePtr для предотвращени..."  +1 +/
Сообщение от Аноним (16), 23-Янв-24, 19:08 
И как это поможет от обычных человеческих ошибок? Или ты из тех самых «настояших сишников», которые ошибок никогда не допускают?
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

17. "Оценка эффективности применения MiraclePtr для предотвращени..."  +1 +/
Сообщение от Аноним (-), 23-Янв-24, 19:22 
Ты сначала научись отличать си плюс-плюсника от чистосишника.
Ответить | Правка | Наверх | Cообщить модератору

47. "Оценка эффективности применения MiraclePtr для предотвращени..."  +2 +/
Сообщение от 12yoexpert (ok), 24-Янв-24, 00:46 
уже лет двадцать народ сначала учит плюсы, потом си
Ответить | Правка | Наверх | Cообщить модератору

20. "Оценка эффективности применения MiraclePtr для предотвращени..."  +1 +/
Сообщение от Карлос Сношайтилис (ok), 23-Янв-24, 19:25 
Zero-cost абстракции, говорили они
Ответить | Правка | Наверх | Cообщить модератору

36. "Оценка эффективности применения MiraclePtr для предотвращени..."  –2 +/
Сообщение от Минона (ok), 23-Янв-24, 22:32 
Это в расте говорили.
В плюсах их нет.
Ответить | Правка | Наверх | Cообщить модератору

48. "Оценка эффективности применения MiraclePtr для предотвращени..."  +2 +/
Сообщение от 12yoexpert (ok), 24-Янв-24, 00:47 
это как бы основная фишка плюсов, есличо
Ответить | Правка | Наверх | Cообщить модератору

64. "Оценка эффективности применения MiraclePtr для предотвращени..."  –2 +/
Сообщение от Минона (ok), 24-Янв-24, 14:11 
> это как бы основная фишка плюсов, есличо

Основная фишка С/С++ - UB.

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

65. "Оценка эффективности применения MiraclePtr для предотвращени..."  +1 +/
Сообщение от 12yoexpert (ok), 24-Янв-24, 16:04 
кто ж вас, детей, так запугал этим UB? из каждого утюга о нём кукарекаете
Ответить | Правка | Наверх | Cообщить модератору

67. "Оценка эффективности применения MiraclePtr для предотвращени..."  –1 +/
Сообщение от n00by (ok), 24-Янв-24, 17:36 
> кто ж вас, детей, так запугал этим UB?

Вон в #62 эксперт меня пугал.

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

77. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (77), 25-Янв-24, 09:47 
Пугает время на поиск и отладку проблемы, потраченные нервы пользователей, не говоря уже возможных финансовых и репутационных потерях. Хеловорды конечно можно абыкак и на абычом писать.
Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

83. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Минона (ok), 25-Янв-24, 15:26 
> кто ж вас, детей, так запугал этим UB? из каждого утюга о
> нём кукарекаете

Сам создатель.

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

86. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Карлос Сношайтилис (ok), 26-Янв-24, 21:14 
В расте сделали, а в плюсах говорили. Не перепутай
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

22. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (22), 23-Янв-24, 19:40 
>так как для указателей требуется хранить дополнительные 4 байта со счётчиком ссылок.

Чем это отличается от std::shared_ptr?

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

28. "Оценка эффективности применения MiraclePtr для предотвращени..."  –1 +/
Сообщение от Аноним (26), 23-Янв-24, 20:49 
Для shared_ptr хранить нужно больше, да ещё по умолчанию и в отдельном чанке памяти, Садись, два
Ответить | Правка | Наверх | Cообщить модератору

44. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от mister_0 (?), 23-Янв-24, 23:53 
с shared будет 100% багов пофикшено, а так только 57% остальные для performance review на следующий год
Ответить | Правка | Наверх | Cообщить модератору

63. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (26), 24-Янв-24, 12:48 
Передача указателя по указателю может же быть не просто так. Собственно, вопрос чтобы вытянуть на троекчку: какая новая бага может появиться, если все такие сырые указатели заменить на shared_ptr сссылки?
Ответить | Правка | Наверх | Cообщить модератору

82. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от anonymous (??), 25-Янв-24, 11:42 
О каких таких сырых указателях идет речь? Гугл использует собственную реализацию shared_ptr, вопрос заключался в том, а почему сразу не использовать их вместо собственной реализации неизвестного радиуса кривизны?
Ответить | Правка | Наверх | Cообщить модератору

85. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (26), 25-Янв-24, 21:16 
Гугл может и использует свою реализацию google::shared_ptr, как и многие другие древние компании, т.к. гугл существует много дольше чем с++11 с std::shared_ptr. Однако научить же читать, выше речь не о shared_ptr.
Ответить | Правка | Наверх | Cообщить модератору

84. Скрыто модератором  +/
Сообщение от Аноним (-), 25-Янв-24, 18:07 
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

29. "Оценка эффективности применения MiraclePtr для предотвращени..."  –1 +/
Сообщение от лютый жабби.... (?), 23-Янв-24, 20:51 
хромоног просто ужасен - запускаю его всегда из консоли, за несколько часов "работы" несколько экранов всяких failed, unable итд.... а периодически закрывается с сегфолтом.

хромиум что дебианий, что арчевский - один фиг. значит не в сборщиках дело, а в косом гугле

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

30. "Оценка эффективности применения MiraclePtr для предотвращени..."  –1 +/
Сообщение от Аноним (26), 23-Янв-24, 20:57 
Ну запусти теперь так ФФ. У него уже, например, несколько десятков последних релизов табы зависают
Ответить | Правка | Наверх | Cообщить модератору

32. "Оценка эффективности применения MiraclePtr для предотвращени..."  +2 +/
Сообщение от Печенька (?), 23-Янв-24, 22:13 
> Кроме того, при использовании MiraclePtr зафиксированы отдельные регрессии, приводящие к снижению производительности, но не связанные с ключевыми метриками, такими как время загрузки и отрисовки страницы.

Я может что не понимаю, но какая метрика ключевая для программы, которая загружает и отрисовывает страницы?

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

35. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (33), 23-Янв-24, 22:29 
А отстукивать в гугло-сервисы кто будет?
Ответить | Правка | Наверх | Cообщить модератору

37. "Оценка эффективности применения MiraclePtr для предотвращени..."  –2 +/
Сообщение от Минона (ok), 23-Янв-24, 22:36 
Гугель, зачем страдать, переписывайте движок на расте!
Ответить | Правка | Наверх | Cообщить модератору

42. "Оценка эффективности применения MiraclePtr для предотвращени..."  +2 +/
Сообщение от Аноним (42), 23-Янв-24, 23:42 
Так может тогда просто взять Vala?
Ответить | Правка | Наверх | Cообщить модератору

51. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (51), 24-Янв-24, 05:46 
Не даром же говорят «не е… вола».
Ответить | Правка | Наверх | Cообщить модератору

74. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Прадед (?), 25-Янв-24, 02:19 
Слишком изысканно
Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

52. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (52), 24-Янв-24, 08:55 
30 придумывают разные виды указателей, и угомониться никак не могут, и даже расширили синтаксис метапрограммирования. Вот уж действительно С++ - это Си на костылях. Вместо того, что бы переложить управление памятью на среду выполнения, они непрерывно создают макросы для реализации очередной разновидности указателей, которые "ни такие как те, что были раньше, а намного лучше и безопаснее".
Ответить | Правка | Наверх | Cообщить модератору

53. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от tty0 (?), 24-Янв-24, 09:21 
Вместо того, чтобы переложить мыслительный процесс на человека, продолжают говнокодить и терять указатели.
Ошибки и опечатки случаются, но искать их должен компилятор. И не так как в расте.
Ответить | Правка | Наверх | Cообщить модератору

72. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Tron is Whistling (?), 24-Янв-24, 23:20 
Miracl'ов не бывает. Потеря производительности кстати копеечная.
Ответить | Правка | Наверх | Cообщить модератору

75. "Оценка эффективности применения MiraclePtr для предотвращени..."  +/
Сообщение от Аноним (76), 25-Янв-24, 03:20 
>While there are performance costs associated with the implementation of MiraclePtr, our analysis suggests that the benefits in terms of security improvements far outweigh these. We are committed to continually refining and expanding the feature to cover more areas.

Короче гуглятам понравилось, будут пользоватся. Еще бы, половина проблем с памятью решена почти бесплатно, память сейчас дешевая.

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

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

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




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

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