Кто-то сказал: 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;
}
Замечу, что тот, кто собеседовал меня был старше. Тоже, вроде бы, технарь. В разговоре упоминались байки с его предыдущих мест работы — пара известных банков первой категории.
Для быстрой разработки, например небольшой консольной утилиты, которая парсит JSON-ы и складывает в Oracle DB.
На Си нам потребуется:
Нужно поискать, где вы подключали похожие либы с помощью autoconf, cmake, meson, SCons(мы ведь не будем заново jansson писать). Ну и пошаманить с ними, открыть документацию, само собой.
Если пишите под винду, там есть Visual C++ и вопрос с cmake-ами снимается, но ваша функция main выглядит примерно так. Вроде бы на Си пишите, а кажется, что и не на Си:
Если работаем с Oracle, то нужен Pro*C. На известном ресурсе посвященном Ораклу "Ask Tom", в вопросе про Pro*C адепт Oracle пишет:
I use pro*c only when I cannot accomplish the task efficiently in PLSQL or SQL. In 9i, with external tables, merge, pipelined functions -- I'm very very hard pressed to find a reason to use C.
Если вы не знаете что такое Pro*C, то вам очень повезло. Там нет проверки синтаксиса, а для компиляции cc вас не выручит, компилить такие файлы следует своей утилитой.
Когда сам проводил собесы, были просто несколько вопросов, но я заранее говорил, что можно не ответить ни на один и получить оффер. Мне важно было видеть, как человек пытается решить задачу, толковый он или просто робот, который пойдёт искать решение на stackoverflow, а если не найдёт, то задача не решаема.
Толковый соискатель может многого не знать, но если он толковый, он доберёт.
К сожалению, не все это понимают. Меня на недавнем собесе на должность архитектора, как бы между прочим, спросили аж про 3 принципа ООП. Я прям растерялся и ответил после паузы.
У меня вот уже 15 лет так с ноутами. Да, есть список софта, который ставится в обязательном порядке, это продукты Jetbrains, VSCode, MSVS, git, msys64 и т.п.. Из того что ставится и сносится, это в основном игры из steam. Больше всего бесит софт, который норовит установиться в мою домашнюю папку, этим грешат Arduino Studio, PlatformIO, ESP-IDF, Python.
А так, никогда не переустанавливал на них винду, разве что апгрейдил.
Так одно дело BIOS, другое дело UEFI. Который с поддержкой мыши, красивыми экранами. Там же всё как у людей: ой тут дизайнер накосячил, а тут в интерфейсе ошибка. Ну, вы понимаете.
Имел опыт работы на десктоп FreeBSD около пары лет. Это было давно. Сейчас вынужден был год сидеть на десктоп линуксе. Всё остальное время сидел под виндой.
И могу сказать, что даже тот же самый во FreeBSD было удобнее, хотя вроде бы тот же самый десктопный софт.
Сейчас вернулся в винду и как-то странно, ничего не надо постоянно донастраивать, ничего не слетает.
Так же, плюс, юзабилити как по мне: чисто для красивых скриншотмков.
В своё время, это очень давно, перепробовал ВСЁ на FreeBSD, от KDE до fluxbox и остановился на WindowMaker. К сожалению, сейчас он уже безнадёжно устарел, а когда был прям оптимал по сочетаниям скорости и юзабилити
А у меня 2 монитора и KDE не выводит task bar на второй по-умолчанию. И как вы понимаете, это начало длиной истории, в которой случались внезапные исчезновения и прочие чудеса.
Кто-то сказал: 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
Замечу, что тот, кто собеседовал меня был старше. Тоже, вроде бы, технарь. В разговоре упоминались байки с его предыдущих мест работы — пара известных банков первой категории.
Для быстрой разработки, например небольшой консольной утилиты, которая парсит JSON-ы и складывает в Oracle DB.
На Си нам потребуется:
Нужно поискать, где вы подключали похожие либы с помощью
autoconf,cmake,meson,SCons(мы ведь не будем заново jansson писать).Ну и пошаманить с ними, открыть документацию, само собой.
Если пишите под винду, там есть Visual C++ и вопрос с cmake-ами снимается, но ваша функция
mainвыглядит примерно так. Вроде бы на Си пишите, а кажется, что и не на Си:DWORD __cdecl wmain(void) { LPCWSTR str = L"Value"; return 0; }Если работаем с Oracle, то нужен Pro*C. На известном ресурсе посвященном Ораклу "Ask Tom", в вопросе про Pro*C адепт Oracle пишет:
I use pro*c only when I cannot accomplish the task efficiently in PLSQL or SQL. In 9i, with external tables, merge, pipelined functions -- I'm very very hard pressed to find a reason to use C.Если вы не знаете что такое Pro*C, то вам очень повезло. Там нет проверки синтаксиса, а для компиляции
ccвас не выручит, компилить такие файлы следует своей утилитой.Добро пожаловать в АД
И это для одно поточного приложения, если у нас несколько потоков, то нам нужен контекст, и такой "элегантный код"
В моём опыте на Си, всегда присутствовало вот это: "ну на Си это написать — всё равно, что из пушки по воробьям, там же ерундовая утилита какая-то".
И в результате кодовая база состоит наполовину из Си, наполовину из адского нагромождения тормозных скриптов на bash, awk, python.
Это был временный ник, который я так и не нашёл, как поменять на Хабре
Согласен по поводу спорных результатов команды, впрочем, это их дело.
Но, как человек писавший на Си и изучающий Rust, могу сказать, что новый проект начну на Rust-е.
Более того, в старых проектах, уж коли доведётся модули зарефакторить, то перепишу на Rust.
Когда сам проводил собесы, были просто несколько вопросов, но я заранее говорил, что можно не ответить ни на один и получить оффер. Мне важно было видеть, как человек пытается решить задачу, толковый он или просто робот, который пойдёт искать решение на stackoverflow, а если не найдёт, то задача не решаема.
Толковый соискатель может многого не знать, но если он толковый, он доберёт.
К сожалению, не все это понимают. Меня на недавнем собесе на должность архитектора, как бы между прочим, спросили аж про 3 принципа ООП. Я прям растерялся и ответил после паузы.
У меня вот уже 15 лет так с ноутами. Да, есть список софта, который ставится в обязательном порядке, это продукты Jetbrains, VSCode, MSVS, git, msys64 и т.п.. Из того что ставится и сносится, это в основном игры из steam. Больше всего бесит софт, который норовит установиться в мою домашнюю папку, этим грешат Arduino Studio, PlatformIO, ESP-IDF, Python.
А так, никогда не переустанавливал на них винду, разве что апгрейдил.
Так одно дело BIOS, другое дело UEFI. Который с поддержкой мыши, красивыми экранами. Там же всё как у людей: ой тут дизайнер накосячил, а тут в интерфейсе ошибка. Ну, вы понимаете.
Постоянно конфигурируемая
Имел опыт работы на десктоп FreeBSD около пары лет. Это было давно. Сейчас вынужден был год сидеть на десктоп линуксе. Всё остальное время сидел под виндой.
И могу сказать, что даже тот же самый во FreeBSD было удобнее, хотя вроде бы тот же самый десктопный софт.
Сейчас вернулся в винду и как-то странно, ничего не надо постоянно донастраивать, ничего не слетает.
Так же, плюс, юзабилити как по мне: чисто для красивых скриншотмков.
В своё время, это очень давно, перепробовал ВСЁ на FreeBSD, от KDE до fluxbox и остановился на WindowMaker. К сожалению, сейчас он уже безнадёжно устарел, а когда был прям оптимал по сочетаниям скорости и юзабилити
Я так и не понял, почему в Цинамоне элементы двоились в меню пуска.
Ну и ещё, только в KDE нашёл управление hotkeys ctrl + alt + backspace, чтобы включить.
Возился с ним, но он что-то вылетал часто.
А у меня 2 монитора и KDE не выводит task bar на второй по-умолчанию. И как вы понимаете, это начало длиной истории, в которой случались внезапные исчезновения и прочие чудеса.