Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Кто кому должен? Я же не собираюсь прерывать отладку, пересобирать все, если мне понадобилась новая утилита прямо по ходу отладки. А потом, через полчаса еще одна. И так, пока баг не найдется.
НС>1) Для debugging и profiling api не нужно ничего пересобирать, подключаешься к работающему процессу.
Я тебе про действия после подключения к процессу, а ты мне про само подключение Как ты понял мое объяснение про хуки я даже и не знаю.
НС>2) Нормальное логирование и метрики — обязательное требование к production коду.
Это общие слова, то есть, ни о чем. Раз я влез отладчиком, значит тех логов уже недостаточно. Как минимум, log level для продакшна и отладки разный. А еще есть компоненты, которые, скажем, можно контролировать еще более детально, нежели log level debug.
НС>3) Любое выражение можно вычислить в отладчике в процессе отладки, не правя при этом код.
Мне надо не просто вычислить, а инструментировать приложение, кое что подпатчить, кое что симулировать итд итд итд.
НС>>>Какие такие заготовки? О чем ты? I>>Чтобы вызвать код, он где то должен быть написан до момента вызова.
НС>Совсем не обязательно.
Давай пример, как вызвать код, который еще не написан.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Евгений Акиньшин, Вы писали:
V>>>Уже попросила ориентироваться только на .Net 5.0, а с выходом LTS .Net 6.1 (скорее всего именно такая версия будет LTS) — и вовсе .Net Standart уйдёт в неподдерживаемое состояние. V>>>И тогда степень совместимости с .Net Core разработчики Хamarin будут обеспечивать только по своей доброй воле, как грится. ЕА>>Xamarin-то как раз полностью на 6-й .net переводят в ноябре.
V>Дай бог. V>Тогда это уже будет не Xamarin (т.е. не mono). V>Т.е., развели названий на ровном месте.
Это да
Xamarin.Native переименовали в .Net for Android\.Net for iOS
Xamarin.Forms теперь называется Maui
Рантайм остался в основе моновский, но BCL c 6-й версии будет единая для всех версий .Net
Здравствуйте, Ikemefula, Вы писали:
НС>>1) Для debugging и profiling api не нужно ничего пересобирать, подключаешься к работающему процессу. I>Я тебе про действия после подключения к процессу
И я тебе про тоже.
I>, а ты мне про само подключение Как ты понял мое объяснение про хуки я даже и не знаю.
Это ты меня не понял. Дотнет позволяет делать точно такие же хуки в процессе работы приложения инструментальным средствам, не правя код программы руками.
НС>>2) Нормальное логирование и метрики — обязательное требование к production коду.
I>Это общие слова
Нет, это вполне конкретное требование. Код без нормального логгирования и метрик в проде — колхоз, который не пройдет ни одно приличное ревью.
I>Как минимум, log level для продакшна и отладки разный.
Добавляешь аппендер с нужным левелом хоть в консоль, хоть в файл. На ходу.
I> А еще есть компоненты, которые, скажем, можно контролировать еще более детально, нежели log level debug.
log level trace?
НС>>3) Любое выражение можно вычислить в отладчике в процессе отладки, не правя при этом код. I>Мне надо не просто вычислить, а инструментировать приложение, кое что подпатчить, кое что симулировать итд итд итд.
И все это позволяет в дотнете profiling api.
НС>>>>Какие такие заготовки? О чем ты? I>>>Чтобы вызвать код, он где то должен быть написан до момента вызова. НС>>Совсем не обязательно. I>Давай пример, как вызвать код, который еще не написан.
Открываешь в студии окошко watch и пишешь там нужное выражение.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[42]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>>>Зачем же тогда нужен Xamarin, если тогда можно было бы пользовать WPF? ))
WPF Windows only S>>Нет поэтому и помечаются как платформозависимые. Часть можно сделать через условную компиляцию.
V>ЧТД. V>Через условную компиляцию ты будешь транзитивно порождать платформенно-зависимые бинари, прощай обещанная "чистая кроссплатформенность". ))
Угу а для 32 и 64 разрядных систем разве не делаешь раздые dll,so? V>Нам пока удаётся сохранять один бинарь подо-все платформы. V>Тут работает тот факт, что пока до вызова помеченной DllImport ф-ии дело не дошло, то реального ресолвинга не происходит.
То есть все хранится в одной dll, а на какой метод дать ссылку уже при запросе метода. Понятно
S>>Поэтому и развивают Xamarin.Forms где тот же гуй один для всех, а реализация для каждой платформы своя.
V>Тебя самого не смущает, что ровно с этой же целью был разработан Silverlight, WPF и прочие?
Silverlight и WPF не кроссплатформенные V>Или вот MAUI вышел. V>Глаза не разбегаются от родственных технологий? ))
Ну это маркетинг. Это те же Xamarin.Forms
V>В общем, практики резко другие. V>Тиков проца потребляется в разы меньше. V>Особенно когда речь идёт о локальных in-proc базах-хранилищах и непосредственного использования их низкоуровневого АПИ, там и вовсе эффективность на порядки выше.
Локальные базы это для ТСД! V>В последних дотнетах тоже есть возможность переписать драйверы общения с БД на похожий манер (через упомянутую сборку Unsafe), но вряд ли это сделают, бо легаси такое легаси...
На самом то деле переписывают много. Все зависит от пожеланий сообщества. Заметь какой курс на сближение с нативом.
Net со средой это рефлексия и динамическая компиляция в рантайме. Подстраивается под любые запросы в том числе и запросы к БД!
Высокая гибкость, чего на нативе сложно или невозможно сделать
и солнце б утром не вставало, когда бы не было меня
Re[49]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это ты меня не понял. Дотнет позволяет делать точно такие же хуки в процессе работы приложения инструментальным средствам, не правя код программы руками.
Какие такие же? Это хук который я сам же и реализовал, т.к. фремворк мой собственный. Каким образом платформа узнает, как надо готовить мои собственные хуки?
I>> А еще есть компоненты, которые, скажем, можно контролировать еще более детально, нежели log level debug.
НС>log level trace?
Смешно — ты вызвал этот трейс в 10 точках в конкретном методе и этого недостаточно, надо больше. Твои действия?
I>>Мне надо не просто вычислить, а инструментировать приложение, кое что подпатчить, кое что симулировать итд итд итд. НС>И все это позволяет в дотнете profiling api.
Непонятно, каким образом этот profiling api узнает, что именно нужно пропатчить, какой ответ симулировать и тд?
Например, мне надо временно отключить мемоизацию и после всех работ вернуть как было. Чем мне здесь поможет profiling api ?
I>>Давай пример, как вызвать код, который еще не написан.
НС>Открываешь в студии окошко watch и пишешь там нужное выражение.
Вместо репл ты предлагаешь такой же репл
Re[50]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
НС>>Это ты меня не понял. Дотнет позволяет делать точно такие же хуки в процессе работы приложения инструментальным средствам, не правя код программы руками. I>Какие такие же? Это хук который я сам же и реализовал
Так я и говорю — закат солнца вручную.
НС>>log level trace? I>Смешно — ты вызвал этот трейс в 10 точках в конкретном методе и этого недостаточно, надо больше. Твои действия?
Смешно, это отладка при помощи тонны внезапных трейсов. Голову нужно тоже иногда включать.
НС>>Открываешь в студии окошко watch и пишешь там нужное выражение. I>Вместо репл ты предлагаешь такой же репл
Такой да не совсем.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[51]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Какие такие же? Это хук который я сам же и реализовал НС>Так я и говорю — закат солнца вручную.
Ручная отладка это вообще закат солнца вручную изначально. Хук может, например, тупо переписывать кое какое состояние в конце или в начале запроса, просто что бы вынудить приложение идти по нужному пути. Я же не будут перезапускать если запомоилась мемоизация какая.
В противном случае понадобится цикл запустил-прогрел-подебажил-остановил-снова-запустил
Или даже добавляются приседания "дописал-перебилдил-задеплоил"
I>>Смешно — ты вызвал этот трейс в 10 точках в конкретном методе и этого недостаточно, надо больше. Твои действия? НС>Смешно, это отладка при помощи тонны внезапных трейсов. Голову нужно тоже иногда включать.
Отладка трейсами это само по себе смешно. Потому и надо решать другими методами.
Re[52]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ikemefula, Вы писали:
I>Ручная отладка это вообще закат солнца вручную изначально.
А это потому что плясать надо от юзкейсов, какую задачу ты решаешть. А не так что у тебя есть возможность хачить код по живому, а теперь мы начинаем думать зачем нам это может понадобится.
Debugging и Profiling API дотнетного рантайма решают те же юзкейсы, ты же зачем то пытаешься юзкейс подменить конкретным, далеко не самым лучшим способом решения из JS. Ожидаемо получаешь непонятную каку.
I>>>Смешно — ты вызвал этот трейс в 10 точках в конкретном методе и этого недостаточно, надо больше. Твои действия? НС>>Смешно, это отладка при помощи тонны внезапных трейсов. Голову нужно тоже иногда включать. I>Отладка трейсами это само по себе смешно. Потому и надо решать другими методами.
Хорошо что ты это понимаешь.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[39]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Serginio1, Вы писали:
V>>И да, сейчас получить указатель непосредственным образом можно только на статические методы. V>>Ниже в сырцах можно подсмотреть, как получить указатель на экземплярный метод и как вызывать затем. S> Нет не надо.
В твоих цитатах не объясняется — почему не надо.
Зато я могу объяснить, почему трюк имеет право на жизнь, по крайней мере в мейнстримовых платформах — из-за соглашений о передаче параметров.
См, к примеру: https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-160
Т.е., this передаётся как обычный аргумент при вызовах, поэтому, для нестатического метода добавляется первый аргумент для this без лишний приседаний.
Можно, только какая разница, кто хостит дотнет-машинку — утилита dotnet или наше приложение?
На стоимость вызова из дотнета в нейтив и обратно это не влияет.
S>А что касается упрощения вызовов можно через Source Generator нагенерить методов типа S>static T WrapClassMethod(int i,param1,param2,...)
Можно, но всё-равно вызов managed-функции через новый тип указателя быстрее всего что только может быть — ассемблерный листинг я приводил, тупо кладутся в регистры (согласно соглашению о вызовах) аргументы, в RAX читается содержимое указателя и затем вызывается call RAX. Ничего быстрее не придумаешь.
Итого:
— получение указателя на ф-ию (обычно) не приводит к выделению памяти, как оно есть в случае делегата;
— не приводит к созданию объекта-делегата, где это создание тяжеловесное и помимо выделения памяти;
— вызов происходит эффективнее, чем через делегат;
— тип указателя на ф-ию определяется сигнатурой её параметров, возвращаемого значения и соглашения о вызовах, а не искуственно-введенным типом делегата, где различные типы делегатов с одинаковой сигнатурой, увы, несовместимы.
Ну и, самое главное, это еще один инструмент проектирования.
Декомпозиция делегата-замыкания отдельно на адрес ф-ии и на ссылку на объект позволяет комбинировать в легковесной манере такие сценарии:
— вызов в цикле одного и того же экземплярного метода, поданного в кач-ве параметра, у разных экземпляров;
— вызов нескольких методов, поданных как параметр, у одного экземпляра.
Оба в комбинации друг с другом легковесно заменяют двойные виртуальные вызовы на один вызов по указателю на метод.
Например, есть способ построения конечного автомата на указателях на методы, представляющие состояние.
Т.е., когда автомат ходит по состояниям, он изменяет текущее состояние через запоминание адреса метода, отвечающего за обработку входящих сигналов, и формирующего, как один из результатов своей работы, следующее состояние. Такой способ построения автомата считается одним из самых эффективных, т.к. переход на след.состояние — это просто вызов ф-ии по адресу. Учитывая, что в .Net 6.0 открыли кишки AsyncMethodBuilder и теперь можно писать произвольные свои асинхронные автоматы, я ожидаю рано или поздно появления более эффективных реализаций, чем имеющиеся дефолтные сейчас. Т.е. техника continuations может зацвести в дотнете новыми красками.
Re[41]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>И да, сейчас получить указатель непосредственным образом можно только на статические методы. V>>>Ниже в сырцах можно подсмотреть, как получить указатель на экземплярный метод и как вызывать затем. S>> Нет не надо.
V>В твоих цитатах не объясняется — почему не надо.
Почему же не объясняется. При результате функции или или out или out параметров записываем результат в хранилище с поиском по интовому индексу.
Делаем статические методы где параметтры объекты в виде индексов и получение объектов из хранилища.
С генерацией методов врапперов. Натив вызывает эти методы.
Можно делать обертки над этими индексами, что бы в деструкторах удалять данные из хранилища и обнулять ссылки.
V>Например, есть способ построения конечного автомата на указателях на методы, представляющие состояние. V>Т.е., когда автомат ходит по состояниям, он изменяет текущее состояние через запоминание адреса метода, отвечающего за обработку входящих сигналов, и формирующего, как один из результатов своей работы, следующее состояние. Такой способ построения автомата считается одним из самых эффективных, т.к. переход на след.состояние — это просто вызов ф-ии по адресу. Учитывая, что в .Net 6.0 открыли кишки AsyncMethodBuilder и теперь можно писать произвольные свои асинхронные автоматы, я ожидаю рано или поздно появления более эффективных реализаций, чем имеющиеся дефолтные сейчас. Т.е. техника continuations может зацвести в дотнете новыми красками.
Ну сейчас сделано как итератор с MoveNext. Каждый MoveNext просто меняет состояние.
Посмотрим. Спасибо заодно почитаю про AsyncMethodBuilder
и солнце б утром не вставало, когда бы не было меня
Re[33]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Просто на Си (даже не С++) инструментарий обыгрывания различий удобнее из-за макропроцесора. V>>"Удобнее" означает меньше трудозатрат в пересчёте на каждое такое обыгрывание. S>Да вы смеётесь? Как вы обыграете отсутствие eventfd на винде при помощи "макропроцессора"?
Есть С++ класс-обертка над eventfd, и есть с таким же публичным интерфейсом и функциональностью реализация поверх pipe.
Через макроопределение выбирается нужный typedef.
В линухах тоже не во всех версиях есть eventfd и в тех линухах тоже обыгрывали через пайпы.
Ну и, в виндах слушать небольшое кол-во хендлов лучше не через select, а через WaitForMultipleObjects, связав сокеты через WSAEventSelect с HEVENT.
Тогда вместо eventfd для специального сигнального хендла можно использовать обычный HEVENT или семафор.
Это в линухах все хендлы на одно лицо, а в виндах нет.
S>У вас будет ровно то же самое — слой абстракции, который реализован сильно по-разному под винду и под линукс.
Ес-но.
Разве что абстракции бесплатны и способ их выбора прост.
S>Максимум, чего можно получить макропроцессором — это автоматического выбора нужного названия класса или семейства функций в месте их вызова.
В месте вызова делают редко, иначе управляемость кода падает.
Т.е., одна обыгрываемая кроссплатформенная функциональность должна обитать в одном месте в исходниках.
S>То есть то, что в дотнете мы будем решать или при помощи DllImport, который стреляет в .dll / .so, или при помощи отдельной менеджед библиотеки, которая собирается из разных исходников в зависимости от target, из исходников с #ifdef.
Конечно, буду решать и решаю.
И мне есть с чем сравнить — в дотнете решение одной кросслатформенной функциональности обходится несравненно дороже с т.з. разработчика.
Хотя бы потому что описание структур и ф-ий АПИ для нейтива дано готовое, а в дотнете необходимо корректно описывать интероп, в т.ч. разметку структур, в т.ч. под разную разрядность платформ.
V>>Плюс, по правилам велосипедостроения, уже очень мало кто изобретает велосипеды, т.к. эти задачи давно и многократно решены, т.е. стоимость "обыгрывания" порой примерно нулевая. S>Если задачи решены — то вопросов нет.
В дотнете аналогично под интероп Windows — есть даже специально посвящённые интеропу сайты, где даны описания структур/констант/ф-ий АПИ, т.е. отрасль накопила уже решения, т.е. их задействование составляет примерно нулевую трудоёмкость.
Под линуха и макось пока приходится делать с 0-ля.
Пример показывает зачем и почему это приходится делать.
И есть еще кое-что — в дотнете и линухах select только выглядит одинаково (по крайней мере в С++), но разметка структур-аргументов разная.
И вот эту разметку структур описываем сами.
Плюс select не очень хорошо работает в линухах, но хорошо в виндах.
В линухах для этого же лучше использовать ppoll.
S>Там кода — полстранички. Делаете её Select<T> where T: IList<Socket>, и она сохраняет совместимость со старой версией. При этом она будет уметь принимать не только массивы сокетов, но и Span-ы
Что-то странное говоришь.
Каким это образом Span-ы переводятся в IList?
Де-факто там никаких генериков не нужно, подавать спаны тоже, бо придётся копировать хендлы в специальные структуры АПИ.
Socket-ы тоже не нужны, т.к. ожидать иногда надо разные хендлы, не только сокеты.
Плюс реагировать на EINTR, плюс ставить маски сигналам...
В общем, облом всё расписывать, я не сомневаюсь, что у кого до этого дойдут руки он справится, просто обнаружит, что всё не настолько тривиально, как тебе сейчас кажется.
Смотря для чего.
Раньше мы работали на микросекундных задержках, сейчас бодаемся за наносекундные.
Жаль, одна только стоимость вызова нейтивной ф-ии сравнима с задержками, даваемыми нейтивной частью уже с приготовленными данными. ))
S>Это в JIT контрибутить трудно, и если он чего-то не умеет — то упс.
Кое-что очевидное пока не умеет.
Впрочем, я уже показывал не раз, какой глупый код генерит JIT.
И не потому что "ловушки GC", "фреймы стека" и прочее — а просто глупый.
Например, два-три раза подряд записать в стековую переменную ноль разными способами, и это значение нигде потом не используется.
Примерно раз в год проверяю — полёт нормальный.
Т.е. степень глупости та же. ))
V>>А какие мы были молодые, когда всё это только начиналось? )) S>Начиналось оно, прямо скажем, бледно. Первый дотнет был — обнять и плакать. И самое, конечно, поганое — в том, что его следы до сих пор сохраняются в дотнете. S>Вот это вот наследование IEnumerable<T> от IEnumerable, или вот ваш же пример с IList (!) в качестве аргументов... S>В общем, понятно, что передать дотнет в опенсорс надо было на десять лет раньше.
Если обернуться назад, чудовищный застой в .Net начался с началом разработки Рослина.
В итоге застой в .Net продлился примерно на 5-6 лет дольше, чем высмеиваемый (справедливо) когда-то застой в С++.
Липперт, конечно, сладкий болтун, особенно по мелочам, но вовремя подняться над ситуацией и осмотреть её с высоты птичьего полёта не смог.
Наверно, был очень занят все эти годы.
В общем, это был эпик-фейл, и он правильно сделал, что ушёл.
К сожалению, птица оказалась не того полёта.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну то есть можно окончательно констатировать — аргументы в споре ты привести не в состоянии, и окончательно поскипал весь конструктив, полностью переключившись на личности.
Да нет от тебя никакого конструктива и быть не может.
Ты тут самый толстый из сверчков, хвалящих свой шесток.
Смешно смотреть на эти потуги "личное — не личное" и прочее, уже пытаешься не мытьём, так катаньем. ))
А всё подчинено, блин, красной линией одному — оправданию себя, любимого.
Re[41]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Ручная отладка это вообще закат солнца вручную изначально.
НС>А это потому что плясать надо от юзкейсов,
Именно.
>какую задачу ты решаешть. А не так что у тебя есть возможность хачить код по живому, а теперь мы начинаем думать зачем нам это может понадобится.
Домыслы. Нужно использовать возможности платформы, а не "делать все правильно"
НС>Debugging и Profiling API дотнетного рантайма решают те же юзкейсы,
Примеров ты не показал, что характерно.
> ты же зачем то пытаешься юзкейс подменить конкретным, далеко не самым лучшим способом решения из JS. Ожидаемо получаешь непонятную каку.
Я просто привожу примеры. И кака это вероятно у тебя, т.к. у меня проблема локализуется быстро, без лишних эксцессов.
Re[56]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, vdimas, Вы писали:
S>>>>Ну статья то не новая. За это время многое изменилось V>>>TypeScript с тех пор практически не изменился. НС>>
V>Статья от 2018-го.
С разморозкой — нынче сентябрь 2021.
Ты бы роадмап глянул? 2018й это выход 3.0. На сегодня актуальна 4.4
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Рантайм остался в основе моновский, но BCL c 6-й версии будет единая для всех версий .Net
V>Интересно, как это будет выглядеть, если BCL тянет за собой так же нейтивный код...
Идеология такая, что пытаются переписать все на C#, чтобы в нейтиве был только runtime\jit\gc.
Но наверняка до идеала еще далеко, как-то подменяют нейтивные куски. Мне лень смотреть, чего там внутри. Мне главное, что для прикладного программиста интерфейс одинаковый
MoveNext()
Перемещает конечный автомат в его следующее состояние.
SetStateMachine(IAsyncStateMachine)
Настраивает конечный автомат с размещенной в куче репликой.
Состояние то это класс. Кроме адреса функции нужно еще и ссылку на класс.
Хотя в Delphi для обмана Win Api и COM генерили методы заглушки где в регистр записывался this для Api, а для COM корректировалось смещение, так как интерфейсов много и для каждого интерфейса генерировалась своя тлб со ссылкой на интерфейс просто поле со смещением от реального this
В .Net так нельзя но сделать
public struct Merhod<T,Y>
{
public T obj;
public Func<Y> func
}
Пусть обзовут не делегатом и вызывают напрямую как метод объекта
Во-первых, необходимо предоставить способ доступа Objective-C к C#, который выполняется с помощью селекторов. Селектор — это сообщение, которое отправляется объекту или классу. Objective-C Это делается с помощью функций objc_msgSend . Дополнительные сведения об использовании селекторов см. в руководстве по средствам Objective-C выбора . Также должен быть способ предоставления управляемого кода Objective-C , который более сложен из-за того факта, что Objective-C нет ничего знать об управляемом коде. Чтобы обойти это, мы используем Registrars . Эти сведения более подробно описаны в следующем разделе.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
V>Есть С++ класс-обертка над eventfd, и есть с таким же публичным интерфейсом и функциональностью реализация поверх pipe. V>Через макроопределение выбирается нужный typedef.
То есть фактически речь идёт об #ifdef/#endif. В С# будет библиотека с одноименным классом / структурой, которая при компиляции через #ifdef породит платформенно-специфичный код. V>В линухах тоже не во всех версиях есть eventfd и в тех линухах тоже обыгрывали через пайпы.
Ну, в дотнетном мире просто бы поставляли две (или) три разных версии платформенно-специфичной части размером ровно в ваш код обёртки над eventfd + эмулятора на pipe.
V>Ну и, в виндах слушать небольшое кол-во хендлов лучше не через select, а через WaitForMultipleObjects, связав сокеты через WSAEventSelect с HEVENT. V>Тогда вместо eventfd для специального сигнального хендла можно использовать обычный HEVENT или семафор. V>Это в линухах все хендлы на одно лицо, а в виндах нет.
И всё это решается через уместную абстракцию, для которой есть две-три реализации. При этом обычно кода, который построен поверх всего этого, в разы больше по объёму.
V>Ес-но. V>Разве что абстракции бесплатны и способ их выбора прост.
При правильной реализации абстракции в дотнете тоже близки к бесплатным.
V>В месте вызова делают редко, иначе управляемость кода падает. V>Т.е., одна обыгрываемая кроссплатформенная функциональность должна обитать в одном месте в исходниках.
Ну, то есть тот же подход C#, вид сбоку. Всё равно всё упирается в #ifdef.
V>И мне есть с чем сравнить — в дотнете решение одной кросслатформенной функциональности обходится несравненно дороже с т.з. разработчика. V>Хотя бы потому что описание структур и ф-ий АПИ для нейтива дано готовое, а в дотнете необходимо корректно описывать интероп, в т.ч. разметку структур, в т.ч. под разную разрядность платформ. V>Под линуха и макось пока приходится делать с 0-ля.
Неужто всё ещё нет инструмента, который умеет определения структур из .h файлов перегонять напрямую в шарп? Там же вроде как более-менее прямолинейно всё.
Так-то понятно, что авторы библиотек на C++ поставляют хидеры на С++, а pinvoke хелперы не поставляют
V>Что-то странное говоришь. V>Каким это образом Span-ы переводятся в IList?
Да, это я затупил. Они же ref struct .
V>Де-факто там никаких генериков не нужно, подавать спаны тоже, бо придётся копировать хендлы в специальные структуры АПИ. V>Socket-ы тоже не нужны, т.к. ожидать иногда надо разные хендлы, не только сокеты.
Да, вот тут есть некоторый факап дизайна дотнетного АПИ. Понятно, что хотелось спрятать все эти InternalSafeHandle с глаз подальше; но в платформе-то есть куча API, которые оперируют именно хэндлами, причём более-менее ООПшным образом. Есть несколько способов всё это исправить, но они довольно-таки затратные.
V>Плюс реагировать на EINTR, плюс ставить маски сигналам... V>В общем, облом всё расписывать, я не сомневаюсь, что у кого до этого дойдут руки он справится, просто обнаружит, что всё не настолько тривиально, как тебе сейчас кажется.
Согласен.
V>Смотря для чего. V>Раньше мы работали на микросекундных задержках, сейчас бодаемся за наносекундные. V>Жаль, одна только стоимость вызова нейтивной ф-ии сравнима с задержками, даваемыми нейтивной частью уже с приготовленными данными. ))
Руки дойдут — посмотрю бенчмарки. Не должно там быть такого оверхеда — речь про единицы десятков ассемблерных инструкций.
V>Кое-что очевидное пока не умеет. V>Впрочем, я уже показывал не раз, какой глупый код генерит JIT.
V>И не потому что "ловушки GC", "фреймы стека" и прочее — а просто глупый. V>Например, два-три раза подряд записать в стековую переменную ноль разными способами, и это значение нигде потом не используется.
Это скорее вопрос к качеству IL-кода. Джит, по большому счёту, рассчитан на то, что семантические оптимизации делает компилятор высокого уровня. Именно там должна проводиться трассировка использования (вот эти вот все варнинги про value assigned to t is never used). У джита мало ресурсов и очень мало времени на то, чтобы отслеживать глобальные потоки данных.
Я когда в прошлом году экспериментировал, убедился, что начиная с определённого количества переменных в методе джит просто забивает на частоты использования и lifetime, и тупо уносит всё в стек.
Как только я реализовал переиспользование временных переменных на уровне генерации IL — JIT сразу стал порождать значительно более качественный код. То есть и перенос в регистры, и assignment propagation, и всё такое.
V>Примерно раз в год проверяю — полёт нормальный. V>Т.е. степень глупости та же. ))
На самом деле джит тоже опенсорсный, и прогресс в нём впечатляет. Народ постоянно контрибутит туда офигенные вещи. Про шестой дотнет я пока не смотрел, а вот в пятом было добавлено до фига "смысловых" оптимизаций.
S>>В общем, понятно, что передать дотнет в опенсорс надо было на десять лет раньше.
V>Если обернуться назад, чудовищный застой в .Net начался с началом разработки Рослина.
На мой вкус — застой начался примерно сразу. Потому, что разработчики компилятора думали "а, ну это пусть коре тим в джите делает". А джит тупо никто не трогал чуть ли не десять лет. А потом его "потрогали" путём выброса на помойку и написания ryuJit.
V>В итоге застой в .Net продлился примерно на 5-6 лет дольше, чем высмеиваемый (справедливо) когда-то застой в С++.
Такого не может быть Дотнету столько лет нет, сколько будет, если прибавить 5 лет к срокам застоя в плюсах V>Липперт, конечно, сладкий болтун, особенно по мелочам, но вовремя подняться над ситуацией и осмотреть её с высоты птичьего полёта не смог. V>Наверно, был очень занят все эти годы.
Пока Липперт работал в команде, прогресс с компилятором был ого-го себе.
V>В общем, это был эпик-фейл, и он правильно сделал, что ушёл. V>К сожалению, птица оказалась не того полёта.
Ну, как мы уже выяснили, по сравнению с вами и Билл Гейтс — неудачник Лично я считаю Липперта очень, очень квалифицированным разработчиком. Как и Хейльсберга, и Торгенсена.
У нас сопоставимого уровня люди есть, пожалуй, в JetBrains. В яндексе — может быть, но уверенности нет. В быту я людей такого уровня не встречаю вообще.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Как ты понял мое объяснение про хуки я даже и не знаю.
.
Лично я считаю Липперта очень, очень квалифицированным разработчиком. Как и Хейльсберга, и Торгенсена.
