В США прекратили работу крупнейшие авиакомпании, среди которых United Airlines, Delta Airlines и American Airlines, они сообщили о проблемах со связью.
Глобальный IT-сбой затронул даже парки развлечений: в Осаке Universal Studios Japan сообщил о сбое системы продажи билетов, посетители публикуют фото закрытых магазинов и ресторанов
Американская авиакомпания United Airlines сообщила РИА Новости, что из-за глобального сбоя задержаны вылеты всех ее самолетов
В Индии на фоне глобального сбоя посадочные талоны в аэропортах заполняют вручную
Работа медицинских учреждений в Британии затронута масштабным сбоем у Microsoft
Все системы Сбербанка на фоне глобального сбоя у Microsoft работают штатно, никаких проблем не наблюдается, сообщила пресс-служба
Все информационные системы РЖД на фоне глобального IT-сбоя работают в штатном режиме, рассказали РИА Новости в компании
"Шереметьево" работает в штатном режиме на фоне массового IT-сбоя, рейсы на вылет и прилет, в том числе иностранных авиакомпаний, выполняются по расписанию
Глобальный сбой Windows не затронул работу российских АЭС, Росэнергоатом работает на импортонезависимом программном обеспечении, сообщили РИА
Лондонские аэропорты Лутон и Станстед сообщили о проблемах из-за сбоя, пассажиров регистрируют вручную
Все электронные системы МИД ОАЭ вышли из строя из-за глобального технического сбоя, сообщило министерство
Ростовская АЭС работает штатно, радиационный фон в норме, появившиеся сообщения об аварии — фейк, заявил "Росэнергоатом".
Блоки работают штатно, радиационный фон на уровне природного
T>Пол-мира лежит
А что это за crowdstrike? Он входит в состав винды по дефолту? А как же ВиндовсДефендер? А если не входит, то как им удалось все винды положить? Так много вопросов...
Как много веселых ребят, и все делают велосипед...
Здравствуйте, trrtrr, Вы писали:
T>Пол-мира лежит
Удивительно. Читая здешние перепалки на тему "винда vs линукс" или "виндовс все" думаешь, что все кроме десктопа на линуксе. Но как проблема с виндой, так встают вокзалы, банки, медучреждения и даже холодильники
Почему-то никого не заинтересовали ключевые вопросы:
1. Что это за мудаки и откуда выползли? Ни разу про эту шарашку не слышал до инцидента.
2. Какого хрена их говнософт установлен у всего крупного бизнеса США и не только? Неужели компании успешного успеха не самостоятельны, и подчиняются Блекроку-Вангарду по каждой мелочи? Ибо иных вариантов, кроме "их вынудили поставить софт clownstrike", что-то не просматривается.
ZZ>2. Какого хрена их говнософт установлен у всего крупного бизнеса США и не только?
Просто одно из популярных MDR (Managed Detection And Response) решений.
ZZ>Неужели компании успешного успеха не самостоятельны, и подчиняются Блекроку-Вангарду по каждой мелочи? Ибо иных вариантов, кроме "их вынудили поставить софт clownstrike", что-то не просматривается.
Здравствуйте, zx zpectrum, Вы писали: ZZ>Почему-то никого не заинтересовали ключевые вопросы: ZZ>1. Что это за мудаки и откуда выползли? Ни разу про эту шарашку не слышал до инцидента. ZZ>2. Какого хрена их говнософт установлен у всего крупного бизнеса США и не только? Неужели компании успешного успеха не самостоятельны, и подчиняются Блекроку-Вангарду по каждой мелочи? Ибо иных вариантов, кроме "их вынудили поставить софт clownstrike", что-то не просматривается. ZZ>Все только про Винду и Линукс однотипно шутят.
3. Почему в крупных компаниях этот говнософт сам бесконтрольно обновяется?
M>Просто одно из популярных MDR (Managed Detection And Response) решений.
Я теряюсь в догадках: как поделие, в котором появилось практически на 100% воспроизводимое обращение к нулевому указателю в режиме ядра, то есть не обладающее даже зачаточным контролем качества, стало популярным? Неужели, как и в случае с FTX и Theranos, журнашлюшкам заказали так написать?
M>Вот прямо вынудили.
A как ещё? Как вы это себе представляете? Безопасники воскликнули "о, какая полезная штука, давайте её установим", так что ли? Да бред же собачий. Для безопасника чем меньше на машинах third party-кода, тем более проприетарного и закрытого, тем более ядерного, тем более самообновляющегося — тем лучше.
M>>Просто одно из популярных MDR (Managed Detection And Response) решений. ZZ>Я теряюсь в догадках: как поделие, в котором появилось практически на 100% воспроизводимое обращение к нулевому указателю в режиме ядра, то есть не обладающее даже зачаточным контролем качества, стало популярным? Неужели, как и в случае с FTX и Theranos, журнашлюшкам заказали так написать?
я тоже не знаю. Возможно конкуренты ещё хуже.
Либо имела место нечестная конкуренция, что в случае крупных контрактов не редкость.
M>>Вот прямо вынудили. ZZ>A как ещё? Как вы это себе представляете? Безопасники воскликнули "о, какая полезная штука, давайте её установим", так что ли? Да бред же собачий. Для безопасника чем меньше на машинах third party-кода, тем более проприетарного и закрытого, тем более ядерного, тем более самообновляющегося — тем лучше.
Это же MDR. Т.е. это и есть безопасники на аутсорсе.
Managed Detection and Response (MDR) denotes outsourced cybersecurity services designed to protect your data and assets even if a threat eludes common organizational security controls.
M>я тоже не знаю. Возможно конкуренты ещё хуже. M>Либо имела место нечестная конкуренция, что в случае крупных контрактов не редкость.
Не исключено. Вообще, чем больше я узнаю про эту мудную шарашку, повязанную с глубинным государством, Доминионом, сервером Хиллари Клинтон, и лже-обвинениями Трампа в работе на Россию, тем больше волосы на сраке шевелятся. Малварью этих пидарасов добровольно протроянил себя почти весь западный бизнес-мир! Это же караул и ахтунг планетарного масштаба. Что называется, тащите сюда новые теории заговора: все старые оказались правдой. Ничуть не удивлюсь, если они втихаря провзаимодействовали с Intel ME, засадив терпилам буткиты -- а на такую глубину ручки независимых исследователей доберутся ой как нескоро, если вообще доберутся -- и обставили это как безобидный баг NULL pointer dereference.
M>Это же MDR. Т.е. это и есть безопасники на аутсорсе. M>
M>Managed Detection and Response (MDR) denotes outsourced cybersecurity services designed to protect your data and assets even if a threat eludes common organizational security controls.
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Почему-то никого не заинтересовали ключевые вопросы:
У нас есть интернет и гугл и мы легко нашли ответы на эти вопросы.
1) Если ты о чем-то не слышал, не значит что это шаражка
2) Их софт установлен не везде. Есть несколько компаний конкурентов которые *пока* так не офакапились.
КБ>У нас есть интернет и гугл и мы легко нашли ответы на эти вопросы.
Гугель отвечает на запрос "white family" так, что рука тянется к оружию. Так что извини, я себя не на помойке нашел, чтобы пользоваться этой машиной лжи и дезинформации.
КБ>1) Если ты о чем-то не слышал, не значит что это шаражка
О, а вот и адвокаты клоунов у пидарасов подтянулись. Про FTX и Theranos мне так же в своё время говорили: кококо, такие уважаемые конторы, Financial Times о них пишет, а ты кто такой вообще, чтобы о них не слышать.
КБ>2) Их софт установлен не везде. Есть несколько компаний конкурентов которые *пока* так не офакапились.
Ключевое слово "пока".
Здравствуйте, zx zpectrum, Вы писали:
КБ>>У нас есть интернет и гугл и мы легко нашли ответы на эти вопросы. ZZ>Гугель отвечает на запрос "white family" так, что рука тянется к оружию. Так что извини, я себя не на помойке нашел, чтобы пользоваться этой машиной лжи и дезинформации.
Лучше чем получать информацию от голосов в голове.
КБ>>1) Если ты о чем-то не слышал, не значит что это шаражка ZZ>О, а вот и адвокаты клоунов у пидарасов подтянулись. Про FTX и Theranos мне так же в своё время говорили: кококо, такие уважаемые конторы, Financial Times о них пишет, а ты кто такой вообще, чтобы о них не слышать.
Мое утверждение это не опровергает.
КБ>>2) Их софт установлен не везде. Есть несколько компаний конкурентов которые *пока* так не офакапились. ZZ>Ключевое слово "пока".
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
КБ>>Ну видимо никому в голову не приходило что для сигнатур антивируса тоже стейджинг нужен.
C>Факап с дефендером никого ничему не научил. C>Тестировать? Да ну, глупость какая-то.
Если что в данной ветке возмущаются тем что админы раскатали обновление не проверив.
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Гугель отвечает на запрос "white family" так, что рука тянется к оружию. Так что извини, я себя не на помойке нашел, чтобы пользоваться этой машиной лжи и дезинформации.
Кстати, советую посмотреть "Социальную дилемму", если кто еще не смотрел.
Здравствуйте, SkyDance, Вы писали:
КБ>>Ну видимо никому в голову не приходило что для сигнатур антивируса тоже стейджинг нужен.
SD>Еще в 2008 году, когда я работал в Касперском, оно уже так было.
Если что в данной ветке возмущаются тем что админы пострадавших организаций раскатали обновление не проверив.
Здравствуйте, Константин Б., Вы писали:
КБ>А чего говорить то. Программисты на сишечке в очередной раз оказались программистами на сишечке.
Ага. Очередное продакшн-опровержение мифа о том, что "Мы и в С++ умеем обходиться без Null pointer dereference".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
КБ>>А чего говорить то. Программисты на сишечке в очередной раз оказались программистами на сишечке. S>Ага. Очередное продакшн-опровержение мифа о том, что "Мы и в С++ умеем обходиться без Null pointer dereference".
Действительно, ведь давно же можно драйвера для Windows писать на безопасном C# или каком-нибудь Spec#, но нет, сишники такие сишники. Или... Как это нельзя?
Здравствуйте, so5team, Вы писали: S>Действительно, ведь давно же можно драйвера для Windows писать на безопасном C# или каком-нибудь Spec#, но нет, сишники такие сишники. Или... Как это нельзя?
Не, это не про драйвера на C#, а про "зачем нам Rust?"
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
КБ>>А чего говорить то. Программисты на сишечке в очередной раз оказались программистами на сишечке. S>Ага. Очередное продакшн-опровержение мифа о том, что "Мы и в С++ умеем обходиться без Null pointer dereference".
Только проблема вылезла не в С++, а в бай-коде коде.
Т.е. это "ваши" подосрали, а не "наши".
Причём, этот сбой уже признан крупнейшим в истории.
Суть проблемы — подписанный и абсолютно исправный драйвер оказался способен исполнять внешний подгружаемый p-код.
Всё-таки, доигрались в "легко обновляемые байт-коды", дебилы, Б.
А вас неоднократно предупреждали, розовоочковые вы эльфы... ))
Т.е. дыра получилась инфраструктурная, из-за неверных принятых решений более высокого уровня, из-за недооценки связанных с этим рисков (ваш этот вечный оптимизм), а не из-за ошибок конкретного Васи-программера на С++.
Каждый в отдельности условный Вася никакой ошибки не допускал.
=============
Похоже, именно в этом и заключается разница программистов на С/С++ и программистов на "уютных" технологиях, т.е. разница сугубо мировоззренческая — "системщики" инстинктивно ожидают засады отовсюду, склонны к многочисленным перепроверкам, перфекционизму и маниакальной недоверчивости ко всему и вся.
И напротив, программеры из "уютных мирков" на фоне хардорщиков кажутся эдакими наивными фриками, вечными недальновидными детьми. И когда такие люди делают потом карьеру (изначально на своём поприще, ес-но) и им доверяют принимать далекоидущие решения — получаем что получаем.
Здравствуйте, Sinclair, Вы писали:
S>>Действительно, ведь давно же можно драйвера для Windows писать на безопасном C# или каком-нибудь Spec#, но нет, сишники такие сишники. Или... Как это нельзя? S>Не, это не про драйвера на C#, а про "зачем нам Rust?"
Да нет. Это как раз про .NET-евангелистов, вроде вас, которые много лет вещали какой C++ плохой, а C# хороший и как скоро .NET захватит мир.
Уже не одно десятилетие прошло, а как-то всемирного .NET щастя с большой буквы Ща не случилось. Ни с C#, ни с прастихоспади, Nemerle.
Но ведь можно сделать вид, что ни разу не обгадились и продолжать подкалывать сишников и крестовиков, мол, так и не научились на C++ писать без разыменования указателей. Смело, да.
Можно даже на Rust кивать, мол, вот сейчас-то. Ну да ничего, мы подождем пока того же Rust-а в Windows-ядре будет хотя бы наполовину от Си и C++. До пенсии еще лет 10 есть.
Здравствуйте, Sinclair, Вы писали:
КБ>>А чего говорить то. Программисты на сишечке в очередной раз оказались программистами на сишечке. S>Ага. Очередное продакшн-опровержение мифа о том, что "Мы и в С++ умеем обходиться без Null pointer dereference".
Здравствуйте, Константин Б., Вы писали:
КБ>Если что в данной ветке возмущаются тем что админы пострадавших организаций раскатали обновление не проверив.
Вроде бы эти обновления применялись автоматически, даже если политики явно запрещали обнволения, т.к. это "только данные".
Здравствуйте, B0FEE664, Вы писали:
BFE>Откуда известно, что это был С++?
Возможно, это был plain C, но в нём-то как раз вовсе нет способов избежать NRE.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
BFE>>Откуда известно, что это был С++? S>Возможно, это был plain C, но в нём-то как раз вовсе нет способов избежать NRE.
Здравствуйте, vdimas, Вы писали: V>Т.е. это "ваши" подосрали, а не "наши".
Вы сейчас к кому примазываетесь-то? Кого вы "нашими" называете? V>Суть проблемы — подписанный и абсолютно исправный драйвер оказался способен исполнять внешний подгружаемый p-код. V>Всё-таки, доигрались в "легко обновляемые байт-коды", дебилы, Б.
В который раз поражаюсь вашей способности читать всё наоборот.
1. "Способность исполнять внешний подгружаемый p-код" является не багом, а фичей драйвера
2. Выполнение NRE при исполнении внешнего подгружаемого кода является не фичей, а багом драйвера.
"абсолютно исправный" драйвер не вызвал бы NRE при исполнении произвольного байт-кода.
Склонен согласиться с автором https://medium.com/@vkoukis/the-root-cause-for-the-recent-crowdstrike-mess-is-not-a-content-update-it-is-a-bug-in-csagent-sys-c3904570f78a
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
КБ>Если что в данной ветке возмущаются тем что админы пострадавших организаций раскатали обновление не проверив.
Я не уверен, что у них вообще был такой выбор. Зачастую это либо политика доверия вендору, либо вовсе отсутствие такой фичи. Тут же еще тонкий вопрос, баг проявляется только при рестарте. Могли и попросту не заметить.
C>А откуда инфа? Потому что у всех объяснения разные, кто в лес кто по дрова.
Это на официальном сайте КраудСтрайк описано.
От того, что они назвали код "конфигурацией", суть не поменялась. Как я уже тыщу раз объяснял, нет никакой конфигурации, — все это лишь код, написанный без тестов и на другом языке.
Здравствуйте, SkyDance, Вы писали:
SD>Это на официальном сайте КраудСтрайк описано. SD>От того, что они назвали код "конфигурацией", суть не поменялась. Как я уже тыщу раз объяснял, нет никакой конфигурации, — все это лишь код, написанный без тестов и на другом языке.
Про файл конфигурации да. А там разве есть что-то про байт-код?
C>Ну да, в конфиге могут быть байт-код или скрипты. Просто мне интересно откуда данные, что у клоунстрайка было сделано именно так?
Так написано в официальном блоге. Если кратко, это код для виртуальной машины csagent.sys. Можно называть его как угодно — сигнатурой, байт-кодом, конфигурацией, но сути это не меняет, — в зависимости от того, что написано в этом самом C-00000291-xxx.sys, будут выполняться разный код.
Здравствуйте, SkyDance, Вы писали:
SD>Думаю, что на Расте было бы не то же самое. Проблема выразилась бы как-то иначе, например, в зависании машины без синего экрана.
Проблема и выразилась в зависании машины при прогоне высокоуровневого сценария.
Низкий уровень там был не при чём.
Здравствуйте, Sinclair, Вы писали:
V>>Т.е. это "ваши" подосрали, а не "наши". S>Вы сейчас к кому примазываетесь-то? Кого вы "нашими" называете?
Это на кого ты пытаешься свалить ошибки "вашей" безответственной братии.
V>>Суть проблемы — подписанный и абсолютно исправный драйвер оказался способен исполнять внешний подгружаемый p-код. V>>Всё-таки, доигрались в "легко обновляемые байт-коды", дебилы, Б. S>В который раз поражаюсь вашей способности читать всё наоборот. S>1. "Способность исполнять внешний подгружаемый p-код" является не багом, а фичей драйвера
Т.е. багом архитектуры, опять бгг.
Мне уже примерно понятны зигзаги карьеры их технического руководства.
Т.е., вот тебе пошло уже вредительство от игрушечных технологий "генного" плана — это когда разрабы с геномом фриков-лалашек растут по карьёрной лестнице и тянут свои шаловливые ручки к рычагам принятия решений.
Время-то идёт, проблема "низкой планки входа" уже пустила корни и даёт свои плоды во втором поколении, в поколении технического руководства.
И твои попытки бегать от первопричин проблемы лишь её усугубляют.
Вы все как под копирку, хосподя, такие же раздражающие своей близорукостью и безответственностью.
В реальной работе я бы тебе гвоздя ржавого не доверил, я ж помню твои эксперименты по генерации кода на C# — степень самокритичности примерно нулевая, зато степень очковтирательства и изворотливости — примерно максимально возможная. И это когда уже совсем разжевали и в рот положили сценарии, где код даёт ошибку. Только почему-то посторонний vdimas видит эти косяки сходу, за единицы/десятки секунд, а потративший кучу времени на тему автор с трудом "догоняет" даже спустя несколько раундов объяснений, бгг...
А сдаётся мне, что автор тупо врёт — да не может же он быть НАСТОЛЬКО тупым.
Автор просто врёт себе, врёт окружающим.
Т.е. из-за какого-то странного дефекта психики предпочитает уходить в выдуманный мир по каждой мелочи, если хотя бы немного начинает чувствовать себя дискомфортно, бгг...
S>2. Выполнение NRE при исполнении внешнего подгружаемого кода является не фичей, а багом драйвера.
Чего? ))
Похоже, ты совсем не вдупляешь происходящее — драйвер честно перехватил ошибку и честно отрапортовал наверх с обязательной диагностикой и кодами ситуации, иначе никакого BSOD не было бы и близко, было бы тупое подвисание или что-то в этом роде.
BSOD — это, как раз, штатный сценарий реагирования на ошибки ядерного уровня.
Похоже, в более высокостоящей архитектуре всей этой приблуды не прописали сценарий — как реагировать на проваливающиеся аж на уровень VM тупые NRE байт-кода, бгг...
Такие вещи разрабатываются на архитектурном уровне и выдаются в кач-ве ТЗ техническими лидерами проекта.
Кароч, это не баг в C++, по крайней мере, никакой ошибки в C/C++ в произошедшем нет, бо на этом уровне отработали штатные ср-ва, которые помогли сразу же локализовать проблему.
Да, я понимаю твои рассуждения: "в уютном коде, выполняющемся на уровне ядра, могут быть ошибки, и VM должен был обыграть их как-то более гладко!"
Напомню, что это код уровня ядра...
Даже если это байт-код.
И что ошибки в нейтиве на этом уровне, когда могут быть локализованы, приводят к отключению подсистемы или к BSOD, если нормальное функционирование системы далее невозможно.
А когда ошибки на этом уровне не могут быть локализованы, то машина ведёт себя произвольно — дай бог где-то диагностика заметит какой-то бред и насильно перегрузит (полно и такого кода в мониторе ядра), а так-то поведение машины может стать произвольным — "подвиснуть", "тормозить", не работать часть систем и т.д.
Вот и получается, что для более простого, более безопасного языка ты требуешь еще большей толерантности, хотя должно было быть, по-идее, ровно наоборот — ведь "сложнее ошибиться" (С) Синклер!
А на деле, пресловутый NRE ты мог получить даже просто закрыв Windows.Forms в неудачный момент — это ж привычные постоянно исправляемые сомны багов на уровне C#.
Я ведь тщательно слежу за дотнетом еще с 2002-го и сам кучу раз репортил — да не бывает такой плотности багов в нейтивной разработке ни за что и никогда, оно бы ничего и никогда не работало с таким отвратительно-несерьёзным подходом. ))
А дотнетный Решарпер в Студии отваливается десятки раз за день до сих пор, бгг...
Хорошо хоть они догадались разбить его на модули меньшего размера, чтобы при краше модуля подгружать/инициализировать лишь его, а не весь монструозный плагин.
Но такой подход — это роспись в собственной убогости, разумеется.
За 20 лет не могли отловить баги, бгг.
Жесть, конечно...
(По моим наблюдениям, один из самых популярных классов ошибок в дотнете — это ошибки синхронизации в многопоточных приложениях, что провоцируется той лёгкостью, с которой произвольный объект может служить примитивом синхронизации и сочетанием всевозможных выделенных примитивов синхронизации со "встроенным" в каждый объёкт, включая механизмы монитора Pulse/PulseALL — иногда такую кашу приходится разгребать... Помнится, я тебе на пальцах показывал, как решаются задачи сложной синхронизации многих подсистем через наработки ТМО, но ты слишком усердно бегал, хотя второе образование получил по близкой моей специализации и эту теорию вам давали, но, видать, это "слишком сложно" для "уютного мирка", бгг...)
Ни один стресс-тест из моих разработок их наколенное поделие, Решарпер, никогда бы не пережило, даже в тех ситуациях, где, казалось бы, "всегда работает".
Да и вообще — что мешает собирать диагностику падений и оперативно исправлять баги?
Некому?
Нет достаточно грамотных спецов сугубо по технической части?
Одни прожжённые прикладники там собрались или как? ))
Когда мне в руки на "поиграть" попадает нечто, что "долгие годы исправно работает" (произносится громко, причём сразу от нескольких опытных разрабов) — у меня оно всё начинает резко падать и захлёбываться собственными соплями. ))
Как раз специализируюсь на поиске ненадёжностей в т.ч. в архитектурном плане и в выработке решений по ним.
S>"абсолютно исправный" драйвер не вызвал бы NRE при исполнении произвольного байт-кода.
Ты действительно не понимаешь, или намеренно работаешь на публику?
Это вполне "законный" NRE уровня виртуальной машинки.
Ну как "законный".
Ужас-ужас, конечно, но разработчики на управляемых языках особо не парятся.
Ты склонен бегать аки ужик на сковородке тут — по ссылке тоже исходят из того, что ошибка была "логическая".
И тоже правильно поняли происходящее — сначала нашли как проблему обойти, а только потом (и неизвестно когда) будут решать как проблему решить.
И да, этому идиотизму посвящена чуть ли не половина твоей ссылки, что говорит о твоей недалёкости, коль даёшь НАСТОЛЬКО низкопробные ссылки — ведь автор не может знать всех подробностей архитектуры решения, как и подробностей происходящего, т.е. вольно или невольно скатывается в банальную желтушность, в распускание слухов, бгг...
===========
Пока что единственное о чём можно делать выводы — пресловутый "порог вхождения уютных языков" привёл к самому масштабному мировому сбою за всю историю IT!
Прилетел бумеранг...
Вас теперь этим будут тыкать каждый раз как позволите себе впредь выделываться и надувать щёки. ))
===========
Вопрос не так прост, как кажется на первый взгляд, бо не позволяет отделять разработчиков друг от друга, ведь даже если в "уютную" область входит достаточно опытный разработчик, навроде тебя, он с некоторой ощутимой вероятностью расслабляет булки на твой же манер, среда-то "безопасная!"
"Выкинет исключение, а не молча отформатирует диск!" (С)
Ну вот среда и выкинула исключение, бгг...
Заодно помножила на ноль все ваши фантазии, коих наслушались за эти 20 лет.
ИМХО, IT надо тупо возвращаться к истокам, к накопленному ранее опыту и определённому менталитету инженера-программиста, независимо от языков и сред.
Фричество не работает, за это уже не первый раз больно прилетает бумеранг.
Здравствуйте, Sinclair, Вы писали:
BFE>>Откуда известно, что это был С++? S>Возможно, это был plain C, но в нём-то как раз вовсе нет способов избежать NRE.
NRE произошёл не в С/С++ ))
Хватит уже распускать слухи.
И да, в Си без проблем вешать обработчики исключений, как и в С++, ес-но, с использованием того же ABI setjmp/longjmp, т.е. не только через языковые ср-ва try-catch.
Здравствуйте, SkyDance, Вы писали:
SD>Я не уверен, что у них вообще был такой выбор. Зачастую это либо политика доверия вендору, либо вовсе отсутствие такой фичи. Тут же еще тонкий вопрос, баг проявляется только при рестарте. Могли и попросту не заметить.
Что странно, ведь основное тестирование обновлений выполняется на виртуалках, т.е. сценарий неоднократного перезапуска при обновлении системы именно так и тестируется.
Здравствуйте, Константин Б., Вы писали:
КБ>Если что в данной ветке возмущаются тем что админы раскатали обновление не проверив.
Это вряд ли.
Учитывая малый процент сбойных машин, на которые попало обновление, сбой мог просто не выстрелить при тестировании.
Т.е. тут вопросы больше к методике тестирования.
Лично меня напрягает то, что сам драйвер протестирован и подписан мелкомягкими, т.е., скорее всего, протестирован достаточно хорошо.
А вот подгружаемый на ядерный уровень байт-код, исполняемый драйвером, тестируется только вендором и не требует подписи, т.е. его надёжность на совести конкретного вендора.
Немного разрывчик шаблона, не? ))
И ожидаемый однажды приплызд за такие выверты.
V>Лично меня напрягает то, что сам драйвер протестирован и подписан мелкомягкими, т.е., скорее всего, протестирован достаточно хорошо.
гм. Это не совсем так работает. Тестирование там очень-очень поверхностное. По крайней мере раньше так было. Может, сейчас как-то иначе, но — сомневаюсь.
Подпись не означает "протестировано". Это означает, что "зуб даем, вот тот бинарь нам пришел от кого-то из crowdstrike, у кого есть приватный ключ для подписи". В общем-то, ничего более. Что уж там, я не удивлюсь, если подписываемый драйвер не тестируется от слова вообще (кроме как базовых статических тестов).
Здравствуйте, Codealot, Вы писали: C>Ты гонишь пургу. Не помню, когда он в последний раз отваливался, и не слышал ни от кого, чтобы это было проблемой.
Да там и всё остальное — пурга. Вот буквально каждое предложение бери — и там вранье.
Совсем парень переехал в параллельную реальность, увы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Codealot, Вы писали:
V>>А дотнетный Решарпер в Студии отваливается десятки раз за день до сих пор, бгг... C>Ты гонишь пургу.
Это ты гонишь пургу.
А Решарпер регулярно отваливается на различных машинах все годы, т.е. на протяжении множества своих версий.
Лицензия самая полная из всех доступных.
C>Не помню, когда он в последний раз отваливался, и не слышал ни от кого, чтобы это было проблемой.
Так "не отваливается" или "это не проблема"?
Это проблема, бо периодически создаёт задержки, пока он там автоматически переподгрузит рухнувшую подсистему.
Да и, что за детсад ты тут разводишь, сотрясая напрасно воздух?
Давай забьёмся на ящик коньяка — я тебе сюда (или куда удобней — в телегу, например) буду скидывать скриншоты его падений в течение нескольких дней, бгг...
Здравствуйте, Sinclair, Вы писали:
C>>Ты гонишь пургу. Не помню, когда он в последний раз отваливался, и не слышал ни от кого, чтобы это было проблемой. S>Да там и всё остальное — пурга. Вот буквально каждое предложение бери — и там вранье.
Конкретней, мистер болтун.
Это где ты занимался очковтирательством в своём "генераторе кода на лету"?
Или что NRE возник в байт-коде конкретно по проблеме этого топика?
Или что ненадёжный багованный Решарпер падает много раз за рабочий день?
Так с чем именно ты всё ещё не согласен?
S>Совсем парень переехал в параллельную реальность, увы.
Скорее, кто-то скромно отворачивается, предпочитая не замечать проблем, связанных с новомодным этим идиотизмом под названием "фричество".
Да забей ты на эту херню уже, пора уже было вырасти из детских штанишек.
Это ж пипец несерьёзно — ты что в 25 лет щенячьими глазками смотрел на мир, что до сих пор.
Ничему тебя жизнь не учит...
И не научит до тех пор, пока предпочитаешь отворачиваться, не замечать, убегать/избегать, одним словом — бояться жить.
"Пусть этим занимается кто-то другой" — это твой такой подход, весьма чистоплюйский, кстате.
ОК.
Ну тогда твоя задача внимательно внимать опыту этих других людей, а не устраивать капризы на весь инет в духе "А баба Яга против!". ))
Здравствуйте, vdimas, Вы писали:
V>NRE произошёл не в С/С++ )) V>Хватит уже распускать слухи.
Конечно же в C/C++
Официально это теперь не nre, а
out-of-bounds memory read, но это ничего в лучшую для сишечки сторону не меняет.
V>И да, в Си без проблем вешать обработчики исключений, как и в С++, ес-но, с использованием того же ABI setjmp/longjmp, т.е. не только через языковые ср-ва try-catch.
setjmp/longjmp тут конечно не в тему. Но да на винде есть SEH который позволяет ловить NRE на си. Но как всем известно программисты на сишечке не обрабатывают ошибки 🤷🏿♀️ И это просто очередной пример.
Здравствуйте, vdimas, Вы писали:
V>А Решарпер регулярно отваливается на различных машинах все годы, т.е. на протяжении множества своих версий.
Я тебе уже сказал. У меня он отваливался в последний раз, наверно, в прошлом году.
V>Так "не отваливается" или "это не проблема"?
Нет такой проблемы, чтобы он вообще отваливался. Так лучше доходит?
V>Да и, что за детсад ты тут разводишь, сотрясая напрасно воздух? V>Давай забьёмся на ящик коньяка — я тебе сюда (или куда удобней — в телегу, например) буду скидывать скриншоты его падений в течение нескольких дней, бгг...
Если очень захотеть, то наверняка можно этого добиться. В крайнем случае, залезть в бинарные файлы и подшаманить.
у меня такой проблемы нет. У всех моих знакомых тоже нет. Похоже, что она есть только у тебя.
Здравствуйте, Codealot, Вы писали:
V>>А Решарпер регулярно отваливается на различных машинах все годы, т.е. на протяжении множества своих версий. C>Я тебе уже сказал. У меня он отваливался в последний раз, наверно, в прошлом году.
А в течение 15 лет до этого? ))
C>Нет такой проблемы, чтобы он вообще отваливался. Так лучше доходит?
Что не соответствует наблюдаемому.
Может, у вас код "более стандартный", бгг?
V>>Да и, что за детсад ты тут разводишь, сотрясая напрасно воздух? V>>Давай забьёмся на ящик коньяка — я тебе сюда (или куда удобней — в телегу, например) буду скидывать скриншоты его падений в течение нескольких дней, бгг... C>Если очень захотеть, то наверняка можно этого добиться. В крайнем случае, залезть в бинарные файлы и подшаманить.
Ой, давай без этого.
Я не заинтересован в глючности инструментария.
C>у меня такой проблемы нет. У всех моих знакомых тоже нет. Похоже, что она есть только у тебя.
И у других коллег, с которыми работаю.
Ну так что, слать тебе ежедневно по нескольку скриншотов глюканутого Решарпера?
Или уже угомонишься и просто примешь инфу к сведению? ))
Здравствуйте, Константин Б., Вы писали:
V>>И да, в Си без проблем вешать обработчики исключений, как и в С++, ес-но, с использованием того же ABI setjmp/longjmp, т.е. не только через языковые ср-ва try-catch. КБ>setjmp/longjmp тут конечно не в тему.
В смысле?
Установка точек возврата для исключений работает аналогичным образом, как setjmp/longjmp.
Здравствуйте, vdimas, Вы писали:
V>Может, у вас код "более стандартный", бгг?
То есть в смысле, что у вас там он черезжопный.
V>Ой, давай без этого. V>Я не заинтересован в глючности инструментария.
Ты явно заинтересован в том, чтобы не выглядеть треплом.
V>Или уже угомонишься и просто примешь инфу к сведению? ))
Ну ок, приму к сведению, что у некоторых любителей каких-то черезжопных вещей бывают странные баги и они на этом основании делают далеко идущие выводы.
Здравствуйте, vdimas, Вы писали:
V>Конкретней, мистер болтун. V>Это где ты занимался очковтирательством в своём "генераторе кода на лету"?
Это очковтирательство по скорости порвало GCC с -o3, при этом не жертвуя контролем диапазонов.
А вы, коллега, усердно тупили, не понимая, чем банальное завёртывание unsafe кода в "safe" обёртку отличается от нормальной статической верификации корректности кода.
V>Или что NRE возник в байт-коде конкретно по проблеме этого топика?
NRE возник в VM, которая пытается интерпретировать байт-код.
Сказки о том, что BSOD является ожидаемым поведением, рассказывайте первокурсницам гумфака. Скормили тебе сигнатуру с ошибкой — записал об этом в лог, пошёл следующую сигнатуру проверять.
Впрочем, от человека, который не понимает, как типизируются промежуточные результаты в выражениях С++, я понимания столь сложных вещей и не ожидаю.
V>Скорее, кто-то скромно отворачивается, предпочитая не замечать проблем, связанных с новомодным этим идиотизмом под названием "фричество". V>Ну тогда твоя задача внимательно внимать опыту этих других людей, а не устраивать капризы на весь инет в духе "А баба Яга против!". ))
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Константин Б., Вы писали:
V>>>И да, в Си без проблем вешать обработчики исключений, как и в С++, ес-но, с использованием того же ABI setjmp/longjmp, т.е. не только через языковые ср-ва try-catch. КБ>>setjmp/longjmp тут конечно не в тему.
V>В смысле? V>Установка точек возврата для исключений работает аналогичным образом, как setjmp/longjmp.
А передавать управление на эту точку возврата кто будет? longjmp сам вызовется?
В случае SEH операционная система нужный обработчик вызовет (который мало что сделать сможет, но это другой вопрос). А longjmp руками вызвать надо.
Здравствуйте, Codealot, Вы писали:
V>>Может, у вас код "более стандартный", бгг? C>То есть в смысле, что у вас там он черезжопный.
О, пошла стадия торга, бгг...
V>>Ой, давай без этого. V>>Я не заинтересован в глючности инструментария. C>Ты явно заинтересован в том, чтобы не выглядеть треплом.
Я даже не думал в эту сторону, но вот ты окончательно затрепался, опять бгг...
Это ж надо придумать, чтобы я влез в бинари Решарпера и пошаманил там эдаким образом, чтобы сохранить работоспособность, но чтобы он иногда глючил.
Ты там под веществами был, что ле? ))
V>>Или уже угомонишься и просто примешь инфу к сведению? )) C>Ну ок, приму к сведению, что у некоторых любителей каких-то черезжопных вещей бывают странные баги и они на этом основании делают далеко идущие выводы.
1. Баги не у меня, а у Решарпера, третий раз бгг...
2. Наш код вполне корректен синтаксически и логически, хотя да, нетривиален с т.з. большинства дотнетных поделий;
3. Выводы не далекоидущие, а самые прямые — основная масса дотнетчиков, даже работающих в ведущих мировых компаниях, откровенно криворуки, безграмотны и наглухо безответственны в разработке аки малые дети, заключительное бгг...
Здравствуйте, Константин Б., Вы писали:
V>>Установка точек возврата для исключений работает аналогичным образом, как setjmp/longjmp. КБ>А передавать управление на эту точку возврата кто будет? longjmp сам вызовется?
Вызывается изнутри _Unwind_RaiseException — сначала производится cleanup текущих стековых переменных, затем поиск обработчика через type_info, затем происходит аналог longjmp на установленную точку входа обработчика.
КБ>В случае SEH операционная система нужный обработчик вызовет (который мало что сделать сможет, но это другой вопрос).
В случае структурных исключений ядро просто трансформирует аппаратные прерывания в софтовые с известной на уровне ABI операционки структурой данных, описывающих исключение.
Т.е., сводит сигналы различной природы к одному АПИ.
КБ>А longjmp руками вызвать надо.
longjmp — это невыразимый обычными ср-вами языка трюк "отмотки" стека с одновременной передачей управления некоей выставленной заранее точке в коде, где указатель стека как раз восстанавливается до значения в этой точке.
Пробрасывания и перехваты исключений построены ровно по такому же принципу, разве что вместо аргумента int user_data оперируют указателями на void*, под которым скрываются более сложные структуры, описывающие семантику происходящего. При доступе к АПИ компилятора на Си нефик делать всё это раскрутить вручную, как это происходит автоматом на плюсах.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Константин Б., Вы писали:
V>>>Установка точек возврата для исключений работает аналогичным образом, как setjmp/longjmp. КБ>>А передавать управление на эту точку возврата кто будет? longjmp сам вызовется?
V>Вызывается изнутри _Unwind_RaiseException ...
А _Unwind_RaiseException кто вызовет?
КБ>>В случае SEH операционная система нужный обработчик вызовет (который мало что сделать сможет, но это другой вопрос).
V>В случае структурных исключений ядро просто трансформирует аппаратные прерывания в софтовые с известной на уровне ABI операционки структурой данных, описывающих исключение. V>Т.е., сводит сигналы различной природы к одному АПИ.
Да. В SEH понятно кто что вызывает. А кто вызывает _Unwind_RaiseException/longjump?
КБ>>А longjmp руками вызвать надо.
V>longjmp — это ...
Я знаю что оно такое и что делает. Вызывает-то его кто?
Здравствуйте, Sinclair, Вы писали:
V>>Это где ты занимался очковтирательством в своём "генераторе кода на лету"? S>Это очковтирательство по скорости порвало GCC с -o3, при этом не жертвуя контролем диапазонов.
Порвало оно наивную реализацию, а так-то отсосала от ненаивной.
Но не в этом дело, мне там на скорости было малость до фени, я среагировал на некорректность генерируемого кода — он генерит корректный код только для узкого класса сценариев, никак не диагностируя, что порет лажу в остальных случаях.
Очковтирательство заключалось в этом и оно непосредственно связано с топиком, иначе бы я не упомянул тот случай.
Это просто у вашей братии вот такой сволочной подход — молча раскладывать лепешки по коду, хлопая честными глазками.
S>А вы, коллега, усердно тупили, не понимая, чем банальное завёртывание unsafe кода в "safe" обёртку отличается от нормальной статической верификации корректности кода.
Опять начались изворачивания...
Сходи да освежи. ))
Я тебе довольно быстро указал на проблему (от первого же поста, в котором взял за труд верифицировать твоё решение), но ты или долго не мог понять её суть, или пытался играть на публику в расчёте на то, что читатели не станут вникать.
В реальной работе я привык малость к другому — стоит только намекнуть на обнаруженную некорректность, и коллеги сразу понимают.
С тобой почему не так?
Я не вижу простого рабочего подхода при решении тобой технических задач.
Беспокойная твоя головушка создаёт слишком много лишнего информационного шума, который никому нахрен не нужен.
Такое ощущение, что ты не работу работаешь, не стремишься к результату, а тупо ждёшь как ребёнок похвалы за каждое своё телодвижение.
Т.е. сосредоточен сугубо на комфортном процессе, а не на результате, бгг...
Смотреть на это невозможно, испанский стыд.
Перехвалили в детстве? ))
V>>Или что NRE возник в байт-коде конкретно по проблеме этого топика? S>NRE возник в VM, которая пытается интерпретировать байт-код.
Ошибка была в самом байт-коде.
S>Сказки о том, что BSOD является ожидаемым поведением
Ожидаемым поведением ошибки ядерного уровня, ес-но.
Было сказано, что BSOD — это штатное ср-во реакции, и что в иных случаях до него даже не доходит.
S>Скормили тебе сигнатуру с ошибкой — записал об этом в лог, пошёл следующую сигнатуру проверять.
Нахрена?
Чтобы "отформатировать диск"? (С)
Нормальным поведением будет вывалиться с ошибкой, а не пытаться исполнять какую-то чухню.
Причём, учитывая, что речь о ср-ве обеспечения безопасности, лично я не уверен, что стоит позволять пользователю продолжать работать в скомпрометированной на ядерном уровне среде — вдруг кривой байт-код является способом атаки?
"Зацикливание" всего сценария случилось на вышестоящем уровне, напомню, что я тоже высмеял.
(Хотя, в 90-е никто не парился, а просто заходили в отладочном режиме и откатывали последние обновления, просто сейчас средняя по палате компьютерная грамотность чудовищно низка)
А так уже высмеял твою толерантность к байт-коду — ты снова запросто рассуждаешь о том, что байт-код может быть кривой.
(Но ни боже упаси будет кривым нейтивный код — тебя порвёт на сотни постов гневно-праведного обличительства, чемпион ты наш по лицемерию)
В общем, высмеиваю тебя за это повторно — ты опять сам себя сдаёшь как стеклотару.
Показываешь перлы своего "объективного мышления", бгг...
S>Впрочем, от человека, который не понимает, как типизируются промежуточные результаты в выражениях С++, я понимания столь сложных вещей и не ожидаю.
Ты опять заврался.
Я же тебе продемонстрировал в чём дело — сохранил результат в промежуточную стековую volatile-переменную (семантика volatile в плюсах иная, чем в дотнете).
В итоге, UB никуда не делся, но битовые фокусы стали ожидаемыми тобой.
И я продемонстрировал тебе суть происходящего и на C#, чем подорвал твой анус, помнится.
Я думаю, что ты упирался лишь по той причине, что до моего появления в подветке успел наговорить тонны первокласнейшей ереси.
Никакой другой причины впадения тебя в неадекват и проявляемой затем мстительности не было.
Ну выставили тебя болтуном и что?
Первый раз, что ле?
Ну вот манера у тебя такая — еще не разобрался, а уже пошёл поливать грязью "классовых врагов". ))
Жалкое зрелище, бо мы к тебе во враги не записывались, бгг...
Это ты сам, сам — глубинные комплексы покоя не дают.
Всего-то достаточно в другой раз следить за языком.
Но ты не можешь — вот как здесь опять нагородил чухни не разобравшись.
============
И чего там понимать-то в том UB? — прямо по стандарту разрешён промоушен до более широких типов в промежуточных значениях вычислений.
Впрочем, компиляторы делали это и до фиксирования в стандарте.
Но теперь это допустимо и просто для локальных объектов, бо согласно последнему стандарту их не требуется "воплощать" без лишней надобности, т.е. их официально приравняли к промежуточным значениям вычислений. Впрочем, компиляторы и это делали еще до фиксации в стандарте.
Это всё способы, во-первых, улучшить точность вычислений, а во-вторых — не натыкаться лишний раз на UB в случае переполнений.
Более того — я показывал тебе ассемлерные распечатки разных компиляторов, где было видно, что те позволяют себе иногда расширять int32 до int64 унутре в регистрах.
До тех пор, пока от этого не страдает семантика well formed кода — это допустимо и правильно.
И да, повторю свою мысль — когда-то это всё дойдёт и до дотнета, несмотря на твой визг "низачто и никогда!"
Сам прикинь — сейчас ситуация в дотнете с нейтивной кодогенерацией примерно как в конце 80-х / начале 90-х на С/С++, когда компиляторы компиляли в точности как написано, бгг...
Разумеется, дотнет еще будет развиваться в деле оптимизации, а значит, список его UB будет расширяться примерно так же, как постепенно расширялся список UB в плюсах.
Здравствуйте, Константин Б., Вы писали:
V>>Вызывается изнутри _Unwind_RaiseException ... КБ>А _Unwind_RaiseException кто вызовет?
Его вызывает ф-ия __cxa_throw — это "высокоуровневый" хелпер для запуска исключения, т.е. чтобы конструкция throw компилялась в малое кол-во опкодов.
Унутре __cxa_throw инициализирует локальные данные потока объектом-исключением и текущим контекстом функции и вызывает _Unwind_RaiseException.
Затем изнутри __cxa_throw (или по возврату из неё — в зависимости от реализации) вызывается:
__builtin_eh_return (offset, handler), which adjusts the stack by offset and then jumps to the handler.
Или другой аналог longjmp.
Там ключевое отличие лишь в том, что setjmp вызывается коде динамически, т.е. некий твой код динамически заполняет структуру jmp_buf, а компилятор генерит таблицу уже заполненных аналогичных структур для ф-ии еще в процессе компиляции.
V>>В случае структурных исключений ядро просто трансформирует аппаратные прерывания в софтовые с известной на уровне ABI операционки структурой данных, описывающих исключение. V>>Т.е., сводит сигналы различной природы к одному АПИ. КБ>Да. В SEH понятно кто что вызывает. А кто вызывает _Unwind_RaiseException/longjump?
Примерно так:
throw SomeException();
; передача аргументов в x64_call: RDI, RSI, RDX, RCX...
mov edi, sizeof(SomeException)
call __cxa_allocate_exception
mov rbx, rax
mov rdi, rax
call SomeException::SomeException()
; __cxa_throw(void *thrown_object, std::type_info *tinfo, void (*dest)(void *))
mov rdx, SomeException::~SomeException()
mov rsi, typeid(SomeException)
mov rdi, rbx
call __cxa_throw
; далее зависит от реализации - где происходит вызов деструктора исключения -
; внутри __cxa_throw или реализация разбита на две фазы
mov rdi, rbx
mov rbx, rax
call __cxa_free_exception
// если по возвращении, то вызываем вторую фазу обработки исключения
mov rdi, rbx
call _Unwind_Resume ; внутри будет вызван аналог __builtin_eh_return
V>>longjmp — это ... КБ>Я знаю что оно такое и что делает. Вызывает-то его кто?
Здравствуйте, vdimas, Вы писали: V>Порвало оно наивную реализацию, а так-то отсосала от ненаивной.
А что вы имеете в виду под "ненаивной"? V>Но не в этом дело, мне там на скорости было малость до фени, я среагировал на некорректность генерируемого кода — он генерит корректный код только для узкого класса сценариев, никак не диагностируя, что порет лажу в остальных случаях.
И в каких же случаях он "порет лажу"?
V>Очковтирательство заключалось в этом и оно непосредственно связано с топиком, иначе бы я не упомянул тот случай. V>Это просто у вашей братии вот такой сволочной подход — молча раскладывать лепешки по коду, хлопая честными глазками.
V>Я тебе довольно быстро указал на проблему (от первого же поста, в котором взял за труд верифицировать твоё решение), но ты или долго не мог понять её суть, или пытался играть на публику в расчёте на то, что читатели не станут вникать.
В реальности вы там начали нести пургу, за которую были высечены несколькими участниками.
V>В реальной работе я привык малость к другому — стоит только намекнуть на обнаруженную некорректность, и коллеги сразу понимают.
Напомните-ка мне, в чём там некорректность? А то дело уж давно было, я малость подзабыл.
V>Я не вижу простого рабочего подхода при решении тобой технических задач. V>Беспокойная твоя головушка создаёт слишком много лишнего информационного шума, который никому нахрен не нужен.
V>Перехвалили в детстве? ))
Скорее вас недохвалили. Отсюда постоянные попытки, обосрамшись, сделать вид, что "ничего не было", на крайняк "меня не так поняли".
V>Ошибка была в самом байт-коде.
Несомненно была.
V>Ожидаемым поведением ошибки ядерного уровня, ес-но. V>Было сказано, что BSOD — это штатное ср-во реакции, и что в иных случаях до него даже не доходит.
V>Чтобы "отформатировать диск"? (С)
Для того, чтобы угрозы проверять. Напомню, речь идёт о софте, выявляющем трояны.
Основное преимущество управляемого кода — как раз возможность изолировать ошибки.
V>Причём, учитывая, что речь о ср-ве обеспечения безопасности, лично я не уверен, что стоит позволять пользователю продолжать работать в скомпрометированной на ядерном уровне среде — вдруг кривой байт-код является способом атаки?
V>А так уже высмеял твою толерантность к байт-коду — ты снова запросто рассуждаешь о том, что байт-код может быть кривой.
По-хорошему, байт-код нужно верифицировать, но кто ж знает, что у них там за байт-код. Это ж какая-то самодеятельность.
V>(Но ни боже упаси будет кривым нейтивный код — тебя порвёт на сотни постов гневно-праведного обличительства, чемпион ты наш по лицемерию)
"Сотни постов". Ага. Стоило один раз упомянуть, как у vdimas порвался пукан, и нас накрыло коричневой волной.
V>Ты опять заврался. V>Я же тебе продемонстрировал в чём дело — сохранил результат в промежуточную стековую volatile-переменную (семантика volatile в плюсах иная, чем в дотнете). V>И я продемонстрировал тебе суть происходящего и на C#, чем подорвал твой анус, помнится.
V>Я думаю, что ты упирался лишь по той причине, что до моего появления в подветке успел наговорить тонны первокласнейшей ереси.
Ну, то есть вы так до сих пор и не поняли, что никакой ереси я там не нёс, зато вот над вашими постами смеются примерно все, кто понимает устройство компилятора?
V>И чего там понимать-то в том UB? — прямо по стандарту разрешён промоушен до более широких типов в промежуточных значениях вычислений.
Ну вот, вы продолжаете позориться. Понятно, почему не хотите в форуме название работодателя светить — вдруг коллеги вас поиском случайно найдут, ржать будут годами.
За истекшее время можно было сходить и найти соответствующий пункт стандарта. Заодно понять, почему он неприменим к рассматриваемому примеру.
V>Это всё способы, во-первых, улучшить точность вычислений, а во-вторых — не натыкаться лишний раз на UB в случае переполнений.
V>Более того — я показывал тебе ассемлерные распечатки разных компиляторов, где было видно, что те позволяют себе иногда расширять int32 до int64 унутре в регистрах.
Во-первых, типизация промежуточных значений происходит задолго до того, как появятся какие-то регистры. Так что продемонстрированные вами расширения — это уже фаза кодогенерации, на этом этапе компилятор все семантические оптимизации давно применил.
Во-вторых, осталось показать, как это работает для суммы двух int256. Куда она там будет расширяться, и почему компилятор позволяет себе выбрасывать код для этого случая безо всякой оглядки на регистры.
V>И да, повторю свою мысль — когда-то это всё дойдёт и до дотнета, несмотря на твой визг "низачто и никогда!" V>Разумеется, дотнет еще будет развиваться в деле оптимизации, а значит, список его UB будет расширяться примерно так же, как постепенно расширялся список UB в плюсах.
Впечатляющий пример глобального непонимания.
1. Не понимаете, что именно делает компилятор, и как он это делает, для конкретного случая.
2. Не понимаете, как выводятся типы промежуточных результатов в арифметике C++. В частности, путаете integral promotions с signed overflow.
3. Не понимаете причин, по которым компиляторы С++ делают именно так. Заодно не понимаете последствий. В частности, отсюда ваши наивные заблуждения вида "ну вот я давно пишу такое на MSVC, и там всё хорошо".
4. Не понимаете закономерностей развития индустрии, отсюда ваши прогнозы про внедрение UB в дотнете.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>я среагировал на некорректность генерируемого кода — он генерит корректный код только для узкого класса сценариев, никак не диагностируя, что порет лажу в остальных случаях. S>И в каких же случаях он "порет лажу"?
Ты потерял тот топик? ))
Меня триггернуло даже не в то, что код неверный для большого класса сценариев, а что об этом даже не сигнализируется.
Ну и, ты в привычной своей манере стал трепать нервы, делая вид, что проблема несущественная. ))
Хотя, у потенциального юзера твоей либы должен был возникает вопрос — а как же оно тогда скомпиллировалось, если неверно работает?
А вот так.
Динамика — штука подлая. ))
Т.е., стоило бы тебе быть честным с самим с собой еще на этапе продумывания того, как это будет выглядеть на самом верхнем уровне.
Тогда ты бы выбрал другую стратегию реализации — ведь на тот момент уже был доступен Рослин, т.е. можно было делать кодогенерацию времени компиляции и сообщать о невозможности реализовать оптимизированный вариант на этой стадии.
(или же скатываться к некоему менее оптимальному fallback)
По крайней мере, такое решение могло бы не уйти "в стол", а постепенно развиваться.
А твой подход — заведомый тупик из-за взрывного роста комбинаторной логики в попытках обыграть всевозможные граничные случаи, при том что код кодогенерации наглухо нечитаемый/неподдерживаемый. И ты тоже заранее знал, что подобный код — это классическая лапша.
Плюс, "захватывать" аж всю сигнатуру 2D-массивов для linq единственной спорной реализацией — такое себе...
Решение не пострадало бы от введения доп. типа-маркера для Рослина, а даже выиграло бы, бо при таком подходе могло бы сосуществовать более одной реализации/стратегии.
Вот и получается, тебе просто захотелось поиграться, ты достиг неких результатов и поспешил "размазать сишников".
А вот не надо было торопиться, сначала надо было исследовать полученное.
И тем более не надо было агрить сишников в топик, они тут уже точно не при чём. ))
Но ты многократно упомянул всуе, и как всегда далёким от корректности образом, но так смешно вышло, что единственный, кто вникнул и целиком разобрался был сишник, а не обычные посетители C# топика. ))
И сдаётся мне, этот забавный факт сильно повлиял на дальнейшее общение, бгг...
Ведешь себя порой, блин, как блоггер моды или даже профессиональный артист.
V>>Очковтирательство заключалось в этом и оно непосредственно связано с топиком, иначе бы я не упомянул тот случай. V>>Это просто у вашей братии вот такой сволочной подход — молча раскладывать лепешки по коду, хлопая честными глазками. S>
Ничего смешного.
В таких случаях коллеги реагируют на порядки короче: "Ой, точно!"
V>>Я тебе довольно быстро указал на проблему (от первого же поста, в котором взял за труд верифицировать твоё решение), но ты или долго не мог понять её суть, или пытался играть на публику в расчёте на то, что читатели не станут вникать. S>В реальности вы там начали нести пургу, за которую были высечены несколькими участниками.
Ага, побегай, "реальность на месте", можно полюбоваться.
Что я неверно изобразил тестовый пример в самом первом своём сообщении в том топике, дык, я и сказал своё "ой" и тут же исправился — и оно ни на что не влияло, т.к. рассматривались методы решения задач этого класса, а не конкретная задача — иначе бы тебе не было смысла городить свою либу.
Да, в момент написания одного из первых ответов был сосредоточен на другом, и?
Оно на что-то повлияло в обсуждении?
Аж ни на что. ))
Я-то свой косяк мгновенно тут же исправил (а мог бы и не исправлять, бо абсолютно было пофик как при обсуждении как твоей реализации, так и моих предлагаемых альтернативных приёмов), а у тебя суровый косяк как был, так и остался неисправленным до сих пор.
Вот и вся разница между нами, бгг...
V>>В реальной работе я привык малость к другому — стоит только намекнуть на обнаруженную некорректность, и коллеги сразу понимают. S>Напомните-ка мне, в чём там некорректность? А то дело уж давно было, я малость подзабыл.
Подробности на месте, но они всё так же маловажны.
Спустя кучу постов ты-то согласился...
Думаю, вряд ли многие коллеги до туда дочитали, бгг...
Я ж не к конкретной ошибке цепляюсь, а в целом к паттерну действий.
Помнится, про драйверы баз данных примерно оно же вышло — ты рассуждал о желаемом как об имеющемся, вынудил меня сделать кучу проверок, чтобы убедиться, что ты прилюдно врёшь как дышишь.
Да, такие вещи раздражают и реакция соответствующая.
Это ж неделовой подход — ты сначала что-то громко рекламируешь, а в итоге выясняется, что тупо воруешь время.
А как же одно из первых твоих сообщений на RSDN об этике инженера?
Это ты сам себя уговаривал, получается, и так и не уговорил до сих пор? ))
Кароч.
Все мы можем ошибаться, я тут не видел ни одного человека, который ни разу бы прилюдно не ошибся.
В реале тем более не видел.
Это наша фича, а не баг.
Баг у некоторых заключается в интерпретации этой фичи. ))
И еще багом у некоторых является тяга к противопоставлению технологий.
Заметь, я противопоставляю не технологии, а подходы к решению задач, сам менталитет инженера-разработчика.
И ты ж должен знать, что многие нейтивные программеры пишут не только нейтивный код.
Что как минимум еще зачастую сопрягают его со скриптовыми или управляемыми языками, как раз выполняя работу изнутри кишок "более прикладных" технологий, т.е. зная и понимая их тонкости.
И что сами эти "более прикладные" технологии почти никогда не критикуются (кроме совсем уж вопиющих моментов, когда плавучку на дотнете даже не пытались оптимизировать в течении 20-ти лет, а потом сделали буквально с полутыка для Core — конкретно мне это навредило в одном из исследовательских проектов, который делал на шарпе, что пришлось уйт ив нейтив и отказаться от кое-какой важной задумки).
Что чаще критикуются неверные ожидания от технологий, ведь неверные ожидания часто приводят к неверным принимаемым решениям.
В общем, очковтирательство — это самое большое преступление инженера, конечно.
Не зря "оно" обыгрывается практически во всех пунктах "инженерной этики", потому что этих очковтирательств много разных — можно врать о мотивах своих принимаемых решений, можно врать о потенциале технологии, можно врать о решениях конкурентов и т.д.
Но врать нельзя.
Ошибаться, исправлять ошибки — можно (обязательно делая работу над своими ошибками, бгг...)
Врать нет.
Просто вы воспринимаете объективные аргументы как нападки на технологии.
И вот это уже "ой".
Простое перечисление характеристик не может быть нападками.
Если вы видите здесь нападки, значит, проблема не в технологиях, а в психике видящих.
Да, над этим периодически стебёмся, бо это ж реально смешно — нахрена тогда вообще в IT сунулись? ))
Я уверен, что пишу кода на Шарпе на порядок-другой больше тебя в течении всех лет его существования.
Простое перечисление характеристик технологий не вызывает у меня батхерта.
Почему вызывает у тебя?
Причём, в клинической его форме, когда ты снова и снова, безо всякого провоцирования, по каждому малейшему поводу пытаешься воевать с виртуальными своими оппонентами? ))
Со стороны — какая-то разновидность мазохизма.
Здравствуйте, vdimas, Вы писали:
V>Это ж надо придумать, чтобы я влез в бинари Решарпера и пошаманил там эдаким образом, чтобы сохранить работоспособность, но чтобы он иногда глючил.
В интернете много упертых идиотов, и не такое бывает.
V>2. Наш код вполне корректен синтаксически и логически, хотя да, нетривиален с т.з. большинства дотнетных поделий;
То есть, черезжопный.
V>3. Выводы не далекоидущие, а самые прямые — основная масса дотнетчиков, даже работающих в ведущих мировых компаниях, откровенно криворуки, безграмотны и наглухо безответственны в разработке аки малые дети, заключительное бгг...
А у меня, например, виртуалбокс нередко падает со странными ошибками. Из чего следует прямой вывод, что основная масса системшиков, даже работающих в ведущих мировых компаниях, откровенно криворуки, безграмотны и наглухо безответственны в разработке аки малые дети
Здравствуйте, Sinclair, Вы писали:
V>>Чтобы "отформатировать диск"? (С) S>Для того, чтобы угрозы проверять. Напомню, речь идёт о софте, выявляющем трояны.
Ну и вот, выявляет трояны байт-код, сам этот байт-код битый, его нельзя исполнять — вдруг это атака?
Правильней будет завершить работу машины до разбирательств.
S>Основное преимущество управляемого кода — как раз возможность изолировать ошибки.
Да ложь это.
Проверка индекса при доступе к массивам — это фича конкретного объекта, а не среды исполнения.
Запросто в опкодах получай ссылку на данные и лезь по произвольному индексу, гадя в произвольную память, бгг...
Что там еще?
Проверка на null перед вызовом метода объекта?
Это и вовсе фича компилятора конкретного языка, который подставляет callvirt вместо call.
В общем, опять и снова ты пытаешься наделить любимый свой класс технологий тем, чем они не обладают или что как минимум перпендикулярно любым технологиями — что байт-кодным VM, что нет.
Да запросто дотнетная байт-машинка и по памяти проходится, и прочие все классы ошибок осуществляет, и нихрена это никак и ничем не "управляется", даром что MS зафорсила этот новый мем. ))
Некую надёжность в safe-режиме дала не VM дотнета, а связка компилятора конкретного языка и возможностей базовых объектов (в т.ч. некоторые из них JIT "знает в лицо").
И всё это за счёт производительности, ес-но.
Но VM тут не при чём, такие же есть и нейтивные технологии, которые тоже разменивают производительность на подстраховку.
А исследовательский проект управляемой ОС окончился ничем, напомню.
Потому что не оттуда и не туда копали, я тебе когда-то объяснял — копать надо было в сторону зависимых типов.
Безопасность будущих программ кроется именно там, а не в байт-коде или нейтивном.
Это вообще условности. ))
V>>Причём, учитывая, что речь о ср-ве обеспечения безопасности, лично я не уверен, что стоит позволять пользователю продолжать работать в скомпрометированной на ядерном уровне среде — вдруг кривой байт-код является способом атаки? S>
ЧТД, ты сам об этом сам не подумал, поэтому ответить тебе нечего.
Плюс ранее в подветке рассуждал о необходимости некоего особого режима для подгружаемого для исполнения кода.
Я на то нубство даже не ответил (и не акцентировал внимание читателей), а зря, получается. ))
Ведь и обычные нейтивные модули тоже "подгружаемые", бгг...
V>>А так уже высмеял твою толерантность к байт-коду — ты снова запросто рассуждаешь о том, что байт-код может быть кривой. S>По-хорошему, байт-код нужно верифицировать, но кто ж знает, что у них там за байт-код. Это ж какая-то самодеятельность.
Да не верифицируется он нигде и никогда даже в случае не самодеятельности. ))
Даже взять самый первый барьер — абсолютно все более-менее полезные дотнетные приложухи имеют унутре unsafe-код.
А после появления в либах объекта-хелпера Unsafe теперь и этого не требюуется — абсоютно все проходы по управляемой или неуправляемой памяти можно выполнять в честном safe-режиме.
Либа эта УЖЕ стала мега-популярной что в коде базовых библиотек, что в прикладном коде, бо позволяет эффективно оперировать данными...
При этом, надёжность кода получается как в С++, только хуже — потому что деструкторы не всегда автоматически вызываются, бгг...
И потому что using-переменная value-типа вдруг становится immutable, и все её начинают через либу Unsafe приводить к мутабельной ссылке и издеваться над ней.
Да кароч, в 2024-м с этим глобальным враньём можно было бы уже и закончить. ))
V>>(Но ни боже упаси будет кривым нейтивный код — тебя порвёт на сотни постов гневно-праведного обличительства, чемпион ты наш по лицемерию) S>"Сотни постов". Ага. Стоило один раз упомянуть, как у vdimas порвался пукан, и нас накрыло коричневой волной.
Не один раз, ты тут несколько раз высказался.
Просто ты не в первый раз высказался.
И просто схема всегда одна и та же — ты тупо гонишь, не разобравшись.
V>>Я думаю, что ты упирался лишь по той причине, что до моего появления в подветке успел наговорить тонны первокласнейшей ереси. S>Ну, то есть вы так до сих пор и не поняли, что никакой ереси я там не нёс
Еще как нёс ересь. ))
Отборнейшую, махровую.
Почитай себя там до моего появления в топике, бгг..
Ты ведь не вникал, как компиляторы обслуживают потенциальные UB?
Не вникал в ретроспективу развития кода компиляторов?
Ты просто придумал себе удобное объяснение, что компилятор — это некий "черный ящик", по мощности сопоставимый с облачными ИИ, и примерно с этих позиций пытался то "объяснить" его поведение "он просто распознал UB" в обсуждениях с другим колегой (чего-чего? ), то, наоборот, ты возмущался тем, что конкретно твой кейз не был распознан.
Нифига себе ожидания...
Пипец махровое нубство. ))
А на деле происходит обратное — компилятор предполагает, что никакого UB нет.
И у него есть такое право — из-за допущения расширения типов промежуточных значений.
Код с volatile я тебе показал сугубо для демонстрации того, как компилятор трассирует точки вычисления.
Что тут может быть непонятно — я уже просто теряюсь.
Ну ты реально тогда считаешь компилятор "черным ящиком", и на этом основании мысленно приписываешь ему любые магические св-ва. ))
S>зато вот над вашими постами смеются примерно все, кто понимает устройство компилятора?
Пытался твой собеседник, который тоже наговорил кучу ереси там.
Я не выбирал кого пороть — сишника или дотнетчика, оба там хороши были. ))
И о каком "понимании устройства" ты сейчас говоришь?
На уровне Ахо+Ульмана? Вирта? Хантера?
В отличие от тебя, у меня достаточно богатый опыт в парсинге, синтаксическом и лексическом анализе, кодогенерации и оптимизации.
А у тебя подготовка по этим дисциплинам банально отсутствует, тут ты пользуешься лишь своим воображением и подвешенным языком, бгг...
Но зато позволяешь себе приёмы "вы, наверно, ничего не понимаете" лишь на том основании, что человек с тобой не согласен.
А я вижу, что ты просто не в состоянии даже понять аргументов, которые тебе приводят.
Но сам ты своих технических аргументов не приводишь, каждый божий раз пытаешься рассуждать о некоей эзотерике для посвящённых.
А кто, типа, наркотикк не вкурил, тому провидение не откроется.
За такие вещи вообще стоило бы пороть, бгг...
V>>И чего там понимать-то в том UB? — прямо по стандарту разрешён промоушен до более широких типов в промежуточных значениях вычислений. S>Ну вот, вы продолжаете позориться.
Это ты продолжаешь не понимать работу компилятора, продолжаешь считать его "чёрным ящиком" с непонятными св-вами.
А там простые if-else, бгг.
Код открыт, иди изучай.
S>Понятно, почему не хотите в форуме название работодателя светить — вдруг коллеги вас поиском случайно найдут, ржать будут годами.
Коллеги мои тут регулярно бывают и ты с некоторыми из них регулярно спорил и так же был не раз прилюдно выпорот, пока на тебя не забили еще лет 15 назад.
Ну реально, не был бы ты настолько нервозно-плодовит в некрасивых своих рассуждениях, что технических, что политических — да плевать на какого-то там фрика, хосподя.
Но у тебя определённым образом подвешен язык — присутствует талант врать, манипулировать, играть на публику, качать эмоции и т.д.
В общем, как вредитель ты весьма талантлив, этого не отнять.
А светить конторы, в которых работаем, в нашей области не принято из-за другого — процветающего HH на уровне хождения на грани порядочности.
(преценденты бывали ранее и продолжают происходить до сих пор у знакомых контор)
S>За истекшее время можно было сходить и найти соответствующий пункт стандарта. Заодно понять, почему он неприменим к рассматриваемому примеру.
Ты про плавучку? ))
Наивный — эту оговорку я уже делал еще тогда.
А чтобы что-то там "понимать", недостаточно надувать щёки.
Надо просто расписать по шагам хотя бы поверхностно алгоритм, каким руководствуется компилятор в той ситуации.
На самом деле там достаточно было быть честным исследователем — потыкать в "черный ящик" палочкой достаточное кол-во раз и понять его реакцию, т.е. вывести алгоритм через почти реверс-инженерию. И вопросы бы у тебя отпали.
Но ты этого не сделал.
Вместо этого у тебя есть некие убеждения, источники которых отсутствуют в природе, бо это синтез порывов твоей души, есть еще упёрство, с которым ты отстаиваешь милые сердцу убеждения, и сверху этого ноль совести, что позволяет тебе быть манипулировать беседой как угодно, работая на читателя.
Не зря же ты регулярно пытаешься опереться на публику — "да это не только я говорил".
Второму там тоже от меня досталось, не переживай. ))
Да хоть сотня вас таких бестолковых будет, тем забавней ситуация, хосподя...
V>>Более того — я показывал тебе ассемлерные распечатки разных компиляторов, где было видно, что те позволяют себе иногда расширять int32 до int64 унутре в регистрах. S>Во-первых, типизация промежуточных значений происходит задолго до того, как появятся какие-то регистры. Так что продемонстрированные вами расширения — это уже фаза кодогенерации, на этом этапе компилятор все семантические оптимизации давно применил.
Т.е. ты не знал, что есть фаза оптимизации при конечной кодогенерации?
И что эта фаза чуть ли не основная по эффективности сегодня?
Семантические, это, надо понимать, альфа, бета и эта-преобразования? ))
Разный семантически код может быть идентичным в регистрах из-за специфики команд процессора (я тебе показывал, где некоторые команды обнуляют старшие байты регистра, а некоторые — нет), оптимизатор это учитывает и много оптимизирует уже на этапе линковки, в т.ч. "склеивает" различный объектный код, который может быть выражен без потери семантики в регистрах одинаковым образом.
А твои "семантические оптимизации" выполняются лишь на стадии генерации объектного кода.
S>Во-вторых, осталось показать, как это работает для суммы двух int256. Куда она там будет расширяться, и почему компилятор позволяет себе выбрасывать код для этого случая безо всякой оглядки на регистры.
__int256 пока что не стандартный тип, тикетов и багов в компиляторах, его поддерживающих, пока хватает.
Вот когда все компиляторы подтянутся, тогда этот тип войдёт в стандарт, а пока что это попытка убежать. ))
Предположу, что пока что "тупо" использовали ту же ветку, что для других целых.
V>>Разумеется, дотнет еще будет развиваться в деле оптимизации, а значит, список его UB будет расширяться примерно так же, как постепенно расширялся список UB в плюсах. S>Впечатляющий пример глобального непонимания. S>1. Не понимаете, что именно делает компилятор, и как он это делает, для конкретного случая.
ЧТД, вместо того, чтобы показать хотя бы схематично свои представления о логике происходящего, ты опять ударяешься в свою эзотерику "вы просто недостаточно просвещённые" ))
(и так каждый раз, бгг)
S>2. Не понимаете, как выводятся типы промежуточных результатов в арифметике C++. В частности, путаете integral promotions с signed overflow.
Если ты пытаешься утверждать, что эти вещи никак не связаны, то ты ошибаешься.
Впрочем, эту ошибку рассуждения я тебе уже показывал схематично на C#. ))
А ты подтвердить свои рассуждения ничем не можешь, заметь, только позицией "А баба Яга против!"
S>3. Не понимаете причин, по которым компиляторы С++ делают именно так.
Но озвучить эти причины, показав хотя бы схематически рассуждения компилятора, ты не в состоянии, верно? ))
S>Заодно не понимаете последствий. В частности, отсюда ваши наивные заблуждения вида "ну вот я давно пишу такое на MSVC, и там всё хорошо".
Я уже лет 30 пишу одновременно для нескольких компиляторов/ОС/платформ.
Т.е. мой код должен исправно работать много где.
Причём, "тепличные" условия для этого случились лишь к концу нулевых, когда компиляторы GCC/ICC/MSVC стали более-менее одинаково понимать и глотать код, а до этого мне приходилось обыгрывать разночтения многих компиляторов, а до конца нулевых еще и многих платформ.
Да, часть используемых когда-то платформ окончательно отсохла вместе с уникальными для них компиляторами, например SPARC, PowerPC и куча тонкостей сверху от различного endianless-представления.
В общем, тебе опять саечку за попытку манипуляции вместо рассуждений по-существу.
S>4. Не понимаете закономерностей развития индустрии, отсюда ваши прогнозы про внедрение UB в дотнете.
Тут речь не о "понимании" (реально задолбал своими впадениями в эзотерику), а о "ванговании".
Я внимательно наблюдаю развитие компиляторов примерно с 92-го года, когда впервые в жизни нашёл баг компилятора в Borland C++ 3.1 и стал тщательно соотносить генерируемый ассемблерный код с исходником все годы затем. И не только на плюсах, ес-но, бо в те года плюсы были для многих задач далеко не самым удобным инструментом. Например, VB генерил более эффективный код при обслуживании COM-объектов, а смарт-поинтеры в плюсах, автоматизирующие время их жизни, спамили ненужными парными AddRef/Release.
По Паскалю и объектной его версии аналогично.
И делал так все годы, благо все 90-е много упражнялся ассемблером в работе.
В том числе использовал Си в микроконтроллерах и все годы, увы, приходилось контроллировать генерируемый компиляторами код.
И в дотнете тоже, ес-но.
И до сих пор та же привычка, бгг...
Эта привычка помогла обнаружить и зарепортить кучу вещей в дотнете, один в GCC (оказался дубликат, но я изобрел обходной путь, бо нам ПРИШЛОСЬ еще много лет поддерживать ту версию GCC-компилятора, бо было много клиентов на RHEL/CentOS 6.x, даже когда уже вышли версии 8.x)
В общем, со мной эта твоя бестолковая болтовня, оперирующая лишь эмоциями и субъективными твоими ожиданиями от технологий приведёт лишь к ответной такой болтовне. ))
Или четко по шагам обсуждать происходящее в техническом плане, или будешь выпорот за каждый косяк в логике спора/аргументации и в целом стрёмных своих манер, бгг...
Например, я увидел достаточно много оптимизаций в 8-м дотнете до написания того своего поста.
Это всё резко отличалось от виденного ранее в течении 24 лет дотнетной истории (ага, я слежу за дотнетом с его беты).
За оптимизацию взялись весьма агрессивно, примерно как за оптимизацию плюсов в 92-93-х годах, что с тех пор его компиляторы ушли далеко в отрыв от других технологий в деле оптимизации.
Почти все трюки применяемых оптимизаций тщательно расписаны для свободно-распространяемых компиляторов: GCC, LLVM.
Так же достаточно много инфы даёт MS по своему компилятору, хотя резко меньше указанных.
ICC меньше остальных, плюс грешил развилками в коде — перенаправлял в высокооптимизированные ветки для интел-процов, и в малооптимизированные для того же AMD.
Ну и плюс, десятки компиляторов С/С++ с тех пор постепенно сдохли, что позволило сосредоточиться на небольшом их множестве и примерно увидеть происходящее.
Так вот, с каждым новым трюком росли требования к самому коду, чтобы этот трюк вообще стал возможным.
Более того, в обсуждениях находятся еще достаточно трюков, введение которых сейчас банально невозможно на текущей кодовой базе.
Теперь про дотнет.
Основной аргумент я тогда же и приводил — ради генерирования нейтивного бинарника и обрезки целевого образа УЖЕ отказались от половины всех свойств дотнета — от рефлексии везде и всюду и от динамической кодогенерации.
Вот тут просто поверь на слово — никогда в истории С++ не было настолько резких изменений оптимизации ради.
Так что даёт тебе уверенность утверждать, что более никаких резких телодвижений в дотнете не будет?
Ну вот взять твой динамический кодогенератор — он ведь заведомо не работает в AOT.
А мои JSON-конфигурации в AOT прекрасно читаются, потому что Рослин! ))
Я бы мог на твой манер сформулировать "сдаётся мне, что не понимает кто-то другой", если бы речь шла о техническом понимании.
Но тут требуется понимание целей и мотивов других людей, а ты не склонен углубляться в других — тебе банально некогда, поддержание внешнего образа себя любимого и неповторимого отжирает тики, выделенные на психологию. У тебя банально не остаётся "мощностей" отслеживать другие порывы людей, кроме как их реакцию лично на тебя, бгг...
(пипец детство)
Причём, эти цели и мотивы людьми нифига не скрываются.
Просто ты пытаешься игнорировать даже то, чем тебе MS натурально под нос уже тычет.
Ты ведь до сих пор на стадии отрицания, а местами заплываешь в стадию гнева, но потом берёшь себя в руки — и опять возвращаешься на первую стадию.
Это малодушие.
Здравствуйте, Codealot, Вы писали:
V>>Было сказано, что BSOD — это штатное ср-во реакции, и что в иных случаях до него даже не доходит. C>Ну тогда любой говнософт, который обрушивает систему, делает все совершенно штатно.
Любой говнософт это сделать не в состоянии — нужен драйвер уровня ядра.
Здравствуйте, vdimas, Вы писали:
V>Любой говнософт это сделать не в состоянии — нужен драйвер уровня ядра.
Кхм, у тебя с русским языком что ли проблемы? Если не обрушивает — значит, это не тот говнософт, про который я писал.
Ну так что, значит, BSOD — это штатный способ обработки ошибок?
V>А они сейчас все подписаны, бгг...
Здравствуйте, vdimas, Вы писали:
V>Ты потерял тот топик? ))
Не, не потерял V>Меня триггернуло даже не в то, что код неверный для большого класса сценариев, а что об этом даже не сигнализируется. V>Ну и, ты в привычной своей манере стал трепать нервы, делая вид, что проблема несущественная. ))
Ну так что за проблема-то?
V>Хотя, у потенциального юзера твоей либы должен был возникает вопрос — а как же оно тогда скомпиллировалось, если неверно работает?
V>А твой подход — заведомый тупик из-за взрывного роста комбинаторной логики в попытках обыграть всевозможные граничные случаи, при том что код кодогенерации наглухо нечитаемый/неподдерживаемый. И ты тоже заранее знал, что подобный код — это классическая лапша.
Чего?
V>Плюс, "захватывать" аж всю сигнатуру 2D-массивов для linq единственной спорной реализацией — такое себе... V>Решение не пострадало бы от введения доп. типа-маркера для Рослина, а даже выиграло бы, бо при таком подходе могло бы сосуществовать более одной реализации/стратегии.
Там есть тип-маркер. При желании, открутить T[,] можно за полчаса. Или перенести в отдельный неймспейс.
Но пока что не видно никаких причин так делать.
V>Но ты многократно упомянул всуе, и как всегда далёким от корректности образом, но так смешно вышло, что единственный, кто вникнул и целиком разобрался был сишник, а не обычные посетители C# топика. ))
Сдаётся мне, что так и не разобрался до сих пор.
V>И сдаётся мне, этот забавный факт сильно повлиял на дальнейшее общение, бгг...
Не, не повлиял. Вы себя дискредитировали задолго до того топика.
V>Я-то свой косяк мгновенно тут же исправил
Продолжается враньё. Не мгновенно, не тут же, а так и не принёс ни разу в топик полного компилируемого кода. V>Вот и вся разница между нами, бгг...
Вот именно. Разница как раз в том, что я написал работоспособное решение, обложил его бенчмарками, и выступил на конференции. А вы просто выёживались, а на все вопросы про код отвечали "да я и не собирался писать корректно — это была просто идея".
V>Помнится, про драйверы баз данных примерно оно же вышло — ты рассуждал о желаемом как об имеющемся, вынудил меня сделать кучу проверок, чтобы убедиться, что ты прилюдно врёшь как дышишь.
Всё как раз наоборот — я с самого начала писал о том, что могло бы быть, о чём была сделана соответствующая оговорка. А вот вы рассуждаете о чём угодно, включая заводы blum на Украине, как об имеющемся, даже после того, как вас носом ткнули. Врёте, как дышите, увы.
V>Все мы можем ошибаться, я тут не видел ни одного человека, который ни разу бы прилюдно не ошибся. V>В реале тем более не видел. V>Это наша фича, а не баг. V>Баг у некоторых заключается в интерпретации этой фичи. ))
Всё верно пишете. Вам осталось научиться применять это к себе.
Я-то всегда готов ошибиться. Тем более, что я — вообще не программист. А вот вы тут в каждом посте бравируете своей якобы супер-квалификацией. Готовы критиковать кого угодно, но только не себя.
V>Но врать нельзя. V>Ошибаться, исправлять ошибки — можно (обязательно делая работу над своими ошибками, бгг...) V>Врать нет.
Тогда вам придётся взять паузу и ничего не постить на RSDN. Я постов, где вы не врёте, за все годы едва парочку могу найти.
V>Просто вы воспринимаете в объективные аргументы как нападки на технологии.
Это у вас голоса в голове. Мне на технологии более-менее всё равно. Я вообще не программист.
V>Я уверен, что пишу кода на Шарпе на порядок-другой больше тебя в течении всех лет его существования.
Я тоже в этом уверен. Тем более, что я — вообще не программист. Я программировал на шарпе профессионально в последний раз в 2006 году.
В том-то и стыдоба, что вас носом в каку тыкает не коллега-нативщик с опытом работы вдвое больше, а тупой продакт менеджер, который работает в основном в Excel и Powerpoint.
V>Простое перечисление характеристик технологий не вызывает у меня батхерта. V>Почему вызывает у тебя?
У меня не вызывает. Это у вас голоса в голове. Батхёрт у меня вызывает, когда люди пишут чушь. Это да, профдеформация такая. Я ж преподаватель
А то, что у вас что-то там не вызывает батхёрта — ну да, ну да. Банальное упоминание о том, что код глючного драйвера был написан на C++, спровоцировало shitstorm. Это называется "не вызывает батхёрта".
Что ж. Не хотел бы я посмотреть на то, как выглядит ваш батхёрт — надо полагать, там Севастополь эвакуировать придётся.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Да ложь это.
Нет, это вы не понимаете. V>Проверка индекса при доступе к массивам — это фича конкретного объекта, а не среды исполнения.
Смотря как реализован доступ к массивам. Например, в дотнете это специальная инструкция байт-кода, за проверку в ней отвечает среда исполнения.
Не получится руками сделать такой же "объект" и не сделать проверку. V>Запросто в опкодах получай ссылку на данные и лезь по произвольному индексу, гадя в произвольную память, бгг...
Это зависит от конкретной среды исполнения. Можно убрать unmanaged pointers, и возможность "лезть по произвольному индексу" исчезнет.
V>Проверка на null перед вызовом метода объекта? V>Это и вовсе фича компилятора конкретного языка, который подставляет callvirt вместо call.
Вы почему-то думаете, что дотнетом исчерпывается мир виртуальных машин. Нет, это не так. Дотнет — компромиссная технология, в нём пришлось принять ряд спорных решений.
Это не означает, что сама по себе идея управляемых сред неверна.
V>Но VM тут не при чём, такие же есть и нейтивные технологии, которые тоже разменивают производительность на подстраховку.
Да без проблем. Давайте, расскажите мне про эти нейтивные технологии. А лучше — не мне, а разработчикам CrowdStrike. А, и ещё авторам видеокодеков, а то Adobe Premiere до сих пор нет-нет, да и упадёт при редактировании видео. Где-то в недрах кодека у него NRE происходит.
V>Потому что не оттуда и не туда копали, я тебе когда-то объяснял — копать надо было в сторону зависимых типов. V>Безопасность будущих программ кроется именно там, а не в байт-коде или нейтивном. V>Это вообще условности. ))
Да, всё верно.
V>Плюс ранее в подветке рассуждал о необходимости некоего особого режима для подгружаемого для исполнения кода.
Чего?
V>Да кароч, в 2024-м с этим глобальным враньём можно было бы уже и закончить. ))
Ну так заканчивайте.
V>Ты ведь не вникал, как компиляторы обслуживают потенциальные UB?
Конечно же вникал. У нас тут как раз курс лекций читался на эту тему — я походил, послушал
V>Нифига себе ожидания... V>Пипец махровое нубство. ))
Учитесь, коллега, никогда не поздно разобраться, как это работает.
V>А на деле происходит обратное — компилятор предполагает, что никакого UB нет.
Нет. V>И у него есть такое право — из-за допущения расширения типов промежуточных значений.
Нет.
V>Ну ты реально тогда считаешь компилятор "черным ящиком", и на этом основании мысленно приписываешь ему любые магические св-ва. ))
Нет, я как раз случайно знаю, как работает компилятор
V>И о каком "понимании устройства" ты сейчас говоришь? V>На уровне Ахо+Ульмана? Вирта? Хантера?
V>В отличие от тебя, у меня достаточно богатый опыт в парсинге, синтаксическом и лексическом анализе, кодогенерации и оптимизации.
Вижу, что опыт этот — в основном воображаемый. V>А у тебя подготовка по этим дисциплинам банально отсутствует, тут ты пользуешься лишь своим воображением и подвешенным языком, бгг...
V>Код открыт, иди изучай.
Отметим, что ссылки на стандарт по-прежнему нет. Ну, можете ссылку на код с if-else мне показать.
V>А светить конторы, в которых работаем, в нашей области не принято из-за другого — процветающего HH на уровне хождения на грани порядочности.
Не переживайте, HH вам не грозит.
S>>За истекшее время можно было сходить и найти соответствующий пункт стандарта. Заодно понять, почему он неприменим к рассматриваемому примеру.
V>Ты про плавучку? ))
Нет, я про int256.
V>Т.е. ты не знал, что есть фаза оптимизации при конечной кодогенерации?
Естественно знал. V>И что эта фаза чуть ли не основная по эффективности сегодня?
Нет, она там в последнюю очередь V>Семантические, это, надо понимать, альфа, бета и эта-преобразования? ))
Я же вам говорил — разработчики компиляторов этими терминами не пользуются. Вы опять выдаёте себя с головой — нет у вас никакого опыта в "парсинге, синтаксическом и лексическом анализе, кодогенерации и оптимизации". В лучшем случае в ВУЗе 30 лет тому назад курсовик делали с разбором Паскаля.
V>__int256 пока что не стандартный тип, тикетов и багов в компиляторах, его поддерживающих, пока хватает.
Ну, пусть будет int128 V>Вот когда все компиляторы подтянутся, тогда этот тип войдёт в стандарт, а пока что это попытка убежать. ))
Не убежите вы никуда. Компилятор все типы обрабатывает одинаково — потыкайте палочкой да убедитесь. Особенности возникают только с типами short и signed char — потому, что для них в стандарте оговорены integral promotions. Никогда компилятор ничего не расширяет шире инта — стандарт ему это запрещает. И сохранение в память тоже не имеет никакого отношения — если так получилось, что на целевом процессоре нет int32 операции, то кодогенератор, естественно, сгенерирует код для int64. Но потом он обрежет результат — даже если этот результат промежуточный, и в память напрямую он никогда не попадёт.
И эзотерика тут ни при чём — обычная инженерная логика.
V>Предположу, что пока что "тупо" использовали ту же ветку, что для других целых. Ваши предположения были бы хороши, если бы вы их подавали с меньшим апломбом и большей скромностью.
Нет, так не работает. Если бы компилятор произвольно расширял сложение, скажем, int64 до __int128, то тогда у нас бы (a+b)/2 работало корректно. Но ведь нет — вы не найдёте компилятора, который бы вам расширил аргументы, сложил, поделил, и потом сузил. Как вы думаете, почему? И зачем он, по-вашему, делает это для случая int64+1?
V>А ты подтвердить свои рассуждения ничем не можешь, заметь, только позицией "А баба Яга против!"
Могу подтвердить ссылкой на стандарт. Но сейчас — ваша очередь.
V>Но озвучить эти причины, показав хотя бы схематически рассуждения компилятора, ты не в состоянии, верно? ))
Я схематически их уже озвучивал.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Codealot, Вы писали:
V>>Это ж надо придумать, чтобы я влез в бинари Решарпера и пошаманил там эдаким образом, чтобы сохранить работоспособность, но чтобы он иногда глючил. C>В интернете много упертых идиотов, и не такое бывает.
Например, в зеркале?
Упёртость и странный ход мысли показал тебе человек оттуда. ))
V>>2. Наш код вполне корректен синтаксически и логически, хотя да, нетривиален с т.з. большинства дотнетных поделий; C>То есть, черезжопный.
Наоборот, в разы прямее, чем 90% стандартной либы. ))
Нам требуется выжимать эффективность, увы.
Или к счастью, бгг...
V>>3. Выводы не далекоидущие, а самые прямые — основная масса дотнетчиков, даже работающих в ведущих мировых компаниях, откровенно криворуки, безграмотны и наглухо безответственны в разработке аки малые дети, заключительное бгг... C>А у меня, например, виртуалбокс нередко падает со странными ошибками.
Ну да, как Оракл его забрал, так постепенно народ от него стал отказываться, и я в том числе, хотя когда-то он был основным инструментом у меня.
Но стал раздражать своими шероховатостями.
В Оракле случилось засилье джавистов и вообще прикладников, и вот тебе результат. ))
Наверно, недостаточно, чтобы спецы "существовали в природе" в некоторой конторе?
Надо еще, чтобы в руководстве должным образом были расставлены приоритеты, не?
C>Из чего следует прямой вывод, что основная масса системшиков, даже работающих в ведущих мировых компаниях, откровенно криворуки, безграмотны и наглухо безответственны в разработке аки малые дети
Это известный демагогический приём, кстате.
Надеюсь, что это вышло у тебя случайно в пылу спора, как и предположение о "допливание Решарпера с целью закидать какашками дотнет", бгг...
Кстате, саму технологию я больше хвалю последние пару лет...
И одновременно выражаю досаду о потерянных 20+ предыдущих.
Но там сейчас нейтивные ребятки рукава засучили, с дотнетом всё будет хорошо.
Я не дотнет ругал, а конкретный программный продукт.
Понимаешь, крупных и заметных приложух на управляемых языках ОЧЕНЬ мало, и только по ним можно делать выводы о состоянии индустрии управляемых языков в целом.
Такова реальность.
А нейтив у тебя вообще везде и всюду, стоит тебе нажать кнопочку "питание" в системнике — и сотни нейтивных подсистем и приложух начинают свою работу.
И не важно что там — линуха, винды или макось.
И как-то ж работает вообще всё?
В общем, с надёжностью Решарпера ты банально не смог бы выполнять за компом повседневные задачи.
И я тут не злорадствую, меня это натурально удручает.
Здравствуйте, Codealot, Вы писали:
C>Ну так что, значит, BSOD — это штатный способ обработки ошибок?
Это штатный способ рапорта об ошибках уровня ядра.
Вернее, финальная стадия этого способа.
Можно подгрузить дамп, коды ошибок и оттрасировать случившееся.
V>>А они сейчас все подписаны, бгг... C>И что? Это говорит только об авторстве.
Таки, BSOD стали очень редки после введения политики подписи драйверов доверенных контор.
Разумеется, все эти вещи не технические, а сугубо организационные, как и обязательная сертификация тех контор по ISO 9000.
Но я именно об отношении к процессу разработки и рассуждал.
Здравствуйте, vdimas, Вы писали:
V>Это штатный способ рапорта об ошибках уровня ядра. V>Вернее, финальная стадия этого способа. V>Можно подгрузить дамп, коды ошибок и оттрасировать случившееся.
Ты так и не ответил на вопрос. Любой софт, который выпал в синий экран, обработал свои ошибки штатно, или все же не любой?
Здравствуйте, vdimas, Вы писали:
V>Например, в зеркале?
Ты же вроде взрослый человек. Должен иметь достаточно интеллекта, чтобы не использовать такой детский аргумент, как "нет ты сам такой".
V>Нам требуется выжимать эффективность, увы.
Оптимизация — как раз тот случай, когда приходится жертвовать всем остальным ради скорости или экономии ресурсов. То есть, писать через жопу, даже если и во имя благих намерений.
V>Ну да, как Оракл его забрал, так постепенно народ от него стал отказываться, и я в том числе, хотя когда-то он был основным инструментом у меня. V>Но стал раздражать своими шероховатостями. V>В Оракле случилось засилье джавистов и вообще прикладников, и вот тебе результат. ))
Это у тебя круговое доказательство.
V>Это известный демагогический приём, кстате. V>Надеюсь, что это вышло у тебя случайно в пылу спора
Тот же самый, который использовал ты. Смайлик про сарказм не заметил?
V>как и предположение о "допливание Решарпера с целью закидать какашками дотнет", бгг...
Нет, с целью не выглядеть треплом. И я про это уже писал. Это к вопросу о демагогии.
V>В общем, с надёжностью Решарпера ты банально не смог бы выполнять за компом повседневные задачи.
Никаких проблем с решарпером у меня нет, как и у подавляющего числа людей. Впрочем, ты уже начал повторяться. Соберись с мыслями.
Здравствуйте, Sinclair, Вы писали:
V>>Да ложь это. S>Нет, это вы не понимаете.
Опять эзотерика? ))
Не надоело?
V>>Проверка индекса при доступе к массивам — это фича конкретного объекта, а не среды исполнения. S>Смотря как реализован доступ к массивам. Например, в дотнете это специальная инструкция байт-кода, за проверку в ней отвечает среда исполнения.
Я и сказал ниже, что некоторые объекты JIT "знает в лицо".
И это не самый эффективный способ итерации по массивам и вообще по данным — не зря сейчас рекомендуют получать Span, и итерироваться уже по нему.
При этом есть способы получения Span, указывающего на произвольный мусор в памяти, с произвольной его интерпретацией или с затиранием произвольного куска памяти, что можно покоцать даже саму VM.
S>Не получится руками сделать такой же "объект" и не сделать проверку.
Это если бы не существовали другие способы — например, есть опкод получения адреса первого элемента массива, именно так читаются составные структуры из массивов.
А затем в опкодах можно этот адрес тупо приращать — и никакой "верификатор-загрузчик" тебе и слова не скажет, бгг...
Но и это слишком сложно, бо массивы тут вовсе не обязательны — бери тело любого объекта, получай ссылку на поле и поступай как описано выше.
Или бери ссылку на локальную переменную/аргумент и т.д.
Кароч, способов развязать руки на манер голого Си полно.
И ты это прекрасно знаешь. ))
Но упорно приводишь в пример лишь безопасные способы.
В любом языке аналогичные безопасные способы есть, конечно, но мы же ругаем языки за наличие опасных способов, т.е. исходя из того, что программисты слишком самоуверенны, но людям свойственно ошибаться.
Так вот, повторю, в дотнете с появлением "официальной" либы Unsafe всё стало ровно так же, как в плюсах, в плане возможностей случайно нагадить.
И даже больше, бо нет детерминированного освобождения ресурсов, т.е. RAII весьма опциональный, а не обязательный.
V>>Запросто в опкодах получай ссылку на данные и лезь по произвольному индексу, гадя в произвольную память, бгг... S>Это зависит от конкретной среды исполнения. Можно убрать unmanaged pointers, и возможность "лезть по произвольному индексу" исчезнет.
Да без проблем — используй managed ссылки.
Это ты был не в курсе или опять прилюдно ломаешь комедию? ))
V>>Проверка на null перед вызовом метода объекта? V>>Это и вовсе фича компилятора конкретного языка, который подставляет callvirt вместо call. S>Вы почему-то думаете, что дотнетом исчерпывается мир виртуальных машин. Нет, это не так. Дотнет — компромиссная технология, в нём пришлось принять ряд спорных решений.
Хорошее слово "пришлось".
Этих "пришлось" было несколько, включая АОТ.
Мне иногда кажется, что JNI с джаве сделали как сделали лишь с той целью, чтобы сопряжение с нейтивом выполняли люди, специализирующиеся на другой технологии.
Потому что дотнет запросто валится даже от корявого P/Invoke, описанного разрабами с другой "планкой входа", бгг...
А ты думаешь, отчего AVK одно время стал настолько раздражителен и спесив, что даже взял второй ник?
Да потому что работает с такими людьми и на фоне их кажется сам себе гигантом мысли, ес-но.
Но нервные клетки, таки, сильно страдают, от непокидающего вечного раздражения.
S>Это не означает, что сама по себе идея управляемых сред неверна.
А никто и не говорил, что эта идея не верна.
Освежи обсуждения еще с 2004-2005-х годов — всегда критиковались лишь завышенные ожидания от этой технологии.
Почему?
Потому что завышенные ожидания выглядят слабостью, эдакой "уважительной причиной" расслабить булки.
И никто не говорил, что GC — днище.
Говорилось другое — что не для всех задач это самая удачная технология.
Скажу так, с какого-то момента в .Net Core у меня вдруг стали резко развязаны руки в плане проектирования данных и алгоритмов, в том числе обобщённых, в том числе, работающих поверх графов неуправляемой памяти наряду с управляемой. А всего-то добавили ограничение unmanaged в генерики и обкатали Span/Memory и... тадаам — обобщили работу с памятью через MemoryManager и паттерны вокруг MemoryHandle. Это было фуф, вытереть пот со лба, наконец-то можно было просто программировать себе без вечного ощущения раздражения из-за убогости доступных платформенных ср-в.
Когда они догадались сделать ref struct одновременно с readonly ref return — да я просто офигел, насколько же там прибавилось здравого смысла у разрабов. ))
Однозначно лайк! ))
Это они одним махом решили очень нетривиальную задачку, которую мы так и не смогли решить эффектвно, на манер как в плюсах — были вынуждены создавать копии данных перед вызовами юзверских колбэков, потому что иначе создавалась дыра — не было защиты от дурака. Теперь есть. А когда добавили scoped — так и вовсе вопрос стал решён даже лучше, чем в С++ (кое-чего мне и в плюсах не хватает, ес-но).
Введение статических методов у интерфейсов тоже неплохо, но это полумера.
По крайней мере, теперь можно избавиться от кучи фабрик на каждый чих, ведь теперь можно прописать абстрактный некий статический Create(args) у интерфейса.
Интересно, догадаются ли они добавить теперь в ограничениях генериков new(args) хотя бы для value-типов, т.е. where T : struct, new(args)? ))
Ведь технически это уже можно сделать без серьёзных доработок (в отличие от такой же фичи для where T : class)
Кодогенерация в процессе компиляции — тоже однозначно лайк.
Немного перемудрили с Рослином (были варианты чуть проще, вернее, можно было дать несколько альтернативных вариантов, где самый сложный был бы самым "общим", т.е. покрывающим все требуемые сценарии). Но один раз разобравшись и накидав своих повторно-используемых хелперов (вручную обыграв более простые сценарии), в принципе, жить можно.
Указатели на методы — ну вообще бомба.
Мы тут же родили легковесную библиотеку-замену делегатам на основе value-типов (включая ср-ва по частичному применению аргументов и прочего из функциональщины).
Видишь, вопрос не может и не должен ставиться "виртуальная машина"/"байт-коды" vs "нейтив".
Вопрос всегда должен быть о наличии тех или иных фич, в том числе объективно возможных или невозможных, из-за конфликта с другими фичами.
Помнишь я говорил лет 10 назад или больше, что хорошие оптимизации в дотнете принципиально невозможны из-за требований обеспечения доступа к объектам и вызова методов в т.ч. через рефлексию? Теперь ОАТ-компиляция убирает это противоречие через убирание доброй половины фич дотнета. ))
В режиме АОТ, если получаешь method handle и получаешь из него адрес метода (а сейчас по адерсу можно этот метод вызвать), то невозможна ситуация, когда делегат указывает на неоптимизированную версию метода, хотя рантайм уже породил оптимизированный его вариант.
V>>Но VM тут не при чём, такие же есть и нейтивные технологии, которые тоже разменивают производительность на подстраховку. S>Да без проблем. Давайте, расскажите мне про эти нейтивные технологии. А лучше — не мне, а разработчикам CrowdStrike. А, и ещё авторам видеокодеков, а то Adobe Premiere до сих пор нет-нет, да и упадёт при редактировании видео. Где-то в недрах кодека у него NRE происходит.
Ты не знаешь таких языков что ле?
Или у тебя в нейтиве как в управляемых средах — очень сложно найти достаточно большой и известный программный продукт? ))
Да почти все продукты, которыми все пользуются — нейтивные.
Конкретно Adobe Premiere — это г-но мамонта из 90-х, контора давно испытывает не лучшие свои времена.
Например, MS Office с тех пор тотально переписали на плюсы за несколько подходов.
Голый сишный код — это ж как ассемблер.
Разумеется, плюсы тоже оставляют все эти опасные входы/выходы на манер либы Unsafe в дотнете, но при этом имеют абсолютно безопасные реализации тех же контейнеров, идиомы уникально или совместно владеемых объектов и т.д., а так же простые ср-ва реализации на библиотечном уровне любых идиом, в .т.ч. NotNull<> безо-всяких пенальти в рантайм.
Я ведь всё еще не о языках/платформах рассуждаю, как ты вечно пытаешься скатиться в эту сторону, я рассуждаю о людях, о подходах к разработке.
Я совершенно уверен (и не раз натыкался на собственном опыте), что никакие самые "безопасные" языки/среды не могут использоваться для отмазок расслабления булок.
В дотнете немного расслабить булки можно только если пользуешься совсем уж всем готовым и оперируешь совсем малым кол-вом приёмов/паттернов.
Но это можно сказать о любой технологии, управляемой или нет.
V>>Ты ведь не вникал, как компиляторы обслуживают потенциальные UB? S>Конечно же вникал. У нас тут как раз курс лекций читался на эту тему — я походил, послушал
Теперь вопрос на засыпку — считал ли компилятор, что у него там UB или нет?
(в твоём примере)
V>>А на деле происходит обратное — компилятор предполагает, что никакого UB нет. S>Нет.
А на деле да.
Компилятор этот момент даже не заметил — для него это обычный код.
Кое-какие явные выверты я обнаруживал только когда подавал заведомый null при вызове метода объекта по указателю — тогда GCC и CLang вели себя весьма странно, в отличие от других компиляторов. Т.е., явно обходили потенциальное UB.
А твой метод был ничем не лучше и ничем не хуже любых других методов, где происходят вычисления.
Причём, мне даже в некоторых конфигурациях удалось добиться того, чтобы тело метода не выкидывалось (подавал туда не константу времени компиляции), а всё-равно ответ выдавал неверный для int в режиме x64 — как раз из-за того же, почему всегда выдавал неверный ответ для short в любой конфигурации — из-за промоушена типа (в давнном случае в регистрах). Похоже, компилятор посчитал это безопасным, не влияющим на семантику (для well-formed кода), ну и вот... Стандарт ему позволяет.
Ты бы мог потратить время на опробование всевозможных типов данных (у меня там сетка была по всем интегральным типам, входящим в стандарт) и по многим компиляторам и их ключах оптимизации.
V>>И у него есть такое право — из-за допущения расширения типов промежуточных значений. S>Нет.
V>>Ну ты реально тогда считаешь компилятор "черным ящиком", и на этом основании мысленно приписываешь ему любые магические св-ва. )) S>Нет, я как раз случайно знаю, как работает компилятор
Вот врун.
Какой именно из кучи их?
И что именно ты "знаешь"?
V>>В отличие от тебя, у меня достаточно богатый опыт в парсинге, синтаксическом и лексическом анализе, кодогенерации и оптимизации. S>Вижу, что опыт этот — в основном воображаемый.
Опыт этот в альфа и бета оптимизации графов вычислений, в оптимизации кодирования состояний автоматов и т.д.
V>>Код открыт, иди изучай. S>Отметим, что ссылки на стандарт по-прежнему нет. Ну, можете ссылку на код с if-else мне показать.
Ну ты же "случайно знаешь", и?
Тебе даже не требуется мне ничего показывать (я не склонен манипулировать давлением на оппонента) — тебе достаточно было бы схематичного объяснения твоих представлений.
Но их никогда не было и не будет.
А те предположения, что ты выдвигал до моего появления в топике — это тебя просто несло.
К тому же, описания полного представления о происходящем так и не было.
(плюс я делал замечания насчёт возможного различного представления знаковых чисел, в некоторых из которых бывает +0 и -0, т.е. критиковал сам способ "решения" задачи is_max)
V>>А светить конторы, в которых работаем, в нашей области не принято из-за другого — процветающего HH на уровне хождения на грани порядочности. S>Не переживайте, HH вам не грозит.
До СВО заваливали каждый месяц и без прямого засвечивания. ))
Сейчас чуть реже, в этом году не более десятка предложений накопилось.
И вообще, складывается ощущение, что с каждым годом всё больше потребность в тех, кто умеет выжимать из компов и сетей производительность.
Хорошо видно, что пошёл мощный откат после идиотизма нулевых.
S>>>За истекшее время можно было сходить и найти соответствующий пункт стандарта. Заодно понять, почему он неприменим к рассматриваемому примеру. V>>Ты про плавучку? )) S>Нет, я про int256.
Это не стандартный тип.
А если сделать его библиотечным — магия не сработает. ))
V>>Т.е. ты не знал, что есть фаза оптимизации при конечной кодогенерации? S>Естественно знал.
Естественно знал, но как обычно в пыу спора забыл.
Потому что не о том думаешь. ))
V>>И что эта фаза чуть ли не основная по эффективности сегодня? S>Нет, она там в последнюю очередь
В последнюю очередь чего?
Эта фаза на сегодня даёт львиную долю прироста эффективности.
Это почему мы свои продукты распространяем в статических либах в основном, чтобы дать возможность поработать LTO у клиентов.
V>>Семантические, это, надо понимать, альфа, бета и эта-преобразования? )) S>Я же вам говорил — разработчики компиляторов этими терминами не пользуются.
Это ты этими терминами не пользуешься.
Или ими не пользовались в просветительских лекциях про компиляторы, на которые ты ходил "послушать", бгг...
Ну конечно, пользуются.
Просто эти термины предполагают некий обязательный бэкграунд для слушателей таких лекций, поэтому с вами могли общаться более приземлёнными терминами — "распространение констант", "преобразования, сохраняющие эквивалентность/семантику" и т.д. ))
И ты уже показывал, что не в курсе, что любые преобразования вычислений, сохраняющие семантику, кроме кеширований значений и перестановок инструкций в императивном коде (оба этих приёма зависят от побочных эфектов), описываются указанными преобразованиями из лямбда-исчисления.
Других в природе не существует.
Замена вызова ф-ии на константу-ответ (с чем ты столкнулся) — это простая бета-редукция.
Введение в C++ constexpr для функций-методов-объектов — это как раз для расширения этой стадии оптимизации.
S>Вы опять выдаёте себя с головой — нет у вас никакого опыта в "парсинге, синтаксическом и лексическом анализе, кодогенерации и оптимизации". В лучшем случае в ВУЗе 30 лет тому назад курсовик делали с разбором Паскаля.
Это тебе так бы хотелось, чтобы самому не выглядеть нубом?
Мне упражняться приходится регулярно.
И вот очередной кодогенератор из DSL приходится пилить, кстате, бгг...
В любом случае, все эти годы ты показывал примерно нулевые знания по теме построения компиляторов, по теме лексического и синтаксичекого анализа, по теме преобразования вычислений, а тут вдруг решил понадувать щеки?
А что произошло?
За ночь подтянул пробелы в образовании? ))
V>>__int256 пока что не стандартный тип, тикетов и багов в компиляторах, его поддерживающих, пока хватает. S>Ну, пусть будет int128
Ну вот у меня в некоторых конфигурациях твоя магия на int128 не работала, хотя работала на int32 и int64.
Я же говорю — ты делаешь слишком дофига допущений/додумываний, вместо честного исследования вопроса.
V>>Вот когда все компиляторы подтянутся, тогда этот тип войдёт в стандарт, а пока что это попытка убежать. )) S>Не убежите вы никуда. Компилятор все типы обрабатывает одинаково — потыкайте палочкой да убедитесь.
Вернись в то обсуждение и освежи — я показывал разное поведение для разных типов.
S>Особенности возникают только с типами short и signed char — потому, что для них в стандарте оговорены integral promotions.
Я показывал результаты уже после внесения необходимых исправлений в твой код с целью нивелирования этого явного эффекта.
Обнаружил, что для некоторых типов он остался неявным, бгг...
S>И сохранение в память тоже не имеет никакого отношения — если так получилось, что на целевом процессоре нет int32 операции, то кодогенератор, естественно, сгенерирует код для int64. Но потом он обрежет результат — даже если этот результат промежуточный, и в память напрямую он никогда не попадёт.
Это ты сейчас цитируешь меня, если что. ))
Но это не относится к промежуточным вычислениям — для них нет такого ограничения.
И тем более это не относится к вычислениям, выполняемым в compile-time — ведь там речь шла о бета-редукции.
Т.е. компиляторам позволялось следующее:
— подставить значение и прогнать его через тело метода, т.е. провести compile-time интерпретацию происходящего, т.е. выполнить β-редукцию; в целочисленных вычислениях, учитывая "тупую обрезку результата" при сохранении его в память, это можно делать на максимально широком типе данных, например на int64 — и получишь описанный эффект;
— выполнить стандартные "символьные" η-преобразования, где x+1<x заменяется сразу на ответ.
S>И эзотерика тут ни при чём — обычная инженерная логика.
Да я давно понял, что ты продаёшь свои собственные представления, хосподя.
И не только я, судя по обсуждениям примерно 15+ летней давности.
Просто с тобой уже никто не общается — не заметил разве?
Ты ж постоянно перегибаешь в своей упоротости.
Ты ж не умеешь спорить — тебя никогда не интересует, собсно, предмет спора, никогда не интересует поиск истины/информации.
Тебя интересует поразвлечься-покрасоваться.
В 40+ это порядком в собеседнике утомляет, ес-но.
S>Нет, так не работает. Если бы компилятор произвольно расширял сложение, скажем, int64 до __int128, то тогда у нас бы (a+b)/2 работало корректно. Но ведь нет — вы не найдёте компилятора, который бы вам расширил аргументы, сложил, поделил, и потом сузил.
Хахаха, в голос просто! ))
Вообще-то, подобные операции есть в некоторых компиляторах над некоторыми архитектурами.
И деление с остатком туда же, и расширение результата вдвое при целочисленном умножении (например, до 128 бит, хотя все регистры 64-битные) и т.д.
Эти вещи специфичные для связки компилятора-проца и в спецификациях отдельно оговариваются.
Другое дело, что требовать этого в стандарте нельзя, но можно не запрещать.
Поисследуй эту тему в процах и компиляторах, там интересно.
S>Как вы думаете, почему?
Потому что ты никогда не задавался этим вопросом?
Потому что вырос на виндах и интел-совместимой архитектуре, и теперь натягиваешь эту сову везде, где дотянешься? ))
V>>А ты подтвердить свои рассуждения ничем не можешь, заметь, только позицией "А баба Яга против!" S>Могу подтвердить ссылкой на стандарт.
Не сможешь.
Никакого одного пунтка, описывающего то поведение, не существует.
Это комплекс работающих совместно эффектов.
S>Но сейчас — ваша очередь.
Выложить тебе на блюдечке весь этот комплекс причин?
V>>Но озвучить эти причины, показав хотя бы схематически рассуждения компилятора, ты не в состоянии, верно? )) S>Я схематически их уже озвучивал.
На мой манер, чтобы не допускать неоднозначных толкований — нет.
И я уверен, что ты специально бегаешь, дабы у тебя были пути отступления в твоём стиле "вы просто неправильно меня поняли", бгг...
Маленькая подсказка — ты в своих тех рассуждениях (в подветке про x+1<x) переборщил с обобщениями.
А так же упустил ретроспективу — почему одни вещи стали допустимыми, а другие нет.
Стандарт ведь не просто так развивался — на каждый чих было очень много и долго обсуждений и опыта в реальных проектах.
Это тебе не стандарты C#, которые стали более-менее обсуждаться только ближе к .Net Core 3.1.
Я ведь хорошо вижу, что обсуждение фич дотнета и компилятора C# всё больше скатывается к тому, как это происходило примерно с конца 90-х в С++.
Именно поэтому я ПРЕДПОЛАГАЮ, что и результаты будут весьма похожими.
Тем более, что похожие результаты уже есть — взять хотя бы сворованные read-only методы структур или ref readonly in/return.
Эти вещи тащят прямиком из плюсов, это const this и const Type &.
Зачем?
Ну я тебе пару раз объяснял-объяснял... тяжело с тобой.
Ну хоть разработчикам дотнета сейчас ничего объяснять не надо — понимают с полутыка.
Предпоследние разы когда репортил 4 года назад — всё было как-то сложно, долго, закрыто.
Последние два раза в позапрошлом году — уже совсем другое кино!
Резко вышли на общение, ПРЕДМЕТНО и эффективно обсудили, взял форк, внёс исправления, их тут же оперативно рассмотрели...
Дали ссылку на обновленную версию потом (чисто жест вежливости) в т.ч. на обновления в документации MSDN (ms-learn сейчас).
Та блин!
А раньше так нельзя было что ле? ))
Когда рапортовал в нулевых про баг в драйвере MS SQL Compact, то в какой-то момент хотелось уже просто послать, бо все входы-выходы дал, а с кем общался — задалбывал на твой манер: "а точно? а не показалось?" — и я должен был подробно расписать ему происходящее через Рефлектор... дурдом какой-то. У них-то исходники, а у меня нет!
Ну я тогда сильно разочаровался в этих дуриках-программерах из MS.
В моем мире такое бараньё не выжило бы, конечно, — быстро бы пошли на воздух всем стадом, бгг...
У меня тогда сложилось стойкое ощущение, что многое в дотнете делается по "остаточному принципу".
Поэтому, открыть исходники дотнета и привлечь сообщество к разработке — это выглядело верным решениям, если сами не тянут с должным качеством (читай — вложениями ресурсов/денег)
Поэтому, Синклер, не в технологиях дело.
Дело в подходе к разработке и только в этом.
И еще в непременном перфекционизме, который без той самой инженерной честности невозможен принципиально.
Враньё себе ведёт к лени ума.
Кстате, на старости это особенно вредно, бо ухудшает когнитивные способности.
Т.е., черты характера способны как продлевать, так и укорачивать жизнь. ))
Здравствуйте, Codealot, Вы писали:
C>Ты так и не ответил на вопрос. Любой софт, который выпал в синий экран, обработал свои ошибки штатно, или все же не любой?
Во-первых, "софт" — это только драйвера для случая BSOD.
Во-вторых, тут возможны как минимум две ситуации:
— штатно отреагировал на ошибку — записал ошибку в системный лог и вернул из вызова (драйверы пишутся по событийной модели) код ошибки с признаком severity=FATAL;
— не создал помех в штатном реагировании на ошибку.
Здравствуйте, Codealot, Вы писали:
V>>Например, в зеркале? C>Ты же вроде взрослый человек. Должен иметь достаточно интеллекта, чтобы не использовать такой детский аргумент, как "нет ты сам такой".
Это самое безобидное.
Зачем тебе дополнительные прилюдные пропесочивания?
V>>Нам требуется выжимать эффективность, увы. C>Оптимизация — как раз тот случай, когда приходится жертвовать всем остальным ради скорости или экономии ресурсов. То есть, писать через жопу, даже если и во имя благих намерений.
Слава богу, сейчас не требуется писать через ж-пу.
Некоторые св-ва дотнета, а именно — генерирование уникального кода генериков, когда аргументы-типы являются value-типами, позволяет резко облегчать код без специальных вывертов и прочих unsafe.
Но шаблонного кода получается много, как и ограничений по нему.
В целом я вижу, что заметно больше, чем в любых других "обычных" проектах.
Да, именно на это я и грешу (на правах гипотезы), что не отменяет факта падучести Решарпера.
Мляха, падать в задаче анализа кода!!!
Мне уже надоело снисходительно улыбаться на эту дичь.
Но я догадываюсь, почему так происходит (по стек-трейсам) — там сыпятся события со всех сторон (обновили файл в файловой системе, или обновили текущий редактируемый файл в редакторе), в общем, выглядит как каша в синхронизации, а результатом такой каши может быть испорченная память.
В таких задачах надо разрабатывать выделенный эффективный диспетчер событий, бо штатные ср-ва дотнета — популярный async и lock(SyncRoot) — это не предназначено для чего-то серьёзного.
Я бы мог им накатать эффективный lock-free диспетчер событий вместе с выработкой общей потоковой модели работы плагина, чтобы такой диспетчер пропускал десятки миллионов событий в секунду в пике и не жрал при этом тики проца, бгг... У них же сейчас резко загружаются куча ядер, что говорит о неэффективности общей схемы обработки событий. Таки, встроенная дотнетная система вокруг Task/ValueTask чудовищно тяжеловесна, т.е. её нельзя юзать на hot-path.
V>>Ну да, как Оракл его забрал, так постепенно народ от него стал отказываться, и я в том числе, хотя когда-то он был основным инструментом у меня. V>>Но стал раздражать своими шероховатостями. V>>В Оракле случилось засилье джавистов и вообще прикладников, и вот тебе результат. )) C>Это у тебя круговое доказательство.
У меня нет других идей, почему VirtualBox стал портиться после приобретения его Ораклом.
Да, я тут малость стебусь, но вряд ли сильно далёк от истины.
Есть такое понятие "по остаточному принципу".
Я думаю, что дело в этом, что это не самый важный для Оракла продукт.
А у кого купили — для тех был самый важный.
Вот такой вот психологический моментик. ))
C>Тот же самый, который использовал ты.
Не, у меня выборка достаточно репрезентативная — ведь дотнетных больших и популярных приложух мало.
Для той же степени репрезентативности в нейтиве нужно указать на многие сотни популярных приложух, которые вечно падают.
Но ситуация так не обстоит.
V>>как и предположение о "допливание Решарпера с целью закидать какашками дотнет", бгг... C>Нет, с целью не выглядеть треплом. И я про это уже писал. Это к вопросу о демагогии.
Я предложил постить тебе каждый день скриншоты падений.
V>>В общем, с надёжностью Решарпера ты банально не смог бы выполнять за компом повседневные задачи. C>Никаких проблем с решарпером у меня нет, как и у подавляющего числа людей.
Да пофик, что у тебя нет проблем.
В этом топике мы обсуждаем проблему, которая коснулась менее 1% от всех участвующих в обновлениях компах — и уже получили самый масштабный за всю историю IT сбой.
Помножь надёжность Решарпера на огромную кучу нейтивного кода, которая выполняется на твоём компе — и ты просто не смог бы работать.
C>Впрочем, ты уже начал повторяться. Соберись с мыслями.
Да, соберись. ))
Не надо считать окружающих за идиотов.
Иногда стоит сделать паузу и помедитировать над тем, что тебе говорят.
Кстате, как пример могу привести исходный код Телеги, библиотеки его специализированной БД и общей их утилитной библиотеки.
Всё писано на плюсах — бэкенд и основные либы фронтенда (В т.ч. на плюсах под винды и на Objective-C для Мака и iOs сугубо GUI).
Весь код открыт.
Я совсем глубоко не вникал и не отлаживал, но регулярно просматриваю тот код.
В общем, подошли к делу серьезно — и свои различные по стратегиям аллокаторы, и свои эффективные очереди, и эффективная сериализация, и lock-free трюки и прочее.
В общем, пишется это достаточно грамотными орлами, которые не боятся пачкать руки об "изобретение велосипедов" (хотя, ничего нового не изобрели, просто разрозненные эти подходы пока мест не существуют в виде единой удобной библиотеки).
Но там виден суровый олдскульный подход, конечно.
И результат тоже налицо — Телега работает наиболее гладко и отзывчиво из всех виденных мною мессенджеров или ср-в коллективной работы.
Никакие Слаки, Тимсы и прочие аналоги от гуглов, или те же whatsapp/вайберы и прочие скайпы и рядом не стояли.
Т.е., казалось бы, все эти годы с начала нулевых нам внушали, что С++ не нужен для таких задач, что его удел — это всякие медиа-кодеки и в лучшем случае другие числомолотилки и то не факт (из-за Питона).
А сейчас ситуация такова, что воцап имеет 2 лярда посещаемости в месяц, а телега уже 1 лярд!
Т.е. новичок почти догнал самого мэтра прошлой эпохи.
И при этом бэкенд воцапа, по слухам, чудовищен в плане занимаемых выч.мощностей, а у телеги — махонький.
И при этом телега предоставляет в разы более шустрый экспиренс загрузки/выгрузки медиа (включая автоматический предпросмотр медиа прямо при проматывании, еще до открытия проигрывателя медиа).
Вот тебе С++ против Эрланга, бгг...
При такой кривой роста посещаемости телега в ближайшие единицы лет обгонит воцап как стоячего, понятно.
И любой желающий может удовлетворить своё любопытство — код ведь открыт!
И сдаётся мне, что бесследно этот опыт для индустрии не пройдёт.
Да уже заметно разворачивание обратно к нейтиву лицом.
Не из-за одной телеги, понятно, это просто очередная крупная капля в эту чашу терпения народа. ))
Здравствуйте, Константин Б., Вы писали:
КБ>Ну т.е. программист должен будет написать вот такое в каждом месте где он разыменовывает указатель?
Макросы плюс библиотечная поддержка.
Ну и, для голого Си можно ограничится пробрасыванием int err_code:
throw_err(EINVAL);
Всё равно нет наследования объектов, поэтому пробрасывать некие объекты из иерархии их бессмысленно.
К тому же, нет конструктора копирования, поэтому выбрасывать исключения-структуры по-значению не выйдет.
К тому же, все указатели равны указателю void*, поэтому пробрасывать исключения-структуры по указателю и типизированно их перехватывать тоже не выйдет.
3. Реальная сложность будет в разметке catch, процитирую себя:
ключевое отличие лишь в том, что setjmp вызывается коде динамически, т.е. некий твой код динамически заполняет структуру jmp_buf, а компилятор генерит таблицу уже заполненных аналогичных структур для ф-ии еще в процессе компиляции.
Т.е. компилятор нифига не помогает в случае Си.
Поэтому, сначала пришлось бы регистрировать обработчики, а потом выполнять целевой код, как-то так:
int do_something(void) {
throw_err(42);
}
int some_fn() {
int rc = -1;
try()
catch_err(42)
printf("Error!!!\n");
end_catch()
catch_err(43)
printf("Warning!!!\n");
end_catch()
rc = do_something();
end_try()
return rc;
}
Здравствуйте, vdimas, Вы писали:
V>И это не самый эффективный способ итерации по массивам и вообще по данным — не зря сейчас рекомендуют получать Span, и итерироваться уже по нему.
Вся разница итерации по массиву и span — это учет дополнительного смещения при считывании адреса элемента для случая с массивами, в span этого нет, потому что там уже сделана поправка на это.
add eax, [rdx+r10*4]
; vs
add eax, [rcx+r10*4+0x10]
^^^^^
public static int Sum_Array(int[] data)
{
var r = 0;
foreach (var v in data)
r += v;
return r;
}
public static int Sum_Span(Span<int> data)
{
var r = 0;
foreach (var v in data)
r += v;
return r;
}
JIT приводит код в такое представление:
public static int Sum_Array_Optimized(int[] data)
{
var r = 0;
var count = data.Length;
if (count > 0)
{
ref var p = ref MemoryMarshal.GetArrayDataReference(data);
for (; count != 0; p = ref Unsafe.Add(ref p, 1), count--)
r += p;
}
return r;
}
public static int Sum_Span_Optimized(Span<int> data)
{
var r = 0;
ref var p = ref MemoryMarshal.GetReference(data);
var count = data.Length;
for (; count != 0; p = ref Unsafe.Add(ref p, 1), count--)
r += p;
return r;
}
И получаем идентичный выхлоп для всех 4 случаев
Sample:Sum_Array(int[]):int
G_M000_IG01: ;; offset=0x0000
G_M000_IG02: ;; offset=0x0000
xor eax, eax
mov edx, dword ptr [rcx+0x08]
test edx, edx
jle SHORT G_M000_IG05
G_M000_IG03: ;; offset=0x0009
add rcx, 16
align [0 bytes for IG04]
G_M000_IG04: ;; offset=0x000D
add eax, dword ptr [rcx]
add rcx, 4
dec edx
jne SHORT G_M000_IG04
G_M000_IG05: ;; offset=0x0017
ret; Total bytes of code 24
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Константин Б., Вы писали:
КБ>>Ну т.е. программист должен будет написать вот такое в каждом месте где он разыменовывает указатель?
V>Макросы плюс библиотечная поддержка.
Ну т.е. каждое разыменование указателя нужно будет в макрос завернуть?
Здравствуйте, rameel, Вы писали:
R>И получаем идентичный выхлоп для всех 4 случаев
Ну какой идентичный, когда речь там шла о безопасности кода?
В случае Array диапазон достоверно берётся у объекта-контейнера и код является абсолютно безопасным, ОК.
Но в случае Span этот диапазон может быть произвольным:
int[] data = { 1, 2, 3};
foreach(var i in data)
Console.WriteLine(i);
var span = MemoryMarshal.CreateSpan(ref data[0], data.Length + 1);
foreach(var i in span)
Console.WriteLine(i);
См., на что именно ты отвечаешь:
S>>Смотря как реализован доступ к массивам. Например, в дотнете это специальная инструкция байт-кода, за проверку в ней отвечает среда исполнения.
V>это не самый эффективный способ итерации по массивам
Т.е. способ итерации array[i], где i пробегает некий диапазон, не самый эффективный, хотя абсолютно надёжный.
(Синклер имел ввиду опкоды семейства ldelem_xxx, я отвечал на это)
И ты ведь показал итерацию по полному массиву.
А теперь проитерируйся по его части, посмотри разницу и помедитируй.
Теперь-то понятно, зачем сначала рекомендуется брать Span от массива и затем итерироваться?
Для итерации по полному массиву брать Span не требуется, конечно.
Мой поинт был в следующем:
— через Span эффективней (и все более и более популярней в реальном коде);
— но через Span можно залезть в произвольную память и наделать делов, в точности как в С++.
/ V>И ты ведь показал итерацию по полному массиву. V>А теперь проитерируйся по его части, посмотри разницу и помедитируй.
Вот чего б самому-то не попробовать?
Не над чем медитировать.
Вот два тела цикла с итерацией по подмассиву:
Какое из них — от Span, какое — от int[]? V>Теперь-то понятно, зачем сначала рекомендуется брать Span от массива и затем итерироваться?
Покамест нет. Проясните, зачем. V>Для итерации по полному массиву брать Span не требуется, конечно.
И по неполному — тоже
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Ну какой идентичный, когда речь там шла о безопасности кода?
Вообще я отвечал на конкретное заявление и речь там шла про эффективность, а не безопасность.
V>И ты ведь показал итерацию по полному массиву. V>А теперь проитерируйся по его части, посмотри разницу и помедитируй.
О том, что нужно проитерироваться по его части речь не шла, это во первых. Во вторых, даже если и так, сильной разницы именно сейчас нет, так как если диапазон нам становится известен только в момент, когда мы хотим проитерироваться, то что я выделю из него этот диапазон и пройдусь по нему, или сразу буду идти нужный диапазон простым и дубовым кодом через for — сильно ничего не поменяется. Ибо, что в первом случае я вынужден проверить, что диапазон валидный, что во втором, только во втором за меня это делает JIT, loop cloning называется, если что.
V>Для итерации по полному массиву брать Span не требуется, конечно.
V>Мой поинт был в следующем: V>- через Span эффективней (и все более и более популярней в реальном коде);
Опять общая фраза, но теперь хотя бы контекст виден.
Мой поинт был в том, чтобы указать, не обязательно тебе, на популярное заблуждение, что span эффективней, чем массивы. А спросишь — в чем эффективней — не знают, просто быстрее и точка.
Здравствуйте, rameel, Вы писали:
V>>Ну какой идентичный, когда речь там шла о безопасности кода? R>Вообще я отвечал на конкретное заявление и речь там шла про эффективность, а не безопасность.
Это называется "потерял контекст" или "заблудился в тёх соснах". ))
Ты ж отвечаешь не на единичное сообщение, а в подветку.
V>>И ты ведь показал итерацию по полному массиву. V>>А теперь проитерируйся по его части, посмотри разницу и помедитируй. R>О том, что нужно проитерироваться по его части речь не шла, это во первых.
Ну и где ты увидел ограничение, что надо проитерировать массив или целиком, или никак?
Это ж попахивает нубством или юлениями, бо в реальном коде массив целиком итерируется крайне редко, т.е. почти никогда.
R>Во вторых, даже если и так, сильной разницы именно сейчас нет, так как если диапазон нам становится известен только в момент, когда мы хотим проитерироваться, то что я выделю из него этот диапазон и пройдусь по нему
Скопируешь в другой массив, что ле?
Что значит "выделю"?
Или, таки, "выделишь" через Span? ))
(что-то уже в голос, сорри... быстро ж ты "поплыл")
R>или сразу буду идти нужный диапазон простым и дубовым кодом через for — сильно ничего не поменяется.
Какое громкое заявление! ))
Ну и что ж ты такой весь в белом притащил тонны ассемблерного кода в предыдущем сообщении, чтобы на весь инет поделиться своими крутыми "знаниями", о которых 99.9% читателей знали еще когда ты пешком под стол ходил еще на бетах дотнета, а теперь почему просто сдулся и выставил себя треплом?
Чтобы не потерять лицо, тебе надо было в предыдущем абзаце сказать всго два слова: "Ой, точно!"
Ну поторопился, ну с кем не бывает...
А сейчас ты себя тупо закопал всем этим идиотизмом.
Кароч, не настолько уж большая была от тебя лажа, чтобы ты так тщательно приступил к юлению.
Теперь взят на карандаш ))
V>>Мой поинт был в следующем: V>>- через Span эффективней (и все более и более популярней в реальном коде); R>Опять общая фраза, но теперь хотя бы контекст виден.
Продолжаешь клоунаду?
Это не "общая фраза", это однозначно понимаемое утверждение, квант знаний в прорве их.
И этот квант стоит учитывать, например, при разработке своих контейнеров вместо тормознутых стандартных (мало ли приспичит).
R>Мой поинт был в том, чтобы указать, не обязательно тебе, на популярное заблуждение, что span эффективней, чем массивы.
Но ты поторопился и ошибся, показав на весь инет, что (а) не владеешь предметом, (б) поленился проверить всевозможные сценарии, (с) не способен признавать косяки.
С таким набором лучше быть ридонли, но тебе зачем-то захотелось общения в этой весовой категории.
R>А спросишь — в чем эффективней — не знают, просто быстрее и точка.
Ты, таки, поитерируй часть массива, посмотри сгенеренную инструкцию CLI, на которую указал Синклер:
в дотнете это специальная инструкция байт-кода, за проверку в ней отвечает среда исполнения
Затем посмотри, что там после джита будет в различных in-force версиях дотнета.
Понимаешь, хотя Синклер, конечно, болтун и склонен преувеличивать (чем зачастую откровенно врёт), но он хотя бы прекрасно понимает, о чём говорит.
Его косяки — они сугубо из-за хождения по грани манипуляций, из-за того, что детстве не пороли за подобное, бгг...
А ты вообще не понимаешь, что тут происходит и зачем.
В общем, извини, но на продемонстрированном тобой уровне понимания как предмета, так и логики взаимных пощипываний, — кыш, кыш, кыш, не мешай взрослым дядькам развлекаться. ))
У них это сугубо ради интеллектуальной физ.зарядки (сорри за тафтологию), ну и местами еще чтобы обкатать собственные мысли или поискать в них дыры усилиями оппонента, бгг...
Здравствуйте, Константин Б., Вы писали:
V>>Макросы плюс библиотечная поддержка. КБ>Ну т.е. каждое разыменование указателя нужно будет в макрос завернуть?
Здравствуйте, vdimas, Вы писали:
V>Это называется "потерял контекст" или "заблудился в тёх соснах". ))
Ты если что спрашивай, подскажу ))
V>Ну и где ты увидел ограничение, что надо проитерировать массив или целиком, или никак? V>Это ж попахивает нубством или юлениями, бо в реальном коде массив целиком итерируется крайне редко, т.е. почти никогда.
Что еще придумаешь?
V>Скопируешь в другой массив, что ле? V>Что значит "выделю"? V>Или, таки, "выделишь" через Span? ))
Выделить диапазон это не обязательно про new, знаешь ли. Впрочем, большего понимания от тебя и не ждут.
V>Ну и что ж ты такой весь в белом притащил тонны ассемблерного кода в предыдущем сообщении, чтобы на весь инет поделиться своими крутыми "знаниями", о которых 99.9% читателей знали еще когда ты пешком под стол ходил еще на бетах дотнета
99.9% читателей может и знали, но это точно не про тебя)
V>Чтобы не потерять лицо, тебе надо было в предыдущем абзаце сказать всго два слова: "Ой, точно!" V>Ну поторопился, ну с кем не бывает...
Обязательно повторяй это по чаще, глядя в зеркало)
V>Продолжаешь клоунаду?
Клоуна здесь только ты из себя изображаешь, но и то не очень как то. Не верю! (с)
V>Но ты поторопился и ошибся, показав на весь инет, что (а) не владеешь предметом, (б) поленился проверить всевозможные сценарии, (с) не способен признавать косяки.
Бросай, все и так знают, что ты (а) не владеешь предметом, (б) поленился проверить всевозможные сценарии, (с) не способен признавать косяки.
V>С таким набором лучше быть ридонли
В точку)
V>но тебе зачем-то захотелось общения в этой весовой категории.
V>Понимаешь, хотя Синклер, конечно, болтун и склонен преувеличивать (чем зачастую откровенно врёт), но он хотя бы прекрасно понимает, о чём говорит. V>Его косяки — они сугубо из-за хождения по грани манипуляций, из-за того, что детстве не пороли за подобное, бгг...
Только все ровно наоборот.
И переставай уже свои детские травмы на других проецировать.
Здравствуйте, Sinclair, Вы писали:
V>>И ты ведь показал итерацию по полному массиву. V>>А теперь проитерируйся по его части, посмотри разницу и помедитируй. S>Вот чего б самому-то не попробовать? S>Не над чем медитировать. S>Вот два тела цикла с итерацией по подмассиву: S>
Слушай, мне аж не верится, что ты на это решился.
"Сгорел сарай — гори и хата!" (С)
Для проверки общего случая достаточно было задать динамически размеры массива и область итерирования:
int count1 = Convert.ToInt32(Console.ReadLine());
int[] array = new int[count1];
int count2 = Convert.ToInt32(Console.ReadLine());
for(int i = 0; i < count2; i++)
Console.WriteLine(array[i]);
var span = array.AsSpan(0, count2);
foreach(var i in span)
Console.WriteLine(i);
И получишь две проверки в цикле для массива, как и ожидается:
G_M27646_IG16: ;; offset=0x010B
cmp r14d, dword ptr [rbx+0x08]
jae SHORT G_M27646_IG23
mov edi, r14d
mov edi, dword ptr [rbx+4*rdi+0x10]
call [System.Console:WriteLine(int)]
inc r14d
cmp r14d, r15d
jl SHORT G_M27646_IG16
V>>Для итерации по полному массиву брать Span не требуется, конечно. S>И по неполному — тоже
И почему ж ты сам не поисследовал тот код?
Я вот поисследовал под 8-м дотнетом и увидел забавное — под линухами JIT сгенерил сразу два цикла — в первый ветвление для случая, когда диапазон заведомо попадает, а во второй — когда не попадает, но итерирование там происходит до момента выхода за границу диапазона.
Причём, это простейший сниппет.
В более общем случае бывают еще выходы из цикла по некоему прикладному условию, бывают оперирования переменной цикла i и т.д.
Для таких более общих случаев был сгенерирован один вариант цикла — тот самый, который "тяжелый", разумеется.
V>>Теперь-то понятно, зачем сначала рекомендуется брать Span от массива и затем итерироваться? S>Покамест нет. Проясните, зачем.
Итого, даже для простейшего случая выгодней сначала получить Span, а потом итерировать, чтобы не получать после JIT два варианта цикла (два варианта не могут быть бесплатнее одного) и чтобы выбрасывать исключение не после частичного итерования массива, а до.
Т.е. в указанном виде через array.AsSpan(range) сразу же произойдёт проверка диапазонов, что добавляет происходящему элегантности — ведь это теперь не надо делать вручную самому, как оно было принято за правило хорошего тона до эпохи Span.
И третья причина — цикл foreach выглядит элегантнее цикла for со счётчиком.
Этот аргумент является совсем уж вкусовщиной и прочими позывами в сторону "избегания синтаксического оверхеда", но, таки, убирание из цикла логики оперирования самим циклом несколько облегчает код, делает его более выразительным. Я такие вещи только приветствую.
Третья с половиной причина — из-за декомпозиции задач формирования диапазона и итерирования, можно (опять элегантно) дополнительно декомпозировать код, т.е. передавать/возвращать Span-ы как аргументы. (В плюсах к этому давно пришли, еще в либе Boost, откуда оно потом переехало в стандарт — такие вещи оставляют меньше простора для случайных ошибок)
Таким образом, всем коллегам настоятельно рекомендую взять за практику итерировать Span-ы, а не массивы.
Абсолютно безопасный вариант указан мною в сниппете выше.
============
И вообще, это мелочная очевиднейшая хрень, зря ты стал "спасать" того коллегу лишь по факту того, что он попытался поддержать тебя в споре. ))
"Поиск поддержки абы от кого" — признак слабости позиции.
Коллеге достаточно было оставаться предметным в споре, даже если он проворонил общий случай.
Но нет!
Чел не оценил предметности разговора, и понеслась моча по трубам, бгг...
Здравствуйте, vdimas, Вы писали:
V>- штатно отреагировал на ошибку — записал ошибку в системный лог и вернул из вызова (драйверы пишутся по событийной модели) код ошибки с признаком severity=FATAL;
Судя по последним новостям, он валился из-за out of bound memory access. То есть, это не тот случай.
V>- не создал помех в штатном реагировании на ошибку.
Например, не рушился при каждой загрузке системы?
Как ты ни крути, а в этом случае разработчики драйвера облажались.
Здравствуйте, vdimas, Вы писали:
V>Это самое безобидное.
Оно же, крайне нелепое. Взрослым людям использовать такой идиотский ответ не подобает.
V>Мляха, падать в задаче анализа кода!!!
Это вообще не проблема, по сравнению с падением при чтении своих собственных конфигов.
V>Мне уже надоело снисходительно улыбаться на эту дичь.
Если это действительно проблема, давно бы разобрался в причинах и натыкал их носом.
V>Да, я тут малость стебусь, но вряд ли сильно далёк от истины.
Да нет, ты опять гонишь пургу. Во всем виноваты джависты и прочие гнусные дотнетчики, даже если в проекте их вообще нет.
V>Да пофик, что у тебя нет проблем. V>В этом топике мы обсуждаем проблему, которая коснулась менее 1% от всех участвующих в обновлениях компах — и уже получили самый масштабный за всю историю IT сбой.
В твоем случае, больше похоже на < 1e-7%
V>Помножь надёжность Решарпера на огромную кучу нейтивного кода, которая выполняется на твоём компе — и ты просто не смог бы работать.
Хоть решарпер, хоть все прочие проги которые работают на моем компе — глючат примерно одинаково.
V>Не надо считать окружающих за идиотов. V>Иногда стоит сделать паузу и помедитировать над тем, что тебе говорят.
Ну ты же считаешь. Вот и медитируй, если считаешь это нужным.
Здравствуйте, vdimas, Вы писали:
V>В общем, подошли к делу серьезно — и свои различные по стратегиям аллокаторы, и свои эффективные очереди, и эффективная сериализация, и lock-free трюки и прочее.
И при этом запускается несколько секунд, и даже переключение между каналами заметно лагает. Где-то они крупно облажались, и никакие аллокаторы с lock-free не помогли.
V>Да уже заметно разворачивание обратно к нейтиву лицом.
Это в какой альтернативной реальности? Сейчас все больше нового софта делают даже не на яве с дотнетом, а на жабаскрипте со сраным электроном.
Здравствуйте, vdimas, Вы писали:
V>Для проверки общего случая достаточно было задать динамически размеры массива и область итерирования:
Приведённый пример порождается для случая динамического размера массива и области итерирования.
V>И получишь две проверки в цикле для массива, как и ожидается: V>
V>G_M27646_IG16: ;; offset=0x010B
V> cmp r14d, dword ptr [rbx+0x08]
V> jae SHORT G_M27646_IG23
V> mov edi, r14d
V> mov edi, dword ptr [rbx+4*rdi+0x10]
V> call [System.Console:WriteLine(int)]
V> inc r14d
V> cmp r14d, r15d
V> jl SHORT G_M27646_IG16
V>
Отож. Как думаете, почему так? И сколько будет проверок, если вместо вызова Console.WriteLine поставить что-то типа s+=array[i], как в исходных примерах?
V>И почему ж ты сам не поисследовал тот код?
Я-то как раз поисследовал. Тем более, что я понимаю, что и почему делает JIT.
V>Я вот поисследовал под 8-м дотнетом и увидел забавное — под линухами JIT сгенерил сразу два цикла — в первый ветвление для случая, когда диапазон заведомо попадает, а во второй — когда не попадает, но итерирование там происходит до момента выхода за границу диапазона.
Именно про это вам писал коллега rameel — "loop cloning". V>Причём, это простейший сниппет.
В этом "простейшем сниппете" вы сравниваете два семантически различных фрагмента кода. Если переписать код так, чтобы фрагменты были семантически эквивалентны, то опять получится одна проверка в цикла.
V>В более общем случае бывают еще выходы из цикла по некоему прикладному условию, бывают оперирования переменной цикла i и т.д.
Бывают. И во всех случаях семантически эквивалентный код порождает эквивалентный asm.
V>>>Теперь-то понятно, зачем сначала рекомендуется брать Span от массива и затем итерироваться? S>>Покамест нет. Проясните, зачем.
V>Итого, даже для простейшего случая выгодней сначала получить Span, а потом итерировать, чтобы не получать после JIT два варианта цикла (два варианта не могут быть бесплатнее одного) и чтобы выбрасывать исключение не после частичного итерования массива, а до.
Ну так JIT за вас не может решить "а давай-ка я буду выбрасывать исключение до того, как будут выполнены Console.WriteLine". Это в С++ UB прямо разрешает компилятору такие вещи — если операция с undefined behavior случается, то это позволяет "произволить" не только результат самой этой операции, но и результаты предшествующих ей операций. А в дотнете стандарт устроен по-другому.
V>Т.е. в указанном виде через array.AsSpan(range) сразу же произойдёт проверка диапазонов, что добавляет происходящему элегантности — ведь это теперь не надо делать вручную самому, как оно было принято за правило хорошего тона до эпохи Span.
Дело не в правиле хорошего тона. Дело в поведении кода. Если у вас по ТЗ нужно сначала вывести все элементы массива, попадающие в заказанный диапазон, и потом выбросить ArrayOutOfBounds, то вы так и пишете, и JIT соответствующим образом это обрабатывает. А если вам по ТЗ нужно сначала убедиться, что заказанный диапазон безопасен, и выкинуть исключение в противном случае, то код без проверки до цикла является ошибкой реализации.
V>И третья причина — цикл foreach выглядит элегантнее цикла for со счётчиком. V>Этот аргумент является совсем уж вкусовщиной и прочими позывами в сторону "избегания синтаксического оверхеда", но, таки, убирание из цикла логики оперирования самим циклом несколько облегчает код, делает его более выразительным. Я такие вещи только приветствую.
V>Таким образом, всем коллегам настоятельно рекомендую взять за практику итерировать Span-ы, а не массивы. V>Абсолютно безопасный вариант указан мною в сниппете выше.
Непонятно, почему вы называете его "абсолютно безопасным". Все приведённые варианты — абсолютно безопасны в том смысле, что там нет ни UB, ни вывода мусора, ни реинтерпретации памяти, ни риска segfault из-за попытки обращения за пределы отмапленного адресного пространства. Программа абсолютно безопасным способом выполняет то, что ей предписано, а в пограничных случаях абсолютно безопасно выкидывает AOOBE.
Разница там — в семантике. Для семантически эквивалентных вариантов можно было бы говорить о разнице в эффективности, но её по факту нет (хотя всего два поста назад вы намекали на обратное).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>Для проверки общего случая достаточно было задать динамически размеры массива и область итерирования: S>Приведённый пример порождается для случая динамического размера массива и области итерирования. V>>И получишь две проверки в цикле для массива, как и ожидается: V>>
V>>G_M27646_IG16: ;; offset=0x010B
V>> cmp r14d, dword ptr [rbx+0x08]
V>> jae SHORT G_M27646_IG23
V>> mov edi, r14d
V>> mov edi, dword ptr [rbx+4*rdi+0x10]
V>> call [System.Console:WriteLine(int)]
V>> inc r14d
V>> cmp r14d, r15d
V>> jl SHORT G_M27646_IG16
V>>
S>Отож. Как думаете, почему так?
Потому что чудес не бывает.
Нельзя одновременно хотеть надёжности не хотеть её.
S>И сколько будет проверок, если вместо вызова Console.WriteLine поставить что-то типа s+=array[i], как в исходных примерах?
И это всё еще хуже, чем array.AsSpan(range) по целому комплексу причин, перечисленных мной.
V>>И почему ж ты сам не поисследовал тот код? S>Я-то как раз поисследовал. Тем более, что я понимаю, что и почему делает JIT.
А что тут понимать-то?
Он всего лишь пытается сохранить семантику, даже если семантика содержит ошибку.
А мы рассуждали о способах эти ошибки избегать.
Видишь насколько дешевы твои манипуляции? ))
"Следим за левой рукой, а фокус производим правой", бгг...
И да, если тело цикла чуть больше тривиального — он не порождает два варианта, порождается лишь "тяжеловесный".
Причём, даже в случае простейшего s+=item, если накопленная сумма s будет доступна и после выброса исключения, то в этот ошибочный вариант заходит и долго пыхтит перед тем, как выбросить исключение.
А на деле, уровнем выше, эта s уже не нужна, но JIT не способен смотреть слишком далеко, пытаясь разгадать намерения программиста.
Все эти доводы ты и сам знаешь как отче наш, но сам себе их не привёл перед тем, как спорить.
Вот цена обсуждений с тобой, бгг...
V>>Я вот поисследовал под 8-м дотнетом и увидел забавное — под линухами JIT сгенерил сразу два цикла — в первый ветвление для случая, когда диапазон заведомо попадает, а во второй — когда не попадает, но итерирование там происходит до момента выхода за границу диапазона. S>Именно про это вам писал коллега rameel — "loop cloning".
С ограничениями:
You must use int, the condition should be less than, increment gap should be one.
V>>Причём, это простейший сниппет. S>В этом "простейшем сниппете" вы сравниваете два семантически различных фрагмента кода.
Ес-но, мы же о безопасности рассуждали.
S>Если переписать код так, чтобы фрагменты были семантически эквивалентны, то опять получится одна проверка в цикла.
Вооот!
За это тебя и не любят в спорах.
В нейтиве ровно та же фигня "если бы" (С)
Ведь зародыш будущей ошибки появляется ровно тогда, когда самоуверенный или ленивый программист не делает лишних проверок.
Разумеется, можно вручную обвешать код проверками и облегчить жизнь JIT-у.
А еще можно вспомнить, что это стало работать вот совсем недавно по меркам жизни дотнета, что сколько я ни смотрел тщательно на выхлоп в течении двух десятков лет — он рожал "тяжелый" цикл, собака.
А еще коммерческие продукты должны поддерживать все дотнетные версии, которые официально в ходу, т.е. приходилось ориентироваться на то, что происходит, скажем, в .Net Core 3.1, даже когда уже вышел .Net 6.0.
Это реальность, в которой приходилось и приходится принимать решения.
V>>В более общем случае бывают еще выходы из цикла по некоему прикладному условию, бывают оперирования переменной цикла i и т.д. S>Бывают. И во всех случаях семантически эквивалентный код порождает эквивалентный asm.
Хотя на практике требуется совсем другое — безопасный и быстрый код при более-менее синтаксической эквивалентности, и, желательно, еще большей синтаксической выразительности.
================
У меня сейчас такое ощущение, что мы с тобой поменялись местами в споре — я топлю за безопасность и выразительность, а ты возражаешь "но если постараться, то ведь можно и ручками допилить примерно до такого же".
Думаю, твоя проблема в том, что нужную и правильную весчь озвучил твой оппонент, что не позволяет тебе "просто согласиться".
V>>Итого, даже для простейшего случая выгодней сначала получить Span, а потом итерировать, чтобы не получать после JIT два варианта цикла (два варианта не могут быть бесплатнее одного) и чтобы выбрасывать исключение не после частичного итерования массива, а до. S>Ну так JIT за вас не может решить "а давай-ка я буду выбрасывать исключение до того, как будут выполнены Console.WriteLine". Это в С++ UB прямо разрешает компилятору такие вещи — если операция с undefined behavior случается, то это позволяет "произволить" не только результат самой этой операции, но и результаты предшествующих ей операций. А в дотнете стандарт устроен по-другому.
Ну так решение может принять программист.
Просто ты никак не можешь под этим подписаться, бгг...
V>>Т.е. в указанном виде через array.AsSpan(range) сразу же произойдёт проверка диапазонов, что добавляет происходящему элегантности — ведь это теперь не надо делать вручную самому, как оно было принято за правило хорошего тона до эпохи Span. S>Дело не в правиле хорошего тона. Дело в поведении кода.
Дело в корректности кода.
Мне забавно, конечно, что ты как аргумент предъявляешь то, что JIT честно пытается выполнить некорректный код.
При том, что мы до этого обсуждали, как сделать код более корректным.
Ладно, тут всё ясно.
Ты "объясняешь" то, что объяснять не требуется, т.е. тупо теряешь лицо переводом стрелок, манипулятивным смещением акцентов.
Что часто эффективность и надёжность обеспечивается лишь выбором того или иного способа решения задачи, в т.ч. через техническую эрудицию — знанием уже существующих ср-в.
Здесь и сейчас я тоже говорил о выборе программиста, а не принципах работы JIT.
Принципы работы JIT — это нечто, даваемое сверху.
И всё что ты говорил — оно как раз в пользу моего варианта, даже когда есть побочный эффект Console.WriteLine(item).
Потому что мой вариант выразительнее, позволяет избежать ошибки выхода за диапазон без лишних рукопашных if и лишних рукопашных выбросов исключений, где эта "лишняя работа" по проверке данных на корректность является источником программистских ошибок в 90% случаев в ПО (или даже больший процент). Как раз там или некорректно проверили (особенно диапазоны, бгг, банальные <, <=, +-1 в смещениях и т.д.), или, довольно часто, вовсе не проверили.
Большинство остальных ошибок ПО, которые "логические" — они часто возникают вне программирования, еще на этапе анализа/понимания предметной области и к ошибкам, собсно, реализации задачи ("тупого кодирования") их отнести сложно.
S>Если у вас по ТЗ нужно сначала вывести все элементы массива, попадающие в заказанный диапазон, и потом выбросить ArrayOutOfBounds
Уф, блин...
Боюсь даже представить, что было бы, начни я пороть примерно это же. ))
Тебя бы порвало от счастья, что оппонент по своей воле пожелал настолько жалко выглядеть.
Реально, завязывай уже с этой хернёй.
По ссылке перечитай меня более молодого и более терпеливого (еще) к вашей братии.
Там все ответы на все вопросы.
Посмотри на сам ход мыслей.
Облом повторяться, а в двух словах такие вещи не распишешь.
Думаю, твоя проблема в том, что нужную и правильную весчь озвучил твой оппонент, что не позволяет тебе "просто согласиться".
И еще проблема в том, похоже, что ты пятой точкой чувствуешь засаду, стоит тебе со мной согласиться. ))
На самом деле, вопрос, можно сказать, жизненно важный.
Тут даже можно на время перестать бодаться и озвучить прямой речью:
— использование Span делает код выразительным и эффективным, оставляет меньше простора для ошибок, связанных с формированием диапазонов, позволяет проводить достаточно дешевую декомпозицию алгоритмов над данными;
— одновременно с этим, через Span можно нарваться на ошибки неаккуратности, присущие нейтивным программам в деле прохода по памяти.
Q. Как безопасно использовать Span?
A. Абсолютно все методы и методы-расширения AsSpan(range) безопасны для строк, массивов, объектов Memory<> и ArraySegment. Также безопасны методы самого Span и все прочие объекты/хелперы, которые используют Span через TryRead/TryWrite/TryParse/TryFormat и т.д.
Q. Где можно нарваться на небезопасность даже в случае safe-кода?
A. При использовании для порождения/реинтерпретации ссылок на память с помощью статических методов у типов Unsafe и MemoryMarshal. Здесь ответственность лежит на программисте.
Здравствуйте, Codealot, Вы писали:
V>>- штатно отреагировал на ошибку — записал ошибку в системный лог и вернул из вызова (драйверы пишутся по событийной модели) код ошибки с признаком severity=FATAL; C>Судя по последним новостям, он валился из-за out of bound memory access. То есть, это не тот случай.
Т.е. ты уверен, что драйвер не обработал эту ошибку и не вернул код ошибки с признаком severity=FATAL?
Откуда ты знаешь такие подробности? ))
V>>- не создал помех в штатном реагировании на ошибку. C>Например, не рушился при каждой загрузке системы?
Ну, в 90-х это был "стандартный" сценарий, почти все тогда умели загружать машинку в отладочном режиме, откатывать последние обновления или удалять некий только что установленный драйвер.
Сейчас это стало проблемой лишь от того, что сей навык был утерян массой пользователей.
C>Как ты ни крути, а в этом случае разработчики драйвера облажались.
Разработчики всей системы, бо пока нет точной информации, где именно возникла ошибка.
Есть мутная информация, что ошибка пришла из байт-кода — тогда причина не в драйвере, а в прикладной части, где драйвер лишь даёт прикладной части доступ к защищённым вещам в памяти и файловой системе.
Но даже там ноль подробностей — гуляют две версии, но ни одна из них не заслуживает доверия.
Сдаётся мне, что подробностей и не будет.
На самом деле для спасения лица компании было бы лучше, чтобы ошибка возникла сугубо в нейтиве, бгг...
Потому что если ошибка в прикладной части вызвала такой сбой, то вопросов станет намного больше, ес-но.
Здравствуйте, Codealot, Вы писали:
V>>В общем, подошли к делу серьезно — и свои различные по стратегиям аллокаторы, и свои эффективные очереди, и эффективная сериализация, и lock-free трюки и прочее. C>И при этом запускается несколько секунд
Сравнивал старый и новый тел, загрузка Телеги на старом 4 секунды, на новом примерно полторы.
Вайбер грузится 8 сек и 3, при том что чатов и обновлений на порядки меньше.
C>и даже переключение между каналами заметно лагает.
Это если в канале накопились сотни сообщений — надо скачать информацию как о примерном объеме этих сообщений, так и близлежащие сообщения от последнего прочитанного, чтобы ты смог сразу же листать. На шустром инете это происходит шустро, на мобильном похуже, ес-но.
Посмотри что в таком сценарии происходит в Вайбере и воцапе и ужаснись — ты по нескольку секунд после переключения можешь пялиться на старые сообщения, не видя новые.
Похоже, Вайбер загружает пропущенные сообщения целиком, в отличие от Телеги, которая грузит их поэтапно и приоритезированно, т.е. ты быстрее получишь те сообщения, которые готов уже посмотреть.
В общем, тут Телега выигрывает с разгромным счётом.
И не только у Вайбера — а вообще у всех.
Взять тот же Слак или Тимс, когда накопились сообщения — это даже несравнимо.
Причём, выигрывает, похоже, сугубо за счёт алгоритмов прикладного уровня — когда и в какой последовательности что именно загружать.
А ведь этот прикладной уровень на более прикладных языках как бы более удобно разрабатывать, не? ))
C>Где-то они крупно облажались, и никакие аллокаторы с lock-free не помогли.
Чтобы так утверждать, да еще в таком окученном деле, как мессенджеры, тебе надо показать альтернативы (хотя бы одну), которые работают лучше.
Я, наверно, пользовался всеми популярными мессендерами еще с 90-х и даже близко находящегося по отзывчивости и общему экспиренсу ничего не видел.
V>>Да уже заметно разворачивание обратно к нейтиву лицом. C>Это в какой альтернативной реальности? Сейчас все больше нового софта делают даже не на яве с дотнетом, а на жабаскрипте со сраным электроном.
Тю, это в нише "мобильного интранета".
Что раньше было тяп-ляп интранет для конкретной маленькой конторки, то сейчас переехало в т.ч. на мобилу.
А в коммерческих приложениях — дудки.
Взять даже популярные мобильные приложения от банков — от электронов и прочей HTML-based чепухи постепенно уходят, кроме последних аутсайдеров, типа Тинькоффа, приложение которого открывается до 15-20-ти секунд на мобильном инете, бгг...
Для сравнения, аппликуха основного моего банка предлагает приложить отпечаток уже через секунду после старта, и, после проверки, еще через секунду-полторы, даёт основной GUI-дашборд.
Здравствуйте, vdimas, Вы писали:
V>Потому что чудес не бывает. V>Нельзя одновременно хотеть надёжности не хотеть её.
Ответ неверный.
S>>И сколько будет проверок, если вместо вызова Console.WriteLine поставить что-то типа s+=array[i], как в исходных примерах? V>И это всё еще хуже, чем array.AsSpan(range) по целому комплексу причин, перечисленных мной. Ну, то есть вы осознали, что промахнулись про эффективность, пришлось переводить разговор на "комплекс причин". Ок, засчитано.
V>Он всего лишь пытается сохранить семантику, даже если семантика содержит ошибку.
Во-первых, с чего вы взяли, что "семантика содержит ошибку"? Возможно, автор так и хотел — вывести не более чем N строк, а AIOOBE успещно перехватывается где-то выше по стеку. V>А мы рассуждали о способах эти ошибки избегать.
Во-вторых, никакого обсуждения способов избегания ошибок не было. Не считать же, в самом деле, выброс AOORE вместо AIOOBE каким-то там "избеганием". V>Видишь насколько дешевы твои манипуляции? ))
Вижу, насколько дёшевы ваши.
V>И да, если тело цикла чуть больше тривиального — он не порождает два варианта, порождается лишь "тяжеловесный".
Давайте посмотрим на какой-нибудь реальный пример.
V>Причём, даже в случае простейшего s+=item, если накопленная сумма s будет доступна и после выброса исключения, то в этот ошибочный вариант заходит и долго пыхтит перед тем, как выбросить исключение.
Повторю неочевидную для вас вещь: такое поведение связано не с плохим качеством оптимизатора, а с требованиями стандарта. "Ошибочность" варианта локально оценить невозможно. V>А на деле, уровнем выше, эта s уже не нужна, но JIT не способен смотреть слишком далеко, пытаясь разгадать намерения программиста.
JIT способен смотреть ровно настолько, сколько попало в его поле зрения. Как, впрочем, и более-менее любой компилятор. Чтобы любой компилятор понял, что s уже не нужна, ему нужно "видеть" весь использующий её код.
Стандартная методика для оптимизаций обсуждаемого типа — инлайнинг. Работает это и в JIT-ах дотнета и джавы, и в GCC, и в LLVM. Нет инлайнинга — нет возможности гарантировать отсутствие побочных эффектов — будь любезен породить семантически корректный код.
V>Ес-но, мы же о безопасности рассуждали.
Неа, вы рассуждали об эффективности. Но пытаетесь мухлевать, как обычно.
V>За это тебя и не любят в спорах.
За то, что я внимательно читаю, и точно пишу?
V>Разумеется, можно вручную обвешать код проверками и облегчить жизнь JIT-у. V>А еще можно вспомнить, что это стало работать вот совсем недавно по меркам жизни дотнета, что сколько я ни смотрел тщательно на выхлоп в течении двух десятков лет — он рожал "тяжелый" цикл, собака. V>А еще коммерческие продукты должны поддерживать все дотнетные версии, которые официально в ходу, т.е. приходилось ориентироваться на то, что происходит, скажем, в .Net Core 3.1, даже когда уже вышел .Net 6.0.
V>У меня сейчас такое ощущение, что мы с тобой поменялись местами в споре — я топлю за безопасность и выразительность, а ты возражаешь "но если постараться, то ведь можно и ручками допилить примерно до такого же".
Не, вы одновременно мухлюете в нескольких направлениях. Например, делаете вид, что не пытались выдать устаревшие знания про оптимизацию циклов в дотнете за какие-то особенные знания, одновременно делая вид, что два кода, выбрасывающих исключения, чем-то отличаются друг от друга в плане безопасности.
V>Ну так решение может принять программист.
Может, конечно. V>Просто ты никак не можешь под этим подписаться, бгг...
Нет, просто утверждение про то, что Span — более эффективный способ итерироваться по массиву устарело примерно тогда же, когда в джит завезли собственно оптимизации Span.
V>Мне забавно, конечно, что ты как аргумент предъявляешь то, что JIT честно пытается выполнить некорректный код. V>При том, что мы до этого обсуждали, как сделать код более корректным.
И как вы определяете, какой из сниппетов более корректный? V>Ладно, тут всё ясно.
Отож.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Сравнивал старый и новый тел, загрузка Телеги на старом 4 секунды, на новом примерно полторы.
Всего то На десктопе примерно столько же.
V>Это если в канале накопились сотни сообщений — надо скачать информацию как о примерном объеме этих сообщений, так и близлежащие сообщения от последнего прочитанного, чтобы ты смог сразу же листать. На шустром инете это происходит шустро, на мобильном похуже, ес-но.
Это происходит и тогда, когда новых сообщений вообще нет.
Так что, закэшировать локально нельзя? Сначала показать старые, потом добавить новые?
Да не, это все забытые технологии древних цивилизаций.
V>Чтобы так утверждать, да еще в таком окученном деле, как мессенджеры, тебе надо показать альтернативы (хотя бы одну), которые работают лучше.
А зачем, собственно? Ты не можешь сам посчитать и прикинуть цифры?
V>Тю, это в нише "мобильного интранета".
Здравствуйте, vdimas, Вы писали:
V>Т.е. ты уверен, что драйвер не обработал эту ошибку и не вернул код ошибки с признаком severity=FATAL?
А у тебя есть данные, что обработал? =)) Ты сам гадаешь на кофейной гуще, но все равно делаешь далеко идущие выводы.
А вообще странно. Неужели даже конкретной инфы, что там за бсод, нигде нет?
V>Сейчас это стало проблемой лишь от того, что сей навык был утерян массой пользователей.
Уверен, что этому нет никаких других причин?
V>тогда причина не в драйвере, а в прикладной части, где драйвер лишь даёт прикладной части доступ к защищённым вещам в памяти и файловой системе.
Тогда нет причин, почему эту ошибку нельзя обработать, не обрушивая систему.
Здравствуйте, Codealot, Вы писали:
V>>Сравнивал старый и новый тел, загрузка Телеги на старом 4 секунды, на новом примерно полторы. C>Всего то На десктопе примерно столько же.
Ну так тел же перегружается крайне редко, даже не каждый месяц, так что в обычном сценарии под видом запуска приложения тычком по пиктограмме происходит переключение на уже открытое несколькими неделями раньше приложение, это вообще доли секунд.
V>>Это если в канале накопились сотни сообщений — надо скачать информацию как о примерном объеме этих сообщений, так и близлежащие сообщения от последнего прочитанного, чтобы ты смог сразу же листать. На шустром инете это происходит шустро, на мобильном похуже, ес-но. C>Это происходит и тогда, когда новых сообщений вообще нет. C>Так что, закэшировать локально нельзя? Сначала показать старые, потом добавить новые? C>Да не, это все забытые технологии древних цивилизаций.
Это всего лишь вопрос выбора стратегии.
На старом медленном интернете, разумеется, имело смысл сначала показать старое, а потом уже подгружать новое.
На быстром инете имеет смысл подгрузить несколько новых сообщений перед переключением в другой канал/чат плюс информацию о кол-ве непрочитанных сообщений, чтобы сразу же читать ближайшие новые сообщения и видеть, сколько всего непрочитанных.
V>>Чтобы так утверждать, да еще в таком окученном деле, как мессенджеры, тебе надо показать альтернативы (хотя бы одну), которые работают лучше. C>А зачем, собственно? Ты не можешь сам посчитать и прикинуть цифры?
Что и как считать?
Я почти не пользовался Телегой до СВО, как и большинство знакомых (потому и не пользовался — ведь это был, в основном, yet another messanger).
Но баны на ютубе и других платформах, плюс удобство ведения каналов в Телеге резко повысили популярность телеги в странах экс-СССР с началом СВО.
И вот тут сравнил с привычными до этого вайберами, воцапами, слаками, скайпами, зумами и т.д.
Если инет не совсем дохлый, то Телега удобнее в разы как для ленты новостей, "плоского" форума, так и в кач-ве обычного чата с контактами или в группах.
По крайней мере, чаты всех групп, в которых состоял, за эти 2 с лишним года переехали с вайберов/воцапов/скайпов в телегу, и не по моей инициативе.
Т.е. народ дружно сошёлся во мнении, что Телега удобней/приятней.
V>>Тю, это в нише "мобильного интранета". C>К сожалению, не только.
Ну вот был у меня клиент-банк еще одного неосновного моего банка (у меня их пяток) — приложуха от банка Точки.
Тормознутое г-но когда-то.
В прошлом году полностью переписали — теперь летает.
А взять клиент-банк ОТП-банка (бизнес-клиент), дык, он изначально, такое ощущение, что на чём-то совсем нейтивном работает, типа QT (на правах гипотезы), бо работает совсем мгновенно, хотя у него и не самый удобный GUI (больше кликов надо для того же).
Здравствуйте, Codealot, Вы писали:
V>>Т.е. ты уверен, что драйвер не обработал эту ошибку и не вернул код ошибки с признаком severity=FATAL? C>А у тебя есть данные, что обработал? =)) Ты сам гадаешь на кофейной гуще, но все равно делаешь далеко идущие выводы.
Да потому что у любой виденной мною виртуальной машинки есть ср-ва реагирования на ошибки в байт-коде.
Отсюда и предполагаю, что вызвавшая сбой ошибка в байт-коде была расценена VM как фатальная, т.е. "невозможно продолжать работу".
Это просто единственный сценарий, который ложится на опыт работы со многими виденными байт-машинками и интерпретаторами p-кода, и не более того, ес-но.
А предполагаемые Синклером причины (его там слишком несло, почему я и вмешался) — они попахивают фантастикой, противоречат даже его собственному опыту, бгг...
Точных деталей ни у меня, ни у него нет, понятно, но если брать вероятности из опыта индустрии — то Синклер однозначно гонит.
Его предположения, даже если ему очень хотелось, чтобы было именно так, необходимо было преподносить аккуратно и с оговоркой, что вероятность исчезающе мала.
Т.е. налицо тупая ангажированность.
C>А вообще странно. Неужели даже конкретной инфы, что там за бсод, нигде нет?
Есть картинки в инете, там два кода ошибки, и?
Это ж надо посмотреть системный лог и загрузить дамп в память отладчика, чтобы оттрассировать произошедшее.
А если рядом не положить PDB — то раскопать реально произошедшее будет оч сложно.
Т.е., проще всего это сделать разрабам, конечно, которые обязаны компилять релизы с PDB, и хранить их у себя как раз для таких случаев.
V>>Сейчас это стало проблемой лишь от того, что сей навык был утерян массой пользователей. C>Уверен, что этому нет никаких других причин?
Если я вижу в инете пошаговую инструкцию для этого сбоя "загрузиться в отладочном режиме и откатить обновление"?
Видя такую "инструкцию" уже не знаешь — плакать или смеяться. ))
V>>тогда причина не в драйвере, а в прикладной части, где драйвер лишь даёт прикладной части доступ к защищённым вещам в памяти и файловой системе. C>Тогда нет причин, почему эту ошибку нельзя обработать, не обрушивая систему.
Своё предположение я уже выдал — тут стоит помнить, что это система по обеспечению безопасности.
И что причина существования модуля драйвера этой системы — это предоставлять остальной части доступ к памяти других процессов и к защищённым файлам.
Т.е., косяки в байт-коде могут означать скомпрометированность системы, например, в результате атаки.
В этом случае драйверу лучше отвалиться, чем продолжать предоставлять в юзверское кольцо исполнения дыру для доступа куда угодно.
Здравствуйте, Codealot, Вы писали:
V>>Это самое безобидное. C>Оно же, крайне нелепое. Взрослым людям использовать такой идиотский ответ не подобает.
Ну, я обычно использую "правило 3-х раз", когда коллега переходит все границы в общении.
У тебя это уже второй, бгг...
В общем, стоит отделять случайные эманации от преднамеренной зловредности.
=========
По этой же причине я не одобряю взаимные упрёки в демагогии — это неконструктивно.
Обструкции стоит подвергать намеренные манипуляции.
В этом смыслу обвинение в демагогии (да еще по незначащим вещам) — тоже разновидность манипуляции.
Рассуждения тут такие — демагогия часто бывает непреднамеренной, из-за неудачного аргументирования и т.д., т.е. сам факт случайного прибегания к демагогии еще не означает, что оппонент ошибается — чаще в спорах это означает лишь, что аргументация хромает и могла бы быть чуть лучше.
Другое дело, когда к демагогии прибегают систематически с целью манипуляций, да и вообще спор идёт не ради добычи полезной инфы или установления истины, а ради желания некоторых почесать своё ЧСВ (или, наоборот, полелеять комплексы/мозоли) за счёт других.
Вот тут я позволяю себе резкости — у меня дофига нарушений и банов. ))
Ну а что делать с подлецами?
Здравствуйте, rameel, Вы писали:
V>>Ну и где ты увидел ограничение, что надо проитерировать массив или целиком, или никак? V>>Это ж попахивает нубством или юлениями, бо в реальном коде массив целиком итерируется крайне редко, т.е. почти никогда. R>Что еще придумаешь?
Наоборот — убираю лишние ограничения и частности.
А попытку их ввести называют "придумываниями" ))
V>>Скопируешь в другой массив, что ле? V>>Что значит "выделю"? V>>Или, таки, "выделишь" через Span? )) R>Выделить диапазон это не обязательно про new, знаешь ли. Впрочем, большего понимания от тебя и не ждут.
Из встроенных ср-в, помимо Span, выделить диапазон можно еще через Memory и ArraySegment, где Span — самый эффективный, а Memory — самый тормознутый.
Я предлагаю выделять в Span — а ты начинаешь странно вилять, бгг...
Чем тебе именно Span не угодил? ))
V>>Ну и что ж ты такой весь в белом притащил тонны ассемблерного кода в предыдущем сообщении, чтобы на весь инет поделиться своими крутыми "знаниями", о которых 99.9% читателей знали еще когда ты пешком под стол ходил еще на бетах дотнета R>99.9% читателей может и знали, но это точно не про тебя)
Эти вещи на сайте обсуждали еще в 2002/2003-х годах, если что.
V>>Но ты поторопился и ошибся, показав на весь инет, что (а) не владеешь предметом, (б) поленился проверить всевозможные сценарии, (с) не способен признавать косяки. R>Бросай, все и так знают, что ты (а) не владеешь предметом, (б) поленился проверить всевозможные сценарии, (с) не способен признавать косяки.
Но предметно возразить не в состоянии?
Ну вот Синклер пытается рядом, но выходит убого — чел пытается подменить рассуждения о способах достижения надёжности и эффективности рассуждениями о сохранении семантики ошибочного кода!
(когда от такой цели отказались — и он прямо это проповедует)
Какая благородная и полезная подмена понятий, однако. ))
Вот что бывает с теми, у кого не хватает мужества произнести простое "ой, точно!"
Лучше же себя закопать еще глубже, бгг...
V>>но тебе зачем-то захотелось общения в этой весовой категории. R>
Таки, тщательнее надо.
Твоё "присоединение" к спору было донельзя наивным.
А если решил "выживать до последнего", то юлить тоже надо уметь.
Или не юлить вовсе.
V>>Понимаешь, хотя Синклер, конечно, болтун и склонен преувеличивать (чем зачастую откровенно врёт), но он хотя бы прекрасно понимает, о чём говорит. V>>Его косяки — они сугубо из-за хождения по грани манипуляций, из-за того, что детстве не пороли за подобное, бгг... R>Только все ровно наоборот.
Ровно наоборот что именно?
Ты уже не в состоянии отличить простую подачу инфы от манипуляций/демагогии, что ле?
И тут у тебя наивность наивностью погоняет? ))
У Синклера любимый трюк из демагогии (связка сразу из двух их) — это резко сменить топик или акцент на другую тему, "доказать" там свою правоту (1-й приём демагогии), споря при этом с вымышленным собеседником (хотя по этому левому моменту с ним никто не спорит и даже не собирался — 2-й приём демагогии) — и по итогу выставить себя правым "в целом", хотя от обсуждения топика трусливо уклонился.
Это такое, блин, детсадище и потеря лица, что я ХЗ зачем он делает это снова и снова, хотя его каждый божий раз ловят за шкирку и как нашкодившего щенка в собственное д-мо тыкают.
Это банально оскорбительно даже — всерьёз считать, что такие фокусы могут пройти.
Разве для тебя новость, что общение может быть оскорбительным не обязательно по форме, но и по содержанию? ))
R>И переставай уже свои детские травмы на других проецировать.
Пфф...
Есть такая стратегия: получил от ситуации урок — запомнил, а на саму ситуацию забил, проехал.
Т.е. будь мужиком, не уподобляйся некоторым тут.
Здравствуйте, Codealot, Вы писали:
C>Оно же, крайне нелепое. Взрослым людям использовать такой идиотский ответ не подобает.
Кстате, прошёлся по своим банам и обнаружил странное — часто сообщение не улетает в Мусор, даже если было достаточно резким.
Просто наказали баном и всё.
Но зато в Мусор стабильно улетают сообщения, в которых резкостей всего на пол-шишечки (полюбуйся рядом от себя — намного речзе всё), зато по-сути накидали манипулятору за шиворот, что не смог унести, бгг...
Наблюдай, что делает Синклер тут:
(S — это он)
S>>втирал, что "гораздо быстрее и удобнее" расплатиться с продавцом вовсе не бесконтактной оплатой с авторизацией отпечатком (или вовсе без неё, если платим часами), а из дома, с десктопа, при помощи клиент-банка для юрлиц и электронного USB-ключа.
CC>Я правильно понимаю что в данном раскладе мы стоим прямо перед продавцом и он протягивает нам wave pass терминал?
Конечно, нет.
А как вообще можно расплатиться десктопом на кассе, что за бред?
"Остапа понесло" (С)
Проповедника малость занесло как-то, когда стал домогаться до коллег с той навязчивой идеей, что по десктопу по клиент-банку долго, а по мобиле быстро, хотя на деле всегда наоборот — до нескольких раз разница усилий/времени не в пользу мобильного клиент-банка чуть ли не во всех операциях.
Многие ж пользуются и тем и тем почти ежедневно, вы не внушите мне, что у меня 17 ног, если я каждый день вижу только две))
Немножко потрунили над блаженным и махнули рукой.
Кисо обиделось, теперь бегает по всем форумам и передёргивает всё забавней.
Теперь взял новую высоту — теперь уже речь изначально шла о расплате на кассе, а vdimas прибежал на эту ситуацию со своим десктопом.
Силён, силён...
И насколько храбр!
Я бы засцал настолько лицо терять. ))
Обидчивое оно наше, увлеклось в пылу передёргивания, и случайно забыло, что бесконтакная оплата не имеет к клиент-банку никакого отношения, ни к мобильному, ни к веб-версии.
Это на предмет того, каково оно выходит спорить с обладателем модерских полномочий.
Не просто ж так чела заносит, бгг?
По-сути того спора: прошло много лет, но ситуация не изменилась — как было на десктопе большая часть операций более удобна, так и есть до сих пор.
По мобиле разве что деньги физ.лицу с карточки кинуть проще.
А выставить счета, оформить платежи юр.лицам или гос-ву, принять валюту, закинув док-ты на валютный контроль, обменять валюту — с мобилы это всегда застрелиться.
А да, насчёт обменять валюту в паре банков из 5-ти легко и по мобиле, но это только по внутреннему хреновому курсу банка.
А где через биржу — это или не поддерживается на мобиле, или задолбаешься.
Зато достаточно просто на десктопе.
Синклер как обычно довёл всё до абсурда "заплатить на кассе", хотя там не требуется мобильный клиент-банк вовсе, бгг...
Ну и всё, где его макнули в его собственное Г — сообщения стабильно улетают в Мусор. ))
Здравствуйте, vdimas, Вы писали:
V>Ну так тел же перегружается крайне редко, даже не каждый месяц, так что в обычном сценарии под видом запуска приложения тычком по пиктограмме происходит переключение на уже открытое несколькими неделями раньше приложение, это вообще доли секунд.
Это уже оправдания пошли. Работает небыстро, но это врде как неважно. А как же выжимание самых последних байтов и тактов, и так далее?
V>Это всего лишь вопрос выбора стратегии. V>На старом медленном интернете, разумеется, имело смысл сначала показать старое, а потом уже подгружать новое. V>На быстром инете имеет смысл подгрузить несколько новых сообщений перед переключением в другой канал/чат плюс информацию о кол-ве непрочитанных сообщений, чтобы сразу же читать ближайшие новые сообщения и видеть, сколько всего непрочитанных.
Ну так переключение каналов все равно заметно лагает.
V>Что и как считать?
Например посчитать сколькими сообщениями оперирует прога, и как быстро это должно работать и сколько памяти использовать — в теории, если исключить фактор кривых рук.
V>Ну вот был у меня клиент-банк еще одного неосновного моего банка (у меня их пяток) — приложуха от банка Точки. V>Тормознутое г-но когда-то. V>В прошлом году полностью переписали — теперь летает.
Одно исключение ничего не доказывает. Вот, к примеру, наоборот — MS Teams. Мне нужно было использовать по работе, и это просто полный п*ц в плане скорости и памяти. И выжирания батареи. Казалось бы, за каким хреном там понадобился электрон? Да и за каким хреном такое говно как электрон вообще существует?
Здравствуйте, vdimas, Вы писали:
V>Да потому что у любой виденной мною виртуальной машинки есть ср-ва реагирования на ошибки в байт-коде. V>Отсюда и предполагаю, что вызвавшая сбой ошибка в байт-коде была расценена VM как фатальная, т.е. "невозможно продолжать работу".
Ну судя по последним новостям, косяк был именно в коде вм. Так что ты мимо попал
Здравствуйте, vdimas, Вы писали:
V>Ну, я обычно использую "правило 3-х раз", когда коллега переходит все границы в общении. V>У тебя это уже второй, бгг...
Я просто не вижу никаких причин просто так взять и верить каким-то случайным людям из интернета, особенно когда дело касается спора на что-то материальное. И вдвойне особенно если они по другим вопросам уже понаписали пурги.
Тебя это удивляет?
Здравствуйте, Codealot, Вы писали:
V>>Ну так тел же перегружается крайне редко, даже не каждый месяц, так что в обычном сценарии под видом запуска приложения тычком по пиктограмме происходит переключение на уже открытое несколькими неделями раньше приложение, это вообще доли секунд. C>Это уже оправдания пошли.
Пытаешься создать видимость спора?
Лучше проверяемыми аргументами.
C>Работает небыстро, но это врде как неважно. А как же выжимание самых последних байтов и тактов, и так далее?
Если не выгружаешь приложение и не запрещена его фоновая работа, то де-факто работает быстро.
Думаю, под этот сценарий приложуху и затачивали.
А у тебя какая версия? ))
V>>Это всего лишь вопрос выбора стратегии. V>>На старом медленном интернете, разумеется, имело смысл сначала показать старое, а потом уже подгружать новое. V>>На быстром инете имеет смысл подгрузить несколько новых сообщений перед переключением в другой канал/чат плюс информацию о кол-ве непрочитанных сообщений, чтобы сразу же читать ближайшие новые сообщения и видеть, сколько всего непрочитанных. C>Ну так переключение каналов все равно заметно лагает.
Это если давно не запускал и накопились сообщения.
В сравнении с чем, на минуточку? ))
У воцапа начинается просто бешенная иллюминация в канале в этом сценарии.
И вообще, только Телега обеспечила приемлимый сценарий подписки одновременно на большое кол-во групп, где большой трафик сообщений.
В сравнимом сценарии воцап и вайбер банально не живут, пользоваться невозможно.
Аналогично невозможно пользоваться мессенджерами ВК и FB в таких сценариях — потребляют терпение как упомянутые выше два.
V>>Что и как считать? C>Например посчитать сколькими сообщениями оперирует прога, и как быстро это должно работать и сколько памяти использовать — в теории, если исключить фактор кривых рук.
Не знаю как в теории, а на практике вызывать обновление экрана при приёме сообщений из накопленной очереди их — это и есть кривые руки.
Причём, это считалось плохим тоном еще в эпоху Win95. ))
Но беда воцапа не только в клиентском приложении — я же вижу, что сообщения из этой очереди накопленных их приходят устройство банально медленней.
Т.е., серверная инфраструктура воцапа тормозит. Или протокол обновления информации неэффективный. Или и то, и другое.
В телеге эта операция, считай, мгновенная.
Ну и, сколько бы сообщений ни было в очереди — ты всегда получаешь ограниченную сверху задержку лишь на первые N сообщений, остальные грузятся в фоне.
И эта задержка фиксирована, что-то доли одной секунды.
Т.е. если новые сообщения не пришли — будет как в воцапе.
Именно поэтому нет смысла сначала переключаться в канал, а затем его обновлять, бо сложность ограничена сверху и даже на 4G даже в нашей провинции каналы переключаются незаметно глазу, к тому на уже обновлённую инфу.
А если инет паршивый, то поведение того же воцапа и вовсе убогое.
В общем, конкурирующие приложения надо сравнивать в одновременно в различных сценариях.
Скажу так, на Телегу я перешёл одним из последних в окружении и стал совсем активно пользоваться вот только с началом СВО, и тут же оценил икпиренс именно при работе с большим кол-вом активных групп/каналов — в этом сценарии Телега мгновенно отправила ВК, Воцап и Вайбер в 19-й век. ))
V>>В прошлом году полностью переписали — теперь летает. C>Одно исключение ничего не доказывает. Вот, к примеру, наоборот — MS Teams. Мне нужно было использовать по работе, и это просто полный п*ц в плане скорости и памяти. И выжирания батареи. Казалось бы, за каким хреном там понадобился электрон? Да и за каким хреном такое говно как электрон вообще существует?
Slak аналогично.
Но там них расфуфыренное представление блоков для плагинов и для сайтов (вернее, для ссылок, конечно), подерживающих те или иные "стандарты" метаинформации (в кавычках, бо стандарты эти не отраслевые, а де-фактовые, например, как у FB). Плагины (в т.ч. встроенные) рендерят HTML, его в любом случае чем-то надо отображать.
ИМХО, для этих вещей стоит пользоваться упрощёнными и более шустрыми вещами, типа Sciter-а.
Здравствуйте, Codealot, Вы писали:
V>>Да потому что у любой виденной мною виртуальной машинки есть ср-ва реагирования на ошибки в байт-коде. V>>Отсюда и предполагаю, что вызвавшая сбой ошибка в байт-коде была расценена VM как фатальная, т.е. "невозможно продолжать работу". C>Ну судя по последним новостям, косяк был именно в коде вм. Так что ты мимо попал
Ты опять пытаешься "перебрасывать горячий пирожок", что ле? ))
Косяк был в байт-коде, который невозможно было исполнять.
Просто некоторые ангажированные, типа Синклера (это просто нарицательный уже персонаж, дело не только в нём на этом сайте) привычным движением пытаются "перекидывать пирожок" на машинку VM, мол, та должна была каким-либо образом обыграть ситуацию невалидного байт-кода.
Т.е., некоторые вредители последовательно задвигают тот тезис, что к байт-коду не обязательно применять накопленные в IT практики, что это "просто песочница, с которой низкий спрос".
То бишь, пропагандируют заведомо низкое кач-во кода.
И если на прикладном уровне подобный вред еще хоть как-то можно нивелировать, то для уровня ядра невалидный байт-код означает невалидный драйвер целиком.
А учитывая, что конкретно этот драйвер ядра предоставляет байт-коду доступ к памяти и диску в обход любой защиты, то наилучшим сценарием будет прекратить работу драйвера, ес-но.
Я в курсе, что под "давлением общественности" компания быстренько выпустила заплатку, и вот тут началась вторая волна гонений на компанию — как раз от таких, как я.
И эти гонения пошли уже не дилетански-эмоциальные, а в виде вопросов по-существу. ))
Понятно, что контора позже сделала "как надо", но в момент выдачи первой версии исправления, контора, по-сути, раздала потенциальный троян... Т.е. включился счётчик времени — кто раньше успеет? — зловредные хакеры с подготовленной атакой на "патч" или релиз нормальной версии, где VM опять не позволит невалидному байт-коду работать? ))
Здравствуйте, Codealot, Вы писали:
V>>Ну, я обычно использую "правило 3-х раз", когда коллега переходит все границы в общении. V>>У тебя это уже второй, бгг... C>Я просто не вижу никаких причин просто так взять и верить каким-то случайным людям из интернета, особенно когда дело касается спора на что-то материальное. И вдвойне особенно если они по другим вопросам уже понаписали пурги. C>Тебя это удивляет?
По каким еще "другим вопросам", специалист по передёргиваниям ты наш?
Ты ж почитай себя: "тут смотрим, тут не смотрим, тут делаем вид, что ОК".
Ты необъективен, ангажирован, склонен игнорить "неудобные" тезисы...
И, тот самый главный признак упоротости — склонен повторять сам себя, без продвижения в обмене аргументами.
Это ж залётище. ))
Ты ж давно созрел быть поротым за это в хвост и гриву, просто тебе пытались показывать малость другой потенциальный сценарий.
Однобитных тут и так хватает, досадно наблюдать монотонный рост их кол-ва...
В общем, не уподобляйся тем некоторым, которых бесит сам факт несогласия с ними, бо они ходят сюда из весьма стрёмных побуждений (т.е. забавных своих комплексов).
Большинство же коллег ходят сюда для обмена инфой и возможности пообкатать свои рассуждения на контр.аргументах коллег.
Адекватный оппонент именно ждёт возражений/дополнений и готов к ним.
А неадекватная реакция на возражения говорит лишь о том, что спорить такому лицу противопоказано в принципе.
Рулить должны факты, логика и непременная беспристрастность, а не насосы из пальца, где 100% букв поста выходят из сплошных оценочных суждений.
В этом топике многие за свою пристрастность и зацикливание на оценочной болтовне заслужили бы кучу предупреждений на том же стек-оверфлоу.
Смотрю, некоторым демократия во вред, бгг.
Т.е., дело не только в хамстве — если чел по ту сторону экрана делает только малейшие попытки нарушать здравую логику спора, ему можно сразу же выписывать жёлтую карточку.
Ты уже дважды грубо нарушил логику спора, при этом приводишь те самые стремные оправдания своим поступкам, да еще в хамовитой манере.
Если вас раскатали в споре, это не значит, что оппоненты "гнали пургу", это значит, что вы заняли контрпродуктивную позицию "А Баба-Яга против!", оно же — "хоть кол на голове теши!"
Т.е., никакие аргументы вам не нужны.
Ну, дык, тогда не засоряйте эфир, если обмен аргументами вас напрягает.
Здравствуйте, vdimas, Вы писали:
V>Если вас раскатали в споре, это не значит, что оппоненты "гнали пургу", это значит, что вы заняли контрпродуктивную позицию "А Баба-Яга против!", оно же — "хоть кол на голове теши!"
Здравствуйте, Codealot, Вы писали:
V>>Если вас раскатали в споре, это не значит, что оппоненты "гнали пургу", это значит, что вы заняли контрпродуктивную позицию "А Баба-Яга против!", оно же — "хоть кол на голове теши!" C>Ты там под наркотой, что ли?
Сам дурак.
Ты хоть что пытаешься-то доказать-то?
Какой у тебя поинт?
Я свой обозначил сходу: байткод — это такой же код, который требует такого же внимания, как и любой другой.
Все эти годы высказываюсь против отношения к виртуальным машинкам как к чему-то, что должно прощать программерам грехи, что обязано создавать разрабам расслабленность булок, бгг...
В этом смысле называю Синклера и других, поддерживающих подобную чухню, вредителями.
Ты-то за ради чего туда захотел?
Здравствуйте, Codealot, Вы писали:
C>Чувак, ты вообще в себе? Они совершенно примитивно накосячили с валидацией данных из своего конфига и словили выход за границу массива.
Ну вот ты и подставился, молодец...
Чувак, если у тебя с чтением проблемы — пользуйся хотя бы переводчиками, что не выглядеть случайным на этом сайте. ))
Там написано не про массив как элемент ЯП, а про "массив данных", где из контекста было понятно, что это разнородные данные — поля некоей сущности (объекта) в памяти.
Ошибка случилась из-за того, что объект в памяти, созданный интерпретатором, был "короче" на одно поле (всего 20 полей, а должно было быть 21).
C>Никаких "это они просто так ошибку обработали", про что ты пытался втирать.
А что тебе тут было не понятно?
The Content Interpreter expected only 20 values. Therefore, the attempt to access the 21st value produced an out-of-bounds
memory read beyond the end of the input data array and resulted in a system crash.
Я тебе и на дотнете точно так же могу всё уронить, если полезу за пределы памяти объекта, и никакой валидатор не спасёт, бгг...
Кароч, не можешь сам разобраться — лучше спрашивай. ))
============
Вдогонку.
Причём, в дотнете вокруг объекта обычно дофига выделенной и закомиченной под процесс памяти, т.е., чтобы нарваться на AV, необходимо обычно промазать очень далеко за память объекта.
Т.е. дотнет маскирует ошибки подобного рода.
В принципе, определённый элемент везения в произошедшем есть, что словили AV и таким образом оперативно обнаружили косяк. ))
Здравствуйте, vdimas, Вы писали:
V>Ты хоть что пытаешься-то доказать-то?
Конкретно по вопросу о решарпере ты гнал пургу. Если он и падает, то это конкретно у тебя с твоим кодом, и если это действительно происходит часто, то почему ты этот вопрос не решил — непонятно.
Собственно, всё.
Здравствуйте, vdimas, Вы писали:
V>Ну вот ты и подставился, молодец...
Это тебе почудилось. Не знаю что ты там употребляешь, но лучше завязывай.
V>Я тебе и на дотнете точно так же могу всё уронить, если полезу за пределы памяти объекта, и никакой валидатор не спасёт, бгг...
Интересно посмотреть, как ты этого добьешься без ансейфа.
V>Причём, в дотнете вокруг объекта обычно дофига выделенной и закомиченной под процесс памяти, т.е., чтобы нарваться на VA, необходимо обычно промазать очень далеко за память объекта. V>Т.е. дотнет маскирует ошибки подобного рода.
Здравствуйте, Codealot, Вы писали:
V>>Ну вот ты и подставился, молодец... C>Это тебе почудилось. Не знаю что ты там употребляешь, но лучше завязывай.
Мде...
Завязывай надувать щёки.
Ты прочитал по диагонали, не разобравшись, но спеси тут развёл — меня чуть не вырвало. ))
Суть произошедшего понятна — конфликт метаинформации, из-за чего две взаимодействующие подсистемы рассматривали лейаут объекта в памяти по-разному.
Тут даже не принципиально, что с одной стороны видели объект с 20-ю полями, а с другой с 21-м.
Конфликт метаинформации — это потенциально неверная реинтерпретация памяти.
Это и без AV серьёзнейшая ошибка.
(AV — это большое везение, повторюсь)
Вот у меня и возникает вопрос — а как так-то?
Вопрос риторический понятно, бо ответ мне хорошо известен — усилиями многих вредителей в отрасли вокруг байт-кодов сложилась нездоровая атмосфера эдакого всепрощенчества.
Мол, "оно всё равно проще и безопасней, можно лишний раз не париться".
Ты ж почитай того, кто тебе плюсовал — Синклера.
У меня порой волосы дыбом встают от настолько наивных рассуждений, высказываемых на самых серьёзных щах.
Иногда охота спросить: "Ну ты ведь шутишь, правда?" — а вот нихера, чистосердечно чел с ума сходит, бгг...
V>>Я тебе и на дотнете точно так же могу всё уронить, если полезу за пределы памяти объекта, и никакой валидатор не спасёт C>Интересно посмотреть, как ты этого добьешься без ансейфа.
Например, через создание Span произвольного размера от произвольной управляемой ссылки через InteropServices.
Или через стандартную либу System.Runtime.CompilerServices — прибавляй к управляемой ссылке произвольное смещение и "щупай" память, рано или поздно наткнёшься на AV.
V>>Причём, в дотнете вокруг объекта обычно дофига выделенной и закомиченной под процесс памяти, т.е., чтобы нарваться на VA, необходимо обычно промазать очень далеко за память объекта. V>>Т.е. дотнет маскирует ошибки подобного рода. C>Очень интересно. Где тебе про это рассказали?
Это я наблюдаю каждый день, в т.ч. в экспериментах, в том числе в профайлере смотрю на блоки памяти.
В том числе специально воспроизводил ошибочные сценарии и наблюдал, как это контролирует платформа.
Аж никак.
Здравствуйте, vdimas, Вы писали:
V>Там написано не про массив как элемент ЯП, а про "массив данных", где из контекста было понятно, что это разнородные данные — поля некоей сущности (объекта) в памяти. V>Ошибка случилась из-за того, что объект в памяти, созданный интерпретатором, был "короче" на одно поле (всего 20 полей, а должно было быть 21).
Ну, чистаа теоретицки это могло быть и массивом указателей, и это очень вероятно согласно типовому стилю написания. Типа, как в main() предполагается, что argv[2] присутствует всегда, и его можно разыменовать, а вызов с 1 аргументом приводит к NPE. Но это не обязательно, могло быть и более переменной сущностью — тут фиг их знает.
(Из курьёзов: argv[0] может тоже быть NULL. Часто код на этом спотыкается. Linux в таком случае явно подставляет пустую, но определённую строку.)
V>Я тебе и на дотнете точно так же могу всё уронить, если полезу за пределы памяти объекта, и никакой валидатор не спасёт, бгг...
Ну разница в том, что на дотнете тебе надо явно заниматься извращениями, которые относительно легко найти в коде, а тут вообще проверки не было по сути. Сотворили "виртуальную машину" вообще без защиты — и, согласно документу, вместо нормальной защиты в самой машине добавили проверку на уровень-два раньше.
Я так понимаю, эта машина по сути больше похожа на переносимый рантайм для C, чем для явы, дотнета и иже с ними. Таких тоже было полно — P-code Паскаля, вирт. машина EFI, и прочая.
V>В принципе, определённый элемент везения в произошедшем есть, что словили VA и таким образом оперативно обнаружили косяк. ))
Да, если бы оно начало просто читать другие аргументы, могли годами не найти.
Здравствуйте, Codealot, Вы писали:
C>Конкретно по вопросу о решарпере ты гнал пургу.
Факты.
C>Если он и падает, то это конкретно у тебя с твоим кодом
На разных машинах.
В течении многих лет, т.е. на всех последних его версиях в каждый момент времени.
Код корректный, компилируется и прекрасно работает.
Сам Решарпер официально купленный в максимальной (всеязыковой и всетулзовой) поставке.
C>и если это действительно происходит часто, то почему ты этот вопрос не решил — непонятно.
Я периодически разрешаю Решарперу отсылать ошибки.
Т.е., всё зависящее от меня делаю.
Дали бы мне доступ к сырцам — давно бы исправил, как вносил исправления в исходники и документацию дотнета, например.
C>Собственно, всё.
Ты просто насмешил своей упоротостью и всё.
И было бы ради чего. ))
Если бы ты был разрабом Решарпера, то твой спор отдавал бы душевной болезнью, бо надо было просить переслать тебе ошибки и стек-трейсы (они и так отсылаются внутренним обработчиком ошибок).
А если ты левый чел со стороны, то оно вдвойне лол, такая "заинтересованность", бгг...
Ну давай посмотрим, вдруг я и правда чего-то не учел.
V>Суть произошедшего понятна — конфликт метаинформации, из-за чего две взаимодействующие подсистемы рассматривали лейаут объекта в памяти по-разному.
И это привело к выходу за массив, а не ошибке типизации или сериализации, или что там еще у них происходило.
Если ты не облажался, то выхода за массив у тебя быть не должно. Всё остальное — всего лищь оправдания.
V>Вопрос риторический понятно, бо ответ мне хорошо известен — усилиями многих вредителей в отрасли вокруг байт-кодов сложилась нездоровая атмосфера эдакого всепрощенчества.
Да ладно, не втирай. Во времена доминирования крестов говнокодеры были такие же, и львиная доля кода работала только благодаря тому, что звезды на текущий момент стояли в правильных созвездиях. Достаточно вспомнить про цирк с CString.Format("%s")
V>Например, через создание Span произвольного размера от произвольной управляемой ссылки через InteropServices.
Это разве не ансейф?
V>Это я наблюдаю каждый день, в т.ч. в экспериментах, в том числе в профайлере смотрю на блоки памяти.
"Мамой клянусь" — это не аргумент. Нужно посмотреть на конкретные доки и/или данные, которые можно проверить.
Здравствуйте, Codealot, Вы писали:
V>>Суть произошедшего понятна — конфликт метаинформации, из-за чего две взаимодействующие подсистемы рассматривали лейаут объекта в памяти по-разному. C>И это привело к выходу за массив
За "массив данных" в тексте, плюс говорилось о полях объекта, плюс язык статьи предназначен для неспециалистов, но из описательной части видно, что произошёл выход за границы лейаута объекта в памяти.
А это уже не столь тривиально, как выход за границы массива-сущности ЯП, но в этих тонкостях разбираются только специалисты-айтишники, что выход за пределы данных при обращении к полю структуры — это более обескураживающий сценарий, чем оперирование невалидным индексом при обращении к массиву.
C>а не ошибке типизации
Это ошибка типизации, произошедшая из-за отсутствия полноценной метаинформации в рантайме VM, где такой рантайм следит за тем, чтобы информация о типах была синглтоном.
Это должно объяснять, почему AOT в дотнете не спешат делать для модулей (DLL/so), а лишь для приложения целиком, бо можно нарваться на похожие эффекты.
C>Если ты не облажался, то выхода за массив у тебя быть не должно. Всё остальное — всего лищь оправдания.
А кто перед кем тут оправдывается?
Что за манеры переводить обсуждение технических вещей в тыкание друг друга пальцами?
V>>Вопрос риторический понятно, бо ответ мне хорошо известен — усилиями многих вредителей в отрасли вокруг байт-кодов сложилась нездоровая атмосфера эдакого всепрощенчества. C>Да ладно, не втирай. Во времена доминирования крестов говнокодеры были такие же, и львиная доля кода работала только благодаря тому, что звезды на текущий момент стояли в правильных созвездиях. Достаточно вспомнить про цирк с CString.Format("%s")
Ну да, теперь говнокодеры подались в другие языки, с другой "планочкой входа".
Теперь пишут на шарпах еще смешнее:
if (result.ToString().ToUpper() == "TRUE")
О чём и речь, что борьбу с говнокодерством некоторые несознательные трансформируют в борьбу с языками.
За это и порка. ))
V>>Например, через создание Span произвольного размера от произвольной управляемой ссылки через InteropServices. C>Это разве не ансейф?
Запретить unsafe в проекте можно, и когда-то возможность такого запрета подавалась "железобетонным аргументом", почему я и привёл примеры для safe-кода.
V>>Это я наблюдаю каждый день, в т.ч. в экспериментах, в том числе в профайлере смотрю на блоки памяти. C>"Мамой клянусь" — это не аргумент. Нужно посмотреть на конкретные доки и/или данные, которые можно проверить.
Это просто делёжка информацией, а не "мамой клянусь", бо слишком тривиальные вещи.
Я тебе дал сразу два способа, которые ты можешь проверить за единицы минут.
=============
Вдогонку.
Мне шарп нравится, это удобный инструмент для многих задач.
Мне не нравится отношение некоторых весьма продуктивных здесь в общении товарищей к шарпу и к области байт-кодов в целом.
Ребятки классически с водой выплёскивают ребенка. ))
Здравствуйте, Codealot, Вы писали:
V>>Т.е., всё зависящее от меня делаю. C>Баг зарепортил?
Отвечал на это заранее:
Я периодически разрешаю Решарперу отсылать ошибки.
Т.е., всё зависящее от меня делаю.
И своё мнение насчёт причин ошибки я высказывал выше — вряд ли можно настолько налажать в коде, собсно, анализа кода, тем более, что ошибки показывают различные стек-трейсы.
Это инфраструктурная ошибка у них — одна из самых популярных (а меня часто бросают на поиски "непонятных" ошибок), где такие ошибки возникают из-за ошибок синхронизации/актуализации данных. И почему-то в проектах на шарпе в различные годы я наблюдал таких ошибок в разы больше, чем в плюсах. ИМХО, и тут "планочка входа" подвела.
Собсно, весь этот async в шарпе не столько выпрямляет событийный код, сколько пытается избавить говнокодеров от инфраструктурных ляпов, беря инфраструктуру на себя.
V>>А если ты левый чел со стороны, то оно вдвойне лол, такая "заинтересованность", бгг... C>Факты, которые я наблюдаю своими глазами, говорят мне, что ты гонишь пургу. Собственно, всё.
Это у тебя классический "Чайник Рассела" получается. ))
Здравствуйте, vdimas, Вы писали:
V>Отвечал на это заранее:
Нет, не делаешь. Вполне очевидно, что сделать все это от тебя зависящее — это зарепортить баг на их сайте и дать им хорошего пинка.
V>Это у тебя классический "Чайник Рассела" получается. ))
На самом деле, ровно наоборот . Ты заявляешь, что твой чайник твои баги существуют и очень серьезные, но ничем это не подтверждаешь.
Когда покажешь багрепорт с деталями и ответом от их кодеров — тогда и будет о чем говорить, а пока ты только сотрясаешь воздух. И сам факт что ты этого еще не сделал говорит не в твою пользу.
Здравствуйте, vdimas, Вы писали:
V>Это ошибка типизации, произошедшая из-за отсутствия полноценной метаинформации в рантайме VM, где такой рантайм следит за тем, чтобы информация о типах была синглтоном.
Нет, это ошибка, которая произошла из-за отсутствия проверки типов.
V>А кто перед кем тут оправдывается?
Ну вот ты зачем-то пытаешься придумывать оправдания говнокоду.
V>Запретить unsafe в проекте можно, и когда-то возможность такого запрета подавалась "железобетонным аргументом", почему я и привёл примеры для safe-кода.
Интероп — никак не safe.
V>Это просто делёжка информацией, а не "мамой клянусь", бо слишком тривиальные вещи.
Здравствуйте, Codealot, Вы писали:
V>>Это у тебя классический "Чайник Рассела" получается. )) C>На самом деле, ровно наоборот . Ты заявляешь, что твой чайник твои баги существуют и очень серьезные, но ничем это не подтверждаешь.
(зевая)
И это говорит тот, кому я предлагал слать скриншоты и/или стектрейсы происходящего.
Заигрался ты малость в манипуляции... ))
Ты пытаешься подвести тему к чайнику Рассела, о чём я и постебался, собсно:
Это у тебя классический "Чайник Рассела" получается.
Процитированное — моё обвинение в адрес твоей "тактики" спора, бгг...
C>Когда покажешь багрепорт с деталями и ответом от их кодеров — тогда и будет о чем говорить
При доступе к сырцам это имеет смысл — я бы тогда расписал суть бага.
А коль у них есть целая подсистема перехвата и аплоада ошибок, то о систематичной глючности своего кода они и так прекрасно в курсе, и так прекрасно получают диагностику. Напомню, что дотнет формирует стек-трейс вместе со значениями всех аргументов вызовов по цепочке их.
Да и, в описаниях релизов нон-стоп звучит о пофикшенных багах и возросшей надёжности, что сходу делает твои рассуждения неадекватными реальности.
Здравствуйте, vdimas, Вы писали:
V>И это говорит тот, кому я предлагал слать скриншоты и/или стектрейсы происходящего.
Завязывай сотрясать воздух и просто сделай багрепорт.
V>Напомню, что дотнет формирует стек-трейс вместе со значениями всех аргументов вызовов по цепочке их.
Очень интересно. Где ты нашел такую информацию?
V>Да и, в описаниях релизов нон-стоп звучит о пофикшенных багах и возросшей надёжности, что сходу делает твои рассуждения неадекватными реальности.
Это касается вообще любого продукта. Чего ты сказать то хотел?
