Вы считаете, что Microsoft обошлись только .NET-кодом для работы с разными ОС? Если ошибаюсь, прошу прощения. Если я верно уловил мысль, то вы не правы.
Чтобы вызывать API конкретной операционной системы из .NET, единственный вариант — DllImport/LibraryImport. Да, можно сделать разбивку кода на файлы под разные ОС, но тогда там будут вызовы нативных функций через эти атрибуты, без этого никак в любом случае. И эти вызовы там есть, поищите Interop.Sys в ConsolePal.Unix.cs. Большущий partial-класс Interop содержит тысячи P/Invoke деклараций для системных функций.
Более того, в статье я привёл пример с получением количества входных MIDI-устройств в Linux. Можно накидать кучу P/Invoke деклараций в C# и реализовать в .NET нетривиальную логику выполнения сценария. Но зачем? Почему бы этот сценарий не убрать в нативный фасад, избавив код на C# от беспорядка?
В любом более или менее сложном проекте желание создать нативный бэкенд возникнет, если разработчика заботит какая-никакая чистота кода. Вот, например, в указанном вами репозитории декларация функции Read из System.Native (в этот бинарник компилируется нативный бэкенд .NET), которая как раз используется в Unix-реализации консоли. Код для System.Native разбит по C-файлам в папке src/native.
Ну т.е. решение там комбинированное, но нативнй бэкенд всё равно используется. Я бы очень удивился, если бы они его не сделали. Сама идея с разбивкой какой-то условной логики в .NET любопытная.
Интересный вопрос. Признаюсь, не знал, что в C/C++ размер int зависит от компилятора. Из того, что я выяснил, бегло погуглив:
В контексте статьи (десктопные 64-битные системы) с вероятностью 99.9% размер int будет 4 байта, так что и со стороны C++ и со стороны C# размеры совпадут. По крайней мере msbuild и clang собирают бинарники с такими параметрами.
2-байтные целые числа могут быть при сборке под старые 16-битные ОС или в случае embedding систем. Для полноты стоило бы рассказать про такие случаи, но, честно, я вообще не эксперт в этом.
В C# можно передать int как 2-байтное число через такую конструкцию: public static extern void Foo([MarshalAs(UnmanagedType.I2)] int n).
Вообще, при создании декларации для P/Invoke так или иначе мы должны знать ABI нативного файла, иначе мы попросту не сможем вызвать функцию без неожиданных эффектов. Т.е. со стороны C# мы никак не согласуем размеры типов магическим образом, только через явные указания маршалеру.
Я рекомендую Silent Hill 2 Remake. Смысла сейчас играть в оригинал 2001-го года никакого. Bloober Team сделали отличный ремейк. С автором статьи не соглашусь, с Resident Evil ничего общего. Мне RE вообще нестрашным показался, а вот SH всю игру держит в напряжении.
Более того, SH уникален тем, как пугает. В игре нет скримеров, все новые монстры вводятся в игру без этих дебильных криков и оров, присущих ужастикам и игровым и киношным. Пугает там сама атмосфера, страх того, что притаилось в темноте или за углом. А сюжет однозначно один из самых необычных.
Я с вами соглашусь, но увы, других метрик не нашлось :-( Вообще, было бы очень круто со стороны MS устроить большой опрос по использованию и удовлетворённостью фичами языка. Им бы тоже было полезно: были бы видны потенциальные векторы развития языка.
По такой логике и Go вполне кратко, ёмко и логотипно. Но вообще на ваш вопрос "зачем" ответы будут субъективные и их будет много. Ну вот мне кажется, что даже и такие вещи могут иметь значение – узнаваемый символ. Но могу ошибаться.
А я и не скрываю в статье, что вкусовщина. И шарп я люблю, и переходить на другой язык не желаю. Но всё равно внутри какое-то чувство, что что-то не так... Но повторюсь, я сам нововведения использую. А в разделе про ref подчёркиваю, что это примеры полезных (на мой взгляд) фич.
Полностью с вами согласен. В целом, C# так или иначе присутствует в пятёрке ну или как минимум десятке самых популярных языков. Но да, до уровня того же Python ему далеко. Вы подняли любопытную тему.
Мне кажется, важно ещё то, что сам .NET был очень долго привязан к Windows (хорошо хоть в MS одумались). Да, был Mono, был Xamarin. Но сторонние поделки не так сильно поднимают популярность, как действия со стороны самих разработчиков языка.
Ещё я только что осознал, что у C# нет вменяемого логотипа, там просто многоугольник с надписью C#. У Python две змейки в виде плюса, у Java чашка кофе, у Go милый зверёк, у Rust велосипедная звёздочка на пять болтов. Мелочь, конечно, но тоже может влиять.
И да, тоже ежегодно решаю задачки Advent of Code, использую его как полигон для опробования новых фич языка. Правда, в leaderboard не попадал никогда. Да и вообще, все задачи (обе части) решил только в 2020-м. Я тоже сделал себе набор полезных методов, а C# использовал сразу. В целом, олимпиадные задачки (а AoC всё же больше к ним тяготеет) мне даются непросто. В этом году, думаю, в лидерах будут сплошь LLM-ки.
Не хватает сравнения с VS Code, например (хотя намекают на него, упоминая Electron). Или даже Visual Studio, если мы говорим про C# или C++. Или семейство IDE от JetBrains.
Dropbox спустя чуть больше полугода после публикации статьи (на английском, разумеется) запустил бета-тестирование фичи Ignore Files. Не знаю, в статье дело или нет, но буду верить, что и она повлияла :-)
Ага, уже разобрался. К своему стыду я даже не знал про амортизационную сложность. И таки-да, очень разумная штука. Не зря статью написал, узнал много нового :-)
Как было сказано в статье, API позволяет менять воспроизводимые объекты на лету. Это значит, что пользователь может захотеть изменить, например, силу нажатия (velocity) какой-то ноты. А чтобы отразить это в плейбеке, нужно найти эту ноту во внутренней коллекции (в дереве) и поменять параметры (я делаю сейчас изменение просто: удаляю ноту и добавляю её с новыми данными).
Стоит признать, что вы правы. Спасибо за конструктивное замечание. Я выполнил бенчмарки интересных мне случаев:
вставка в конец коллекции;
удаление с конца, с начала и рандомно.
Да, List выигрывает у LinkedList, если операции выполнить в цикле. Нужно будет подумать, стоит ли переходить на List. Потому что массовые операции происходят только при иницализации дерева (и то, в большинстве случаев изначально дерево пустое будет), а потом уже точечные будут. Замерю на досуге.
знали ли Вы, что современные реализации сортировок используют сортировку вставками, а не квиксорт в некоторых случаях
Нет, я этого не знал. Сейчас прочитал и таки-да, разумно.
Treap-дерево попадалось на глаза, когда изучал научные работы по сбалансированным BST. Но мне запомнилось, что оно в бенчмарках заметно проигрывало AVL и красно-чёрному. Вероятно, коэффициенты при логарифме у treap-дерева больше.
И всё-таки логарифм там обеспечен с высокой вероятностью, но не гарантирован, как у AVL или красно-чёрного. У treap может и O(N) быть в маловероятном случае.
Взятие элемента по индексу за O(1) вы в дереве не сделаете. Только если рядом хранить какой-то массив и держать его в отсортированном состоянии. Но тогда и дерево не нужно.
Говоря о проблемах сравнения, я, разумеется имел в виду логику сравнения, алгоритм. Не реализацию на языке программирования. Закодить-то несложно (если есть алгоритм). Наиболее простым способом будет реализовать IComparable<> на классе-ключе, чтобы не менять код самого дерева.
Но именно логика сравнения является сложной частью головоломки. Во-первых, класс-ключ будет содержать большое число условий и проверок. Во-вторых, проблемы, описанные выше. В третьих, придётся менять и код дерева тоже. Потому что теперь мы не сможем легко и просто взять значения, у которых время равно T. Ибо ключ не равен времени, и нужно заглядывать внутрь ключа.
Как я и писал выше, в теории оно сработает, можно и так сделать. Другое дело, что композитный ключ порождает большое количество вопросов и проблем. А зачем, если можно сделать проще? Разве что в качестве интеллектуального упражнения.
Ну и статья про красно-чёрное дерево, не про SortedSet<>. Почему мне оно не подходит, я в другом комментарии отвечал.
Вы считаете, что Microsoft обошлись только .NET-кодом для работы с разными ОС? Если ошибаюсь, прошу прощения. Если я верно уловил мысль, то вы не правы.
Чтобы вызывать API конкретной операционной системы из .NET, единственный вариант —
DllImport/LibraryImport. Да, можно сделать разбивку кода на файлы под разные ОС, но тогда там будут вызовы нативных функций через эти атрибуты, без этого никак в любом случае. И эти вызовы там есть, поищитеInterop.Sysв ConsolePal.Unix.cs. Большущийpartial-классInteropсодержит тысячи P/Invoke деклараций для системных функций.Более того, в статье я привёл пример с получением количества входных MIDI-устройств в Linux. Можно накидать кучу P/Invoke деклараций в C# и реализовать в .NET нетривиальную логику выполнения сценария. Но зачем? Почему бы этот сценарий не убрать в нативный фасад, избавив код на C# от беспорядка?
В любом более или менее сложном проекте желание создать нативный бэкенд возникнет, если разработчика заботит какая-никакая чистота кода. Вот, например, в указанном вами репозитории декларация функции
Readиз System.Native (в этот бинарник компилируется нативный бэкенд .NET), которая как раз используется в Unix-реализации консоли. Код для System.Native разбит по C-файлам в папке src/native.Ну т.е. решение там комбинированное, но нативнй бэкенд всё равно используется. Я бы очень удивился, если бы они его не сделали. Сама идея с разбивкой какой-то условной логики в .NET любопытная.
https://github.com/microsoft/CsWin32 — интересный проект, спасибо!
Спасибо!
Интересный вопрос. Признаюсь, не знал, что в C/C++ размер
intзависит от компилятора. Из того, что я выяснил, бегло погуглив:В контексте статьи (десктопные 64-битные системы) с вероятностью 99.9% размер
intбудет 4 байта, так что и со стороны C++ и со стороны C# размеры совпадут. По крайней мереmsbuildиclangсобирают бинарники с такими параметрами.2-байтные целые числа могут быть при сборке под старые 16-битные ОС или в случае embedding систем. Для полноты стоило бы рассказать про такие случаи, но, честно, я вообще не эксперт в этом.
В C# можно передать
intкак 2-байтное число через такую конструкцию: publicstatic extern void Foo([MarshalAs(UnmanagedType.I2)] int n).Вообще, при создании декларации для P/Invoke так или иначе мы должны знать ABI нативного файла, иначе мы попросту не сможем вызвать функцию без неожиданных эффектов. Т.е. со стороны C# мы никак не согласуем размеры типов магическим образом, только через явные указания маршалеру.
Я рекомендую Silent Hill 2 Remake. Смысла сейчас играть в оригинал 2001-го года никакого. Bloober Team сделали отличный ремейк. С автором статьи не соглашусь, с Resident Evil ничего общего. Мне RE вообще нестрашным показался, а вот SH всю игру держит в напряжении.
Более того, SH уникален тем, как пугает. В игре нет скримеров, все новые монстры вводятся в игру без этих дебильных криков и оров, присущих ужастикам и игровым и киношным. Пугает там сама атмосфера, страх того, что притаилось в темноте или за углом. А сюжет однозначно один из самых необычных.
Программно на C# через стандартный System.Drawing.
Я с вами соглашусь, но увы, других метрик не нашлось :-( Вообще, было бы очень круто со стороны MS устроить большой опрос по использованию и удовлетворённостью фичами языка. Им бы тоже было полезно: были бы видны потенциальные векторы развития языка.
По такой логике и Go вполне кратко, ёмко и логотипно. Но вообще на ваш вопрос "зачем" ответы будут субъективные и их будет много. Ну вот мне кажется, что даже и такие вещи могут иметь значение – узнаваемый символ. Но могу ошибаться.
Запрос на такую фичу, оказывается, существует с 2015-го года.
А я и не скрываю в статье, что вкусовщина. И шарп я люблю, и переходить на другой язык не желаю. Но всё равно внутри какое-то чувство, что что-то не так... Но повторюсь, я сам нововведения использую. А в разделе про ref подчёркиваю, что это примеры полезных (на мой взгляд) фич.
Кстати, да :-)
Полностью с вами согласен. В целом, C# так или иначе присутствует в пятёрке ну или как минимум десятке самых популярных языков. Но да, до уровня того же Python ему далеко. Вы подняли любопытную тему.
Мне кажется, важно ещё то, что сам .NET был очень долго привязан к Windows (хорошо хоть в MS одумались). Да, был Mono, был Xamarin. Но сторонние поделки не так сильно поднимают популярность, как действия со стороны самих разработчиков языка.
Ещё я только что осознал, что у C# нет вменяемого логотипа, там просто многоугольник с надписью C#. У Python две змейки в виде плюса, у Java чашка кофе, у Go милый зверёк, у Rust велосипедная звёздочка на пять болтов. Мелочь, конечно, но тоже может влиять.
И да, тоже ежегодно решаю задачки Advent of Code, использую его как полигон для опробования новых фич языка. Правда, в leaderboard не попадал никогда. Да и вообще, все задачи (обе части) решил только в 2020-м. Я тоже сделал себе набор полезных методов, а C# использовал сразу. В целом, олимпиадные задачки (а AoC всё же больше к ним тяготеет) мне даются непросто. В этом году, думаю, в лидерах будут сплошь LLM-ки.
Не хватает сравнения с VS Code, например (хотя намекают на него, упоминая Electron). Или даже Visual Studio, если мы говорим про C# или C++. Или семейство IDE от JetBrains.
Dropbox спустя чуть больше полугода после публикации статьи (на английском, разумеется) запустил бета-тестирование фичи Ignore Files. Не знаю, в статье дело или нет, но буду верить, что и она повлияла :-)
На первый взгляд кажется, что реализация у меня станет сложнее наоборот. Но подход и его плюсы я понял, нужно подумать.
Ага, уже разобрался. К своему стыду я даже не знал про амортизационную сложность. И таки-да, очень разумная штука. Не зря статью написал, узнал много нового :-)
Как было сказано в статье, API позволяет менять воспроизводимые объекты на лету. Это значит, что пользователь может захотеть изменить, например, силу нажатия (velocity) какой-то ноты. А чтобы отразить это в плейбеке, нужно найти эту ноту во внутренней коллекции (в дереве) и поменять параметры (я делаю сейчас изменение просто: удаляю ноту и добавляю её с новыми данными).
Спасибо за полезную информацию про splay-дерево.
Стоит признать, что вы правы. Спасибо за конструктивное замечание. Я выполнил бенчмарки интересных мне случаев:
вставка в конец коллекции;
удаление с конца, с начала и рандомно.
Да,
Listвыигрывает уLinkedList, если операции выполнить в цикле. Нужно будет подумать, стоит ли переходить наList. Потому что массовые операции происходят только при иницализации дерева (и то, в большинстве случаев изначально дерево пустое будет), а потом уже точечные будут. Замерю на досуге.Нет, я этого не знал. Сейчас прочитал и таки-да, разумно.
Treap-дерево попадалось на глаза, когда изучал научные работы по сбалансированным BST. Но мне запомнилось, что оно в бенчмарках заметно проигрывало AVL и красно-чёрному. Вероятно, коэффициенты при логарифме у treap-дерева больше.
И всё-таки логарифм там обеспечен с высокой вероятностью, но не гарантирован, как у AVL или красно-чёрного. У treap может и
O(N)быть в маловероятном случае.Вот я выше тоже про это написал:
Не знал про skip list, спасибо!
Говоря о проблемах сравнения, я, разумеется имел в виду логику сравнения, алгоритм. Не реализацию на языке программирования. Закодить-то несложно (если есть алгоритм). Наиболее простым способом будет реализовать
IComparable<>на классе-ключе, чтобы не менять код самого дерева.Но именно логика сравнения является сложной частью головоломки. Во-первых, класс-ключ будет содержать большое число условий и проверок. Во-вторых, проблемы, описанные выше. В третьих, придётся менять и код дерева тоже. Потому что теперь мы не сможем легко и просто взять значения, у которых время равно
T. Ибо ключ не равен времени, и нужно заглядывать внутрь ключа.Как я и писал выше, в теории оно сработает, можно и так сделать. Другое дело, что композитный ключ порождает большое количество вопросов и проблем. А зачем, если можно сделать проще? Разве что в качестве интеллектуального упражнения.
Ну и статья про красно-чёрное дерево, не про
SortedSet<>. Почему мне оно не подходит, я в другом комментарии отвечал.