Все обсирают бейсик (типа недостойный) паскаль (и другие ЯВУ). Восхваляют Си. А чем он лучше? На мой взгляд - полное гуано собачье. Такое ЯВУ достойно тех, кто даташиты не признаёт, и всякие сраные библиотеки под Си ищет (самому написать как-то в падлу(ну как же, даташит читать надо )).
Как сказали два умных мужика:
- В Си надо писать очень определённым шрифтом, с очень определённым наклоном, разными цветами
- на Си можно написать: main(_,l)char**l;{6*putchar(--_%20?_+_/21&56>_?strchr(1[l],_^"pt`u}rxf~c{wk~zyHHOJ]QULGQ[Z"[_/2])? 111:46:32:10)^_&&main(2+_,l);} и это не будет ошибкой (автор - ARV)
Не это ли верх извращенства?
Когда посмотришь в дизасме код после си , блевотинкой захапывающей память попахивает.
И что интересно, в последнее время на сайте чевойто народ на асм подтягивается.

я весьма скептически настроен к Си. но я полностью объективен в его оценке.

я полностью согласен со следующим мнением:

но я не согласен, с вашим определением, высказанным в весьма резком тоне. при всех своих недостатках и странностях синтаксиса язык Си является практически безальтернативным вариантом для программирования микроконтроллеров. все дело в количестве программистов, его использующих: их огромное количество, они уже сделали огромное количество библиотек на любые случаи жизни, и количество людей, способных помочь при возникновении вопросов измеряется сотнями тысяч (вообще).

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

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

так что при всем богатстве выбора иной альтернативы нет...

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

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

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


В том плане, что программирование начинается на бумажке, обычным литературным языком, с карандашом в руках. Или на планшетнике с электронным пером, кому как.
И на Си, и на ассемблере, и на Бэйсике можно накалякать такой хрени, что только фтопку.
- Вы любите кошек?
- Нет
- Да вы просто не умеете их готовить!

Думаете, на Си вам не нужны знания даташитов? Ага, да вы просто не в курсе.
Думаете, на ассемблере вас спасут знания даташитов? Да черта с два! для ассемблера вам понадобится знание ассемблерных команд, это и все, что будет дополнено к Си.
Дизасм после Си не нравится? Так если вы привели запись на Си: main(_,l)char**l;{6*putchar(--_%20?_+_/.... (много букав еще), так какого вы ждете еще? Как написали, так и получили. Пеняйте на свои кривые руки из жoпы.

Хотите писать на Паскале или Бейсике? Пишите, не вопрос, вас никто не отговаривает, и религия не запрещает.
Пишите на том, на чем умеете. Это сугубо ваше личное дело.


то есть вот так, да? :


а чем это плохо? Цветовое и начертательное выделение синтаксиса - это безусловно удобно. Или вы - суровый челябинский кодописатель? Ну-ну.
Сравните предыдущий кусок с вот этим:


тест тот же самый, а восприятие разное. Так что не надо ля-ля насчет выделения синтаксиса. Когда у вас портянка на 10 страниц совершенно одинакового черно-белого текста, вы черта с два сможете выделить в нем хоть какие-то блоки.
Цветовое выделение на первый взгляд кажется маскарадом, но если у вас уже отработан стиль и вы придерживаетесь его, то вы вскоре даже будете благодарны различным цветам и шрифтам. Вы с легкостью отличите глобальную переменную от локальной внутри функции и легко вообще найдете, где у вас переменные там записаны, а где функции, и быстро найдете комментарии.
Цвета ведь настраиваются. По своему усмотрению можете задать схему с меньшим "маскарадом", выделяя лишь то, что вам нужно по вашему усмотрению.

100% !
Для слабых камней есть правило "Одна строка - одно действие", для 16-32 бит камней это правило уже не всегда действует. Сложная на вид строка может быть соптимизирована куда лучше и правильнее, чем набор простых.

Ага! Только пусть не забудет в дизасм заглянуть, что там эти черти наваяли.

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

После любого языка высокого уровня дизасм будет вызывать несварение желудка с точки зрения религиозно-правильного ассемблерщика. Но если на мелких пик-авр это еще имеет значение, то на более крупных и мощных контроллерах это уже не столь важно.
Я так понял, топикстартер некоторое время сидел на Бейсике и смотрел дизассемблированный его код, пытаясь изучить ассемблер, и ему очень не нравился получаемый результат.
Хотите писать на ассемблере - пишите, если сумеете. Но вы должны писать именно на ассемблере, а не опираясь на дизасм. Как один кекс тут похвалялся писаниной на ассемблере, а на поверку оказался это дизасм.
Так что, изучайте ассемблер с начала.
Например, когда на мелких пиках уткнетесь в математику, одинхрен пойдете искать готовые ассемблерные куски. Которые, кстати, писаны еще лет 10-15 назад.

Кстати, доводилось ли кому видеть, как начинает колбасить сишную отладку при высоком уровне оптимизации?

Вам лишь бы поспорить.

ну что вы, нет конечно!
а вам лишь бы сказать что-то бездоказательно

А вот хренушки! С Асма всё началось. Си видал в ......
А давайте моск ипать не будем. Пишем моргалку, кажный в своём любимом языке на полсекунды, на любом PIC (не сильно новом (увы, кислодрищенск)). Сравним, померим письки.

И что? Мне, например, пофигу. Если оптимизатор свою задачу выполнил и всё работает как надо, то какая мне разница? Если оптимизация по скорости, компилер там чёта развернул, чёта заинлайнил, код чуть подрос в размерах - ну и фиг с ним! На АСМЕ пришлось бы делать то же самое, только вручную, и код точно также бы подрос. Если по размеру - компилятор что-то там навыпиливал в подпрограммы, что-то там понавыхватывал, код сократился? Ну и ладно! На АСМЕ тоже бы пришлось выискивать что можно урезать. Всё равно отладку, как правило, производят только в узких местах, а не всего того что уже работает. Там можно и поднапрячься.

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

Это и всё что вы имеете мне сказать?

да

Добавлено after 1 minute 56 seconds:
да, кстати, второй-то кто?

А вот еще одна сишная фишка, которая вызывает у многих непонимание, а половина вообще не знает об этом, а еще одна половина неправильно этим пользуется. #include и файлы хидеров *.h
Кто-то во все файлы кода *.c подключает все хидеры сразу, кто-то пытается подключить вместо хидера файл кода *.c, кто-то создает файл main.h и в него собирает все хидеры и подключает main.h ко всем файлам кода - кто во что горазд. И получают засорение пространства имен и разросшееся пространство доступа к функциям. Неправильное использование хидеров приводит к тому, что имена функций, переменных, макросов и дефайнов приходится делать уникальными на протяжении всего кода. Например, GREEN_LED_01. Хотя правильное подключение хидеров позволит использовать одно имя LED хоть для десятка одинаковых или разных светодиодов.
Кто-то вроде и более-менее правильно подключает хидеры, но в файл хидера включает не то, что надо было бы. И получает снова засорение имен и распространение доступности не в тех границах, которые следовало бы.
Фишка языка Си в этом плане такова, что пространство имен переменных, текстовых замен и доступность функций определено от начала файла и до его конца. Расширить границы доступности можно при помощи #include заголовочного файла, в который помещены переменные и прототипы функций, которые должны быть доступны извне. Вот именно с помощью инклюда можно создать такие связи между файлами, когда не будет прямой видимости из main.c локальных функций и переменных, определенных в некотором файле. И внутри разных файлов можно будет использовать одинаковые локальные имена, если они не выходят за границы этого файла, то есть не вынесены в файл хидера.

Сложность для понимания? Да. Но зато какие возможности она открывает.

Та даже не интересно, тем более на ПИКах и тем более на старых. Там "Всё уже украдено до нас!"(с). Ну и что вы там увидите? Инит переменных? Так это и в АСМе требуется. Загрузку константы генератора? Так это можно отключить в опциях компилятора, при необходимости. Старенький добрый Хайтеч сделает код на уровне средного АСМИста, т.е не хуже. И за что там в АСМе бороться? За несколько байт? Так я лучше сразу возьму СТМ8 или СТМ32, если уж на то пошло, и не буду вообще вспоминать этот кошмар под названием Микрочип.

Давайте. Тем более что это уже столько раз обсуждалось, что уже просто совсем.

да вот отвечу, токмо в личку.

А вот хренушки - за полсекуны вы даже палец на мышку перенести не успеете.
Да полстраны начинало с асма, и что с того то?
Могралку на ПИК? Вопервых, я сто лет не писал для старых пиков, но, не сильно углубляясь в даташитное соответствие,
асм:


Си:



вот, а теперь давайте напишем bin-to BCD на асме и на си?:) а потом попробуем написать что-то более сложное, с модульным раскладом. И засечем время. Разница будет не то что полсекунды, а даже и полдня и более, более, более.


Ладно, хорошо. А какой язык вам нравится тогда? Есть предпочтения? Так вот и пишите на выбранном языке и не выёживайтесь.
Можете писать на Бейсике, если вам он по душе. Вон есть Пик-Бейсик для пиков. или вообще Flowcode, какой-то графический турбо-визуальный-конструктор для младших научных сотрудников. Пжалста - ваш выбор, вам решать.
Как говорится, не умеете в воду пердеть - нефик рыб пугать.

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

в Си имена всех функций по умолчанию глобальны, а не ограничены "пространством имен файла". кстати, понятие пространства имен вообще в Си нет, не стоит и превносить этот термин. принято говорить "область видимости". так вот, область видимости идентификатора функции - весь проект в целом, если нет явного ограничения в виде static. более того, не локальные переменные так же формально имеют область видимости во всем проекте! только следует подсказать компилятору, что переменная всё-таки существует при помощи слова extern - и ошибки компиляции не будет, а линкер найдет это имя в любом из множества файлов проекта!

так что ваше утверждение о том, что область видимости ограничена файлом - ошибочно.

и, вообще-то, подобное "глобальное" поведение является недостатком Си, а не достоинством, как ошибочно можно предположить из вашего выступления.

Ознакомьтесь получше с языком Си и ваши заблуждения исчезнут.


Применяя extern повсеместно, вы лишаетесь модульности и усложняете себе жизнь. Extern требует двойного внимания.

Школота лютует! Хотя жо весны ещё далеко.