Pull to refresh

Comments 39

"...ассемблера, который был не очень удобен для восприятия."
Так вот в чём проблема, а я-то думал...

эээ, ммм... статья в википедии полнее и информативнее. Это рекламная обертка для телеграм канала?

Ссылки на телегу вроде нет. Может человек упражняется в кратких пересказах статей большого объема? Так для этого наверняка есть другие, специализированные ресурсы.

))) была, убрали
В следующий раз скрин сделаю на такие случаи

А смысл? Все равно эта писанина не тянет на заявленный заголовок.

когда я в 90-е писал на Ассемблере, то читать код было весьма легко, для меня, не знавшего ни Си ни Паскаля. Там ведь читаешь сразу блоками команд которые реализуют какие-то вещи. Тут вопрос привычки. На Си банально выше скорость разработки и отладки (мне всегда казалось что именно для этого и оборачивают ассемблер в условные макро-конструкции). Сейчас я люблю писать на C#, мне он комфортнее в работе чем Си/С++, а с питоном я как-то не смог подружиться, слишком много условностей и сам вид языка, хотя когда читал о нем лет 10 назад было весьма интересно, но на C# я пишу раз в 10 быстрее.

когда я в 90-е писал на Ассемблере, то читать код было весьма легко

Я вот так не могу сказать. Первой машиной, на которую я писал что-то применимое, была Наири-2.. Может кто помнит? Еще была така Минск-32. Позже уже PDP-подобные (все - ассемблер). Когда много позже перешел на C - радовался:

На Си банально выше скорость разработки и отладки

На Си шарп не перешел (я в основном эмбедингоом сейчас) а вот Пайтон для прототипирования и отладки протоколов и т.п. - зашел и даже очень.

На Си шарп не перешел (я в основном эмбедингоом сейчас) а вот Пайтон для прототипирования и отладки протоколов и т.п. - зашел и даже очень.


Подскажите пожалуйста, что в разработке для микроконтроллеров можно полезного сделать на python кроме вычисления формул и отрисовки графиков?

Мне в разработку firmware прислали помощника, а он говорит, что хочет только на python код писать.

Какую же задачу мне ему делегировать?

Когда говорят об языке Си, о его истории, то мне сразу вспоминается книга Эндрю Таненбаума «Operating Systems Design and Implementation» ее первое издание и то, как в ней представлен собственно язык Си. Это просто классика - "Введение в Си. Послание из прошлого столетия".

Язык программирования С был разработан ... с целью создания более эффективного и
быстрого языка для разработки ОС.

Долго не понимал смысла этой фразы и удивлялся от неё. Почему язык создавался для разработки ОС? Почему не просто язык общего назначения? А потом попробовал написать собственную микроскопическую минимальную ОС, и как понял! Там суть в том, что язык и ОС разрабатываются вместе одновременно. Чуть-чуть язык, потом чуть-чуть ОС и так многократно, раскручивая друг друга. А по другому и никак, потому что язык очень активно использует системные вызоы ОСи, а их ещё нет, и чтобы их написать нужен язык...

Не ради спора, только поделиться тем о чем читал сам - писали ОС как правило на другой машине на языке высокого уровня, либо, изначально, на ассемблере. Когда ОС обрастала ядром и хоть каким-то самостоятельным функционалом - могли уже писать в ней. Потом уже блоки, написанные криво-косо - причёсывали и переписывали.

Язык си не опирается на системные вызовы, это в стандартной библиотеке для конкретной ОС и архитектуры они используются. При написании ОС или любой другой программы, работающей на голом железе, вы должны свою библиотеку написать со всем необходимым, и для этого не нужны системные вызовы. И это не какая-то особенность языка си, точно такая же ситуация будет при написании программы, работающей на голом железе, на любом другом языке, например, на расте.

Я не опытный, и не сишник, и вообще не программист. Но поставил бы 10 жирных минусов: половину из них - за содержание, а вторую половину - за неграмотность.

Си не является самым популярным для изучения, всё больше уступая свои позиции более простым языкам, таким как Python. И действительно, С — весьма сложен и не безопасен.

Чушь!

Язык Си по сравнению с другими языками простой как ножик.
Одни только функции и переменные. Самый древний язык из тех что всё еще используются ~50 лет.

В Си не будет никаких программных делегатов как в C#, сборщиков мусора, исключений и виртуальных машин.

В программировании микроконтроллеров вы никогда не услышите таких страшных слов как "FrameWork". В программировании на Си только один паттерн: конечный автомат.

Язык Си по сравнению с другими языками простой как ножик. Одни только функции и переменные.

Очевидно имелась в виду сложность написания программ. На си сложнее писать многие вещи чем, скажем, на том же python, просто потому что приходится думать об управлении памятью, работать с указателями, самому освобождать все выделенные ресурсы. В си так же очень неудобно работать со строками в отличие от того же python. Также приходится думать о том, приведёт ли твой код к UB или нет. Я, скорее всего, о чём-то забыл, но, думаю, мысль донёс.

работать с указателями

Указатели в Си намного проще чем std optionals из C++, которую используют вместо указателей.

Причём тут std::optional? std::optional позволяет представить либо наличие значения, либо отсутствие, что в этом сложного? А указатель - это буквально адрес в памяти, он может указывать на структуру данных, значение, строку. То есть это как минимум не равнозначные вещи. Да, если, указатель равен NULL, можно считать, что значения нет, но это не делает std::optional его полным аналогом.

Как то странно измерять качество языка в количестве паттернов.

Да и если так уж хочется паттернов, то язык си настолько универсальный, что не могу себе представить паттерн, который нельзя было бы реализовать на си.

Язык Си по сравнению с другими языками простой как ножик.

100% проще многих...

Одни только функции и переменные.

Забыли про структуры и перечисления...

В Си не будет

исключения вообще-то есть.

В программировании микроконтроллеров вы никогда не услышите таких страшных слов как "FrameWork"

А давно писали на MCU? Ибо есть. И довольно много.

В программировании на Си только один паттерн: конечный автомат.

Правда? Еще есть RTOS и псевдо всякие, лаунчеры. Но конечный автомат рулит.

Язык С потихоньку сдает свои позиции.

Кроме микроконтроллеров Си уже практически никому даром не нужен.
Навыки программирования на С очень слабо конвертируются!

В свое время, видимо, на С написали компилятор для С++ и нужда в С для desktop как таковая отпала.

A сам язык Си остался для сборки артефактов для микроконтроллеров с экстремально малыми ресурсами (для automotive ECU, SIM карт, IoT).

Хотя и сейчас большинство компаний в Евросоюзе уже давно как и микроконтроллерные сборки собирают на С++ 17 и выше. Плюс сейчас набирает обороты Rust для микроконтроллеров.

Вероятно, что язык программирования С для МК вскоре и вовсе войдет в историю.

Есть конечно DeskTop проекты написанные на С: Git, JVM, MySQL, Nginx, PostgreSQL, TaranTool, WallArm, однако вероятность, что в этих проектах можно работать из РФ да еще и с опытом из электроники бесконечно мала.

Не тратьте свое время на изучение Си!

С тем, что вакансий на си практически нет, спорить не буду, это так. Могу поспорить с этим утверждением

Не тратьте свое время на изучение Си!

Это примерно как говорить людям не изучать язык ассемблера. Да, вакансий нет, но ради понимания того, как всё работает на низком уровне написать несколько программ на си всё же стоит, это меняет мышление.

Учить си это тоже что учить латынь. Полезно только для общего развития.

Есть конечно DeskTop проекты написанные на С: Git, JVM, MySQL, Nginx, PostgreSQL, TaranTool, WallArm, однако вероятность, что в этих проектах можно работать из РФ да еще и с опытом из электроники бесконечно мала.

git - опенсорсный

openjdk - опенсорсный (но не си, а плюсы и java). Оригинальный JDK вообще проприетарный насколько я знаю (но могу ошибаться, огурчик не специалист по миру java)

mariadb (не формально проприетарный ныне mysql)- опенсорсная

nginx (ne nginx+) - опенсорсный

postgresql - вообще чуть ли не половина написана российскими программистами, и да, тоже опенсорсный (ок, enterprice версия не совсем опенсорсная).

Вероятность работать с этими проектами из РФ вполне себе не мала и вообще никак не зависит от опыта в микроэлектронике.

То, насколько все эти штуки являются desktop, я даже комментировать не хочу.

Не тратьте свое время на изучение Си

Тратьте если вам реально интересна профессия. Мало что так прочищает мозги в плане "а как вообще всё это работает под капотом?" как наличие опыта программирования на чем-нибудь относительно низкоуровневом и дубовом, например С. К тому же гораздо легче осваивать условный python, имея хотя бы небольшой опыт в С, чем осваивать rust/плюсы/С, начав с python. Это парадоксально (ведь, казалось бы, тут алгоритмы и там алгоритмы), но факт.

A сам язык Си остался для сборки артефактов для микроконтроллеров с экстремально малыми ресурсами

Ну вообще-то используется там, где нужно гарантированное поведения/реакция/исполнение. При экстремально малых ресурсах - чистый ассемблер. И не факт, что писать классами на MCU будет проще. Разбираться потом - да проще.

Вероятно, что язык программирования С для МК вскоре и вовсе войдет в историю.

Вы ну просто слишком оптимистичны.... Думаю, что вы раньше в историю войдете.

Есть конечно DeskTop проекты написанные на С

Ага, большинство драйверов на ОС.

Не тратьте свое время на изучение Си!

100%, особенно если он вам и нафиг не надо. Но, вопрос: а чего ж вы в данном топике целую главу написали? Может оно для вас и не так?

Ну вот. Уже до SIM карт Java добралась.
Это как раз только подтверждает мой первый тезис об ущербности программирования на Си в современном мире.

Языке Си очень много недостатков.

Вот вам яркий пример:

Я синтезирую массив структур препроцессором Си.

Потом проверяю, что получилось на выходе Си(шного) препроцессора cpp.exe
А там в *.pp файле получается гигантская строка.

Как бы мне на выходе Си препроцессоре сгенерировать принудительный перенос строки из исходного кода на Си?
Чтобы в файле *.pp не было длинных строк.

Может для этого есть какое специальное Predefined Macro, триграфы или ключ для утилиты cpp?

А при чём тут человекочитаемый вывод с удобненькими переносиками и препроцессор? Ну настройте свой редактор/ide/утилиту для просмотра чтобы она длинные строки резала для удобного представления и всё. Идея вставлять перенос строки в сгенерированный код ради удобства чтения оного подобна идее выведения удобной породы котов с ручкой для переноски.

Это нужно для исключения повторяющих ся эмементов в массиве на стадии компиляции. Утилитой uniq. А утилита uniq работает со строками.

Расчехляйте другие инструменты значит. Это всё ещё не проблема препроцессора. Это проблема того, что вы хотите странного при использовании неподходящего инструментария.

Какие именно другие инструменты?

Недостатки в языке Си:

1--нет типа данных int24_t int13_t и т.п.
2--нет встроенных в язык абстрактных типов данных: FiFo, LiFo, Set, HasSet, AVLtree и т. п.

3--нет возможности на стадии компиляции обнаружить повторяющиеся элементы в постоянном массиве

Насчёт третьего не скажу, не могу придумать, зачем это может быть нужно.

нет типа данных int24_t int13_t и т.п.

А в каких языках они есть из коробки?

нет встроенных в язык абстрактных типов данных: FiFo, LiFo, Set, HasSet, AVLtree и т. п.

Такой себе недостаток, на си все эти структуры уже написаны, просто не входят в стандартную библиотеку. Да, придётся немного потрудиться и добавить себе в проект нужную структуру, но это не сложно ведь.

У си есть куда более серьёзные недостатки, я их в своём комменте описал

Насчёт третьего не скажу, не могу придумать, зачем это может быть нужно.

У нас на стадии препроцессора формируется большой массив структур для команд SHELL.
И часто команды при сборке дублируются и отжирают Flash память. Выявить это получается только в run-time что крайне не удобно так как надо снова пере собирать сборки.

Это проблему легко можно решить сторонними средствами, не вижу проблемы в том, что язык не поддерживает compile-time вычисления. Тем более это не проблема конкретно си, в подавляющем большинстве языков нет поддержки произвольных вычислений в compile-time.

Я бы решил проблему так - сделал бы список с командами на каком-нибудь скриптовом языке, дальше устранил бы дубликаты и сгенерировал бы .h файл

Я бы решил проблему так - сделал бы список с командами на каком-нибудь скриптовом языке, дальше устранил бы дубликаты и сгенерировал бы .h файл

Не ясно. У нас сборка из makefile. Массив команд формируются препроцессором cpp.exe.



Эту проблему можно было бы решить утилитой sort + uniq которые, работают между препроцессором и компилятором, но для этого надо научиться как-то на выходе препроцессора cpp вставлять принудительные переносы строки.

А утилита препроцессора cpp не может принудительно генерировать перенос cтроки на выходе.

Ну всегда можно написать свой скрипт, который будет вставлять переносы строки где нужно или сразу разделять по нужному символу и исключать дубликаты

Стандартная библиотека языка С не была очень большой, это позволило довольно легко разрабатывать для него компиляторы.

Какое отношение размер стандартной библиотеки связан со сложностью и вообще разработкой компилятора?

Sign up to leave a comment.

Articles