Да, можно обрезать. В том же Arduino я пишу на C++, фактически, но не углубляюсь.
К тому же, например, под микроконтроллеры ESP32 я вместо С/С++ использовал бы Toit потому что компиляция не занимает 10 минут, можно очень быстро проверять на конечном устройстве. А вот если на тех же контроллерах потребуется создавать красивые интерфейсы, то я опять же возьму C/C++, потому что интерфейсы удобно создавать с помощью библиотеки LGVL.
А прикладное приложение или веб сервис я бы написал на C#, просто потому что он кроссплатформенный, с хорошей производительностью и огромным потенциалом для оптимизации. Но если уж нужно, то критический к производительности код можно вынести в отдельную библиотеку, написанную уже на C/C++.
Т.е., я сторонник того, что хороша ложка к обеду и стараюсь выбирать удобный инструмент по задаче.
Но текущее состояние дел во фронте — удручает и удручала всегда.
Были многочисленные попытки сделать что-то стандартное. Сейчас у нас появился WASM. При таких раскладах, я не вижу смысла цепляться за HTML/CSS/JS, а следует посмотреть по сторонам и поискать что-то цельное.
OCI или Oracle® Call Interface это старый интерфейс для Java/C#, когда работаешь в этих языках, вам нет необходимости ставить Oracle Instant Client и т.п. Также, нет необходимости ставить отдельный для Linux, отдельный для винды.
При подключении нативной для платформы библиотеки, конечный Docker образ приложения увеличивается на 4 Мб, вместо установки 121 Мб Basic Package.
Сказать по правде, я не могу припомнить никакую подобную игру после, да ещё с таким разнообразием задач. Тут тебе городок спасти, его газом отравить пытаются, там сброс контейнеров и для обеспечения ударной группы и тд. Был красивый-крысивый Comanche Max Overkill, Я ещё в его третью версию играл, там было вообще красивее, но миссии были пресными.
И вот эти маленькие прикольняшки, когда со штабной карты и в кабину. Или из кабины обратно на карту и отчёт. Ну и мини игра, когда быстро туда-сюда щёлкаешь, меняя уровень сложности с этим пилотом. По-моему на предпоследнем уровне орёт, а на последнем орёт и смотрит на нас.
Может это уже возраст, но хочется пробурчать, что такие сейчас не делают.
Точнее, делают, может быть другого жанра, но так же с душой. И не крупные корпорации, а именно инди-разработчики. Приблизительно как в ту пору, несколько человек могли создать игру, тоже самое и сейчас. Скорее всего, это идеальный рецепт для шедевра.
PS. А ещё игра привила глубокое уважение к «Шилке».
Если вам будет охота выучить C# и познакомиться с языком разметки XAML, то к вашим услугам Blazor Hybrid. Там есть функционал работы а-ля HTML/JS/CSS, а есть прямой XAML который реализует Model-View-ViewModel концепцию.
Я работал с XAML и по мне, это небо и земля для создания интерфейсов. При этом его функционала хватает, чтобы создать любой интерфейс.
В самом Blazor очень много чего решается внутренними компонентами, вам даже нет нужды знать, что такое бабель.
Кто-то сказал: C это высокоуровневый ассемблер, C++ это высокоуровневый язык :)
Если приложение небольшое, то C++ избыточен, вы тащите за собой рантайм, без которого ничего работать не будет.
Если у вас реально требуется высоко оптимизированное приложение, то C++ вам тут плохой товарищ. Некоторые вещи будет намного проще написать на C. Именно поэтому, если речь идёт о драйвере, то обязательно C.
Сам C++ я побаиваюсь, знаю его в разрезе MFC. И это ничего не значит, если приложение будет написано на boost, stl. Я вынужден буду изучить и их. Я ещё тут читал ахи-вздохи C++ программистов по поводу того, что иногда трудно угадать, как соптимизирует код компилятор, из этого выходило, что порой это рулетка. Короче, лично для меня, и без этого проблем хватает, есть множество других языков.
Можете дать ссылку, где написано, что драйвера для Java/C# являются просто оберткой над OCI? Потому что я на сайте Оракл только находил инфу о том, что это native драйвера
Если бы меня спросили, на чём следует писать уровень взаимодействия с базой данной, то я бы отдал предпочтение C#, где без всяких лишних прокладок в виде OCI, с библиотекой размером 4 Мб обходятся.
Исходя из того, что мы уже определились, что пишем наше большое приложение на Си или Rust, в таких условиях дописывание маленькой сопутствующей утилиты всегда рискует перерасти в ад из кучи скриптов на bash, awk, python, etc.
Пожалуйста не объединяйте строки с помощью string + string, это сжирает память и неэффективно. Внутри string — обычный массив char, когда вы соединяете строки, фактически делаете это:
public char[] PseudoStringConcat(char[] firstString, char[] secondString)
{
char[] result = new char[firstString.Length + secondString.Length];
int i = 0;
foreach (var c in firstString)
{
result[i] = c;
i++;
}
foreach (var c in secondString)
{
result[i] = c;
i++;
}
return result;
}
Замечу, что тот, кто собеседовал меня был старше. Тоже, вроде бы, технарь. В разговоре упоминались байки с его предыдущих мест работы — пара известных банков первой категории.
На сайте Oracle написано, что они native. И magaged не применяется к коду на Java.
M5Stack Cardputer, за 30$. Из минусов, не удобная клавиатура и маленький экран.
Да, можно обрезать. В том же Arduino я пишу на C++, фактически, но не углубляюсь.
К тому же, например, под микроконтроллеры ESP32 я вместо С/С++ использовал бы Toit потому что компиляция не занимает 10 минут, можно очень быстро проверять на конечном устройстве. А вот если на тех же контроллерах потребуется создавать красивые интерфейсы, то я опять же возьму C/C++, потому что интерфейсы удобно создавать с помощью библиотеки LGVL.
А прикладное приложение или веб сервис я бы написал на C#, просто потому что он кроссплатформенный, с хорошей производительностью и огромным потенциалом для оптимизации. Но если уж нужно, то критический к производительности код можно вынести в отдельную библиотеку, написанную уже на C/C++.
Т.е., я сторонник того, что хороша ложка к обеду и стараюсь выбирать удобный инструмент по задаче.
Но текущее состояние дел во фронте — удручает и удручала всегда.
Были многочисленные попытки сделать что-то стандартное. Сейчас у нас появился WASM. При таких раскладах, я не вижу смысла цепляться за HTML/CSS/JS, а следует посмотреть по сторонам и поискать что-то цельное.
Тем, что не написан на JVM/.NET.
OCI или Oracle® Call Interface это старый интерфейс для Java/C#, когда работаешь в этих языках, вам нет необходимости ставить Oracle Instant Client и т.п. Также, нет необходимости ставить отдельный для Linux, отдельный для винды.
При подключении нативной для платформы библиотеки, конечный Docker образ приложения увеличивается на 4 Мб, вместо установки 121 Мб Basic Package.
Тогда сочувствую, на таких тасках выгораешь очень быстро.
А модель повреждений, не это аркадное пиу-пиу, а вот пытаться дотянуть до своих, масло вытекло и двигатель в любой момент заклинит.
В конце концов, после этого ты не задаёшь глупых вопросов, из серии: а зачем нам сзади маленький винт :)
Сказать по правде, я не могу припомнить никакую подобную игру после, да ещё с таким разнообразием задач. Тут тебе городок спасти, его газом отравить пытаются, там сброс контейнеров и для обеспечения ударной группы и тд. Был красивый-крысивый Comanche Max Overkill, Я ещё в его третью версию играл, там было вообще красивее, но миссии были пресными.
И вот эти маленькие прикольняшки, когда со штабной карты и в кабину. Или из кабины обратно на карту и отчёт. Ну и мини игра, когда быстро туда-сюда щёлкаешь, меняя уровень сложности с этим пилотом. По-моему на предпоследнем уровне орёт, а на последнем орёт и смотрит на нас.
Может это уже возраст, но хочется пробурчать, что такие сейчас не делают.
Точнее, делают, может быть другого жанра, но так же с душой. И не крупные корпорации, а именно инди-разработчики. Приблизительно как в ту пору, несколько человек могли создать игру, тоже самое и сейчас. Скорее всего, это идеальный рецепт для шедевра.
PS. А ещё игра привила глубокое уважение к «Шилке».
Мне человек смс таким писал. И экономия была
Бог ты мой! LHX! Любовь! Те времена, когда Electronic Arts не было бранным словом.
Вот-вот, в качестве предложения:
Если вам будет охота выучить C# и познакомиться с языком разметки XAML, то к вашим услугам Blazor Hybrid. Там есть функционал работы а-ля HTML/JS/CSS, а есть прямой XAML который реализует Model-View-ViewModel концепцию.
Я работал с XAML и по мне, это небо и земля для создания интерфейсов. При этом его функционала хватает, чтобы создать любой интерфейс.
В самом Blazor очень много чего решается внутренними компонентами, вам даже нет нужды знать, что такое бабель.
Кто-то сказал: C это высокоуровневый ассемблер, C++ это высокоуровневый язык :)
Если приложение небольшое, то C++ избыточен, вы тащите за собой рантайм, без которого ничего работать не будет.
Если у вас реально требуется высоко оптимизированное приложение, то C++ вам тут плохой товарищ. Некоторые вещи будет намного проще написать на C. Именно поэтому, если речь идёт о драйвере, то обязательно C.
Сам C++ я побаиваюсь, знаю его в разрезе MFC. И это ничего не значит, если приложение будет написано на boost, stl. Я вынужден буду изучить и их.
Я ещё тут читал ахи-вздохи C++ программистов по поводу того, что иногда трудно угадать, как соптимизирует код компилятор, из этого выходило, что порой это рулетка. Короче, лично для меня, и без этого проблем хватает, есть множество других языков.
Можете дать ссылку, где написано, что драйвера для Java/C# являются просто оберткой над OCI?
Потому что я на сайте Оракл только находил инфу о том, что это native драйвера
Понимаю и сочувствую, правда, в последний раз работал с фронтом ещё во времена jQuery, но уже тогда это было дикостью.
Кстати, если так всё сложно в вашем стеке, то может взгляните на другие платформв по созданию WASM, но уже без JS и HTML.
В другой ветке я ответил https://habr.com/ru/companies/ruvds/articles/842970/#comment_27299666
Если бы меня спросили, на чём следует писать уровень взаимодействия с базой данной, то я бы отдал предпочтение C#, где без всяких лишних прокладок в виде OCI, с библиотекой размером 4 Мб обходятся.
Исходя из того, что мы уже определились, что пишем наше большое приложение на Си или Rust, в таких условиях дописывание маленькой сопутствующей утилиты всегда рискует перерасти в ад из кучи скриптов на bash, awk, python, etc.
Если вы скомпилировали в RELEASE режиме и дали коду поработать какое-то время, то дельта кода на Си и СШарп будет минимальна.
По поводу кода я добавлю:
System.Windows.Forms.Timerможет иметь погрешность 55 мс в силу своей однопоточной природы. В вашем примере нет нескольких потоков, но в целом, для точного таймера с потоками используйтеSystem.Timers.Timerhttps://learn.microsoft.com/en-us/dotnet/api/system.timers.timer?view=net-8.0&viewFallbackFrom=windowsdesktop-8.0
Пожалуйста не объединяйте строки с помощью
string+string, это сжирает память и неэффективно.Внутри
string— обычный массивchar, когда вы соединяете строки, фактически делаете это:public char[] PseudoStringConcat(char[] firstString, char[] secondString) { char[] result = new char[firstString.Length + secondString.Length]; int i = 0; foreach (var c in firstString) { result[i] = c; i++; } foreach (var c in secondString) { result[i] = c; i++; } return result; }Для объединения строк служит
StringBuilderhttps://learn.microsoft.com/en-us/dotnet/fundamentals/runtime-libraries/system-text-stringbuilder
Замечу, что тот, кто собеседовал меня был старше. Тоже, вроде бы, технарь. В разговоре упоминались байки с его предыдущих мест работы — пара известных банков первой категории.