Здравствуйте, 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 эффективней, чем массивы. А спросишь — в чем эффективней — не знают, просто быстрее и точка.
Смайлик про сарказм не заметил?
