именно поэтому доступ к нему требует координации через протокол когерентности
Доступ к L3 не требует никакой координации. Но L3 выступает той самой шиной, по которой эта когерентность обеспечивается, да. Но когерентность обеспечивается между L1, L2 кэшами, при этом сам L3 кэш точно такая же коробка с игрушками. С той лишь разницей, что рядом стоит дядя с журналом и записывает кто и что оттуда взял/положил.
Однажды на одном из собеседований, меня спросили, ключевые отличия между new и malloc, вопрос интересный, так что я также хотел бы затронуть его в этой статье.
Ключевое отличие new от malloc в том, что new начинает object lifetime, а malloc нет. И reinterpret_cast тоже не начинает. Рекомендую копнуть в такие чудесные вещи как std::launder и std::start_lifetime_as.
Также new, помимо прочего, гарантирует корректное выравнивание для аллоцируемой памяти под объект, в обычный malloc - нет (но у него есть aligned версия).
Отчего, кстати, примерно все касты в ваших примерах и последующая запись в кастуемую память - UB.
Я не шибко активно слежу за развитием Rust, но насколько мне известно в stable ветке нет поддержки per-container аллокаторов (в стандартной библиотеке). ChatGPT тоже не может дать примеров.
ИМХО, главная проблема C++ных исключений в их высокой стоимости
А вы хоть раз измеряли? На практике, до момента срабатывания они не стоят ничего. Но... Они ведь на то и исключения)
Я бы сказал, что коды возврата даже подороже будут, ибо из-за постоянных проверок на каждом уровне вложенности дают погрустить предсказателю переходов.
Следом за этим еще и перегрузка операторов идет в пешее эротическое.
И часто она вам нужна, для не арифметических типов (или обертами над ними)? Ну сделайте MyType::ToString и живите щастливо. Современные стандартные API для печати один хрен не требуют перегрузки операторов.
Если в середине бизнес-логики есть какой-нибудь условный vector::push_back
А если нет? Оч странный у вас контраргумент. Да, в каких-то местах оно работает, в каких-то нет.
Бездумное обмазывание noexcept -- прямой путь к внезапным падениям, а не к плюсам в производительности.
Не, ну если бездумное, то конечно, но если ваш код не бросает исключений, то как бы... Вы уже подумали?) А если не подумали, то кто соббсно виноват?)
Остается пожелать самому себе никогда не иметь дело с кодом, написанным такими экспертами.
Chromium собирается без поддержки исключений и вполне себе популярен) Вроде нормальный код.
Впрочем, с вами бы я тоже не сработался) Вы какой-то очень эмоциональный)
Та в чем проблема-то? Исключения, в сущности, ничем не лучше и не хуже кодов возвратов (std::expected если угодно).
Разницы-то никакой по сути.
Ну, да, придется вместо MyType(...) писать MyType::Create(...). Велика ли потеря?
В остальном тож самое) Я бы даже сказал, есть много плюсов. Если ничего не может внезапно сломаться в середине бизнес логики, потребителю библиотеки надо меньше думать.
Плюсом можно обмазаться в API слое всякими noexcept и получить какие-никакие плюсы к производительности)
Нет у раста стандарта)) Ну да ладно, это мелочи. Когда уже завезут не глобальные аллокаторы, а отдельно под каждый контейнер? Мне вот совсем не нужно bump allocator для всей программы)
Расшифровать можно будет, если кому-то нужен будет именно трафик kenomimi. На DPI же никто не будет даже пытаться, поэтому протокол будет просто размечен как unknown.
Q-синтаксис работает и с массивами. Примерно так
Сработает как надо, но синтаксис получается немножко инопланетный, да
Доступ к L3 не требует никакой координации. Но L3 выступает той самой шиной, по которой эта когерентность обеспечивается, да. Но когерентность обеспечивается между L1, L2 кэшами, при этом сам L3 кэш точно такая же коробка с игрушками. С той лишь разницей, что рядом стоит дядя с журналом и записывает кто и что оттуда взял/положил.
За последние 20 лет я не видел ни одного реального окружения, где бы отсутствовал bash. Буквально ни одного случая.
Да меня всякий шелл - это bash, а там где не bash - всегда можно вызвать `bash - c`
Не делайте так! Не надо! А bash есть массивы, используйте их!
Эту буквально единственный вменяемый способ передачи флагов. Всё остальное - отлукавого
Вообще ещё есть capabilities :)
Ключевое отличие new от malloc в том, что new начинает object lifetime, а malloc нет. И reinterpret_cast тоже не начинает. Рекомендую копнуть в такие чудесные вещи как std::launder и std::start_lifetime_as.
Также new, помимо прочего, гарантирует корректное выравнивание для аллоцируемой памяти под объект, в обычный malloc - нет (но у него есть aligned версия).
Отчего, кстати, примерно все касты в ваших примерах и последующая запись в кастуемую память - UB.
Я не шибко активно слежу за развитием Rust, но насколько мне известно в stable ветке нет поддержки per-container аллокаторов (в стандартной библиотеке). ChatGPT тоже не может дать примеров.
Если я ошибаюсь, дайте пример на https://play.rust-lang.org
Я со временем пришел к тому, что если я делаю что-то третий раз - пора писать скрипт.
По моему личному опыту - все что делалось больше 2-3 лет назад по большей части не имеет никакого значения.
Ну, кроме совсем фундаментальных знаний конечно, но их одних недостаточно, чтобы получить приличную работу.
А вы хоть раз измеряли? На практике, до момента срабатывания они не стоят ничего. Но... Они ведь на то и исключения)
Я бы сказал, что коды возврата даже подороже будут, ибо из-за постоянных проверок на каждом уровне вложенности дают погрустить предсказателю переходов.
И часто она вам нужна, для не арифметических типов (или обертами над ними)? Ну сделайте MyType::ToString и живите щастливо. Современные стандартные API для печати один хрен не требуют перегрузки операторов.
А если нет? Оч странный у вас контраргумент. Да, в каких-то местах оно работает, в каких-то нет.
Не, ну если бездумное, то конечно, но если ваш код не бросает исключений, то как бы... Вы уже подумали?) А если не подумали, то кто соббсно виноват?)
Chromium собирается без поддержки исключений и вполне себе популярен) Вроде нормальный код.
Впрочем, с вами бы я тоже не сработался) Вы какой-то очень эмоциональный)
Та в чем проблема-то? Исключения, в сущности, ничем не лучше и не хуже кодов возвратов (std::expected если угодно).
Разницы-то никакой по сути.
Ну, да, придется вместо MyType(...) писать MyType::Create(...). Велика ли потеря?
В остальном тож самое) Я бы даже сказал, есть много плюсов. Если ничего не может внезапно сломаться в середине бизнес логики, потребителю библиотеки надо меньше думать.
Плюсом можно обмазаться в API слое всякими noexcept и получить какие-никакие плюсы к производительности)
Оч странно применять логику русского языка к жаргонизмам, которые ещё и калька с английского)
Мне вот слух не режут оба варианта) Что много фичей, что много фич)
Какой гемморой? Просто пиши без исключений и... Всё?
Хтож embedded разработкой из-под винды занимается)
Травма
Яндекс священный.
Подорожали тарифы. Раньше 5 тыщ было
Нет у раста стандарта)) Ну да ладно, это мелочи. Когда уже завезут не глобальные аллокаторы, а отдельно под каждый контейнер? Мне вот совсем не нужно bump allocator для всей программы)
Тоже улыбнулся) Такую херню сегодня мне самы модный ChatGPT 5.2 выдавал, я аж хохотал)
ХЗ. Я вижу не читаемые каракули и магические константы) Хотя читать ассемблер умею)
Расшифровать можно будет, если кому-то нужен будет именно трафик kenomimi. На DPI же никто не будет даже пытаться, поэтому протокол будет просто размечен как unknown.