[dxp 33]

Это — ваши фантазии. На С написано больше полезного софта, чем на любом другом языке. Потому что только С позволяет иметь большую гибкость и кучу удобств!

Именно! Шарп - это вообще какая-то местечковая поделка M$. Захотелось иметь свою жабу, вот и родили. А цэ-крест-крест - уже в самом названии - язык, на котором даже автор поставил аж два креста! Ну, что там можно от него ожидать?! Одни понты: какие-то, дескать, типы, определяемые пользователем - это зачем? чтобы запутать? Перегрузка операторов - зачем? Опять чтобы запутать. Как будто без этого у программиста проблем нет. А шаблоны - эт ваще песня! Многословный мутный синтаксис, по которому компилятор должен что-то родить. Нередко там оно такого нарожает, что мама-не горюй! Тонны дублирующегося кода. А потом удивляются, что процы на гигагерцах и гигабаты памяти, а проги всё равно тормозят и не лезут.

 

А этот самый полиморфизм! Написать код, который не ясно, что конкретно делает, а ясно только на рантайме. А там уже поздно выяснять. И зачем это? Опять чтобы запутать. Если кто в этом что-то и может делать, то только автор. В общем, write-only язык.

 

Отдельно хочется отметить так называемые виртуальные функции! Это что за название? Что обычно называют виртуальным? Что-то такое, что как бы является похожим. Т.е "виртуальные функции" - это "как бы функции", т.е. не настоящие, а выдающие себя за них. Так понимать? И так там во всём. Костыли на костылях.

 

Но и С - это тоже полумеры! С - есть попытка сделать портабельный макроассемблер, и вся его мощь в том, что программист может управлять ресурсами на низком уровне. И если раньше этот подход (портабельный макросассемблер) был ещё как-то оправдан, то сегодня это уже анахронизм - компания ARM решила эту проблему - изобрела унифицированную ISA, и теперь без разницы, какой проц - надо микроконтроллер или апликушный процессор, ассемблер тот же самый. Т.е. без разницы, Cortex-M или Cortex-A, команды пишем те же самые. Скажете: "А как же другие процы, которые не ARM?". Так они все обречены на вымирание, нет смысла тратить на них время. Надо учить ассемблер ARM, это решает все проблемы без гемора, вносимого так называемыми "языками высокага уровня".

 

Возвращаясь к С - и этот тоже туда же (в смысле, больше проблем от него, чем пользы). Например, если надо обратиться по конкретному адресу, это требует явного преобразования типов через мерзкий, ломающий мозг синтаксис типа (*(int *)ptr). А у ж разместить переменную по конкретному адресу вообще средствами языка невозможно - начинают тянуться всякие расширения, которые у разных вендоров все разные, а у некоторых отсутствуют. Ну, и где эта хвалёная переносимость?

 

А пресловутая "адресная арифметика"?! Это нескончаемый источник труднообнаруживаемых ошибок. Недаром серьёзные фирмы, выпускающие ответственные изделия (автомобильная электроника), осознав эту проблему, разработали отдельный стандарт для безопасности - MISRA, где вся эта возня с указателями и адресной арифметикой просто запрещена!

 

Другое дело ассемблер: доступны абсолютно все средства используемой целевой платформы, без всякого гемора оптимальнейшим образом достигаем любой цели. Например, попробуйте на С написать такое:

    mrc    p15, 0, r0, c1, c0, 0        /* read CP15 register 1 */
    bic    r0, r0, #0x1            /* clear bit 0 */
    mcr    p15, 0, r0, c1, c0, 0        /* write value back */

 

А уж про синтаксические правила и говорить нечего. Ведь это же надо придумать конструкции вроде такой:

 

int (*(af[]))(int);

 

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

 

int* ptr;

 

или

 

int *ptr;

 

Я вот думал поначалу (и довольно долго), что первый вариант - дескать, int* - это тип указателя. Хотя даже тогда не покидало чувство, что что-то тут не так - почему для объектов звезда применяется слева, а для типов справа. А потом узнал, что правильно - второй вариант. И трактуется это так: "ptr - это такой тип, при разыменовании которого, получается int".

 

Т.е. по сути типа указатель в языке вообще нет! Есть неявный тип, при разыменовании которого получается уже настоящий тип. Это ж какая извращённая логика в этом заложена! Отсюда и этот ужасный синтаксис выше - про массив указателей на функции.

 

Т.ч. не, не говорите, что С хороший язык. Попытка сделать портабельный макроассемблер - да. Имела право на жизнь? Да. Нужна ли сейчас? Нет! Учите ISA от ARM, и будет вам счастье.

 

На нем вообще ничего нельзя писать, как и на пхытоне.

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

 

Тоже чушь! Начать с отступов вместо скобок, спагетти-кода и вообще полной алогичности самого языка! Нет, на пхытоне работать — себя не уважать! Единственное, что удобно в пхытоне — количество кода в разы меньше, чем на С. Но, естественно, только под узкий круг задач: микроконтроллеры на пхытоне не попрограммируешь, и операционку на нем не напишешь. Ибо убог.

Да, какой-то голландский (кстати, это может не случайно) мужык по имени Гуидо решил, что мне удобно везде использовать одинаковый отступ для выделения блока, а я вот, может, люблю каждую строчку индивидуально отодвинуть от края. И потом - подумать только - ведь каждый объект - это выделение памяти в куче (malloc, сиречь). Это ж какой тормоз-то получается! Ну подумаешь, динамическая типизация - зачем она? Только запутывает! Никогда не знаешь, какого типа объект.

 

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

[hsoft 0]

Я тоже хочу такой травы.... :):):)

[DASM 0]

Вы ничего не понимаете в программировании. Вот код настоящих профи своего дела, такие кадры воспитываются в отдельных элитных ВУХах страны и они нарсхват

static int bus_spi_cs(dev_spi_t * dev, bool state)
{
dev_gpio_t * cs_pin = ((dev_spi_stm32f_hints_t *) dev->hints)->spi_cs_pin;
((int (*)(dev_gpio_t *))((uint32_t)cs_pin->setpin*(!state) + (uint32_t)cs_pin->resetpin*(state)))(cs_pin);	
return 0;
}

Я всего лишь колхозник самоучка и заменил на

static int bus_spi_cs(dev_spi_t * dev, bool state)
{
dev_gpio_t * cs_pin = ((dev_spi_stm32f_hints_t *) dev->hints)->spi_cs_pin;	

if (state)
	cs_pin->resetpin(cs_pin);
else 
	cs_pin->setpin(cs_pin);		
return 0;
}

Мне придется много учиться еще, чтобы хоть немного достичь уровня этих, не побоюсь этого слова, Мастеров.

:crying:

А вы говорите Питон плохой и Сишарп

Кстати все поняли как работает первый вариант? Мой уровень на грани имбицилла позволил понять примерно минут за 10 только

моя б воля запретил бы приведение типов программистом вообще, а еще лучше и сами типы как класс, лишнее это нонче

[AlexandrY 2]

Кстати все поняли как работает первый вариант? Мой уровень на грани имбицилла позволил понять..

 

Видно, что программно, остальное не интересно.

Переходите на Kinetis, там CS передается вместе с данными. Можно одним блоком DMA писать/читать сразу из 6-и слэйвов, вообще не парясь установкой и снятием CS.

[DASM 0]

Видно, что программно, остальное не интересно.

Переходите на Kinetis, там CS передается вместе с данными. Можно одним блоком DMA писать/читать сразу из 6-и слэйвов, вообще не парясь установкой и снятием CS.

мне лично никуда переходить не надо, я на Питон перелезаю, ну и драйвер на Сях немного V4L

[AlexandrY 2]

мне лично никуда переходить не надо, я на Питон перелезаю, ну и драйвер на Сях немного V4L

 

Кстати в VS2017 бесплатно идет Xamarin.

Это С# для всего - iOS, Android, Win

 

Как бы must-have в свете последних трендов, важнее математики.

[dxp 33]

Вы ничего не понимаете в программировании. Вот код настоящих профи своего дела, такие кадры воспитываются в отдельных элитных ВУХах страны и они нарсхват

static int bus_spi_cs(dev_spi_t * dev, bool state)
{
dev_gpio_t * cs_pin = ((dev_spi_stm32f_hints_t *) dev->hints)->spi_cs_pin;
((int (*)(dev_gpio_t *))((uint32_t)cs_pin->setpin*(!state) + (uint32_t)cs_pin->resetpin*(state)))(cs_pin);	
return 0;
}

Мне придется много учиться еще, чтобы хоть немного достичь уровня этих, не побоюсь этого слова, Мастеров.

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

 

Или критерий оценки - чем запутаннее, тем круче? По мне так ровно наоборот. Хороший код прозрачен, лёгок для восприятия и модификации. Мастерам есть куда расти.

 

Вот такие вот примеры и приводят желанию писать на ассемблере - там такого безобразия в принципе быть не может.

[DASM 0]

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

 

Или критерий оценки - чем запутаннее, тем круче? По мне так ровно наоборот. Хороший код прозрачен, лёгок для восприятия и модификации. Мастерам есть куда расти.

Сарказм тэе где тут :) Меня приколоа идея сложения указателей.. или как-то так? Я уже снова не понимаю как это работает

(int (*)(_t*) ((uint32_t)setpin*...+ (uint32_t) ....) ()

[Гость TSerg]

Именно!

Но и С - это тоже полумеры!

Другое дело ассемблер:

Да, какой-то голландский

И вообще типы - зло. Какая-то лишняя сущность. Вон на ассемблере нет никаких типов, всё просто и прозрачно

5+!!!

 

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

Задачка простая:

- есть/создается массив random-целых (integer 32b) чисел;

- требуется отсортировать массив на месте по следующим правилам:

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

 

Пример:

rnd= 19 [40,14,17,46,12,53,3,49,26,56,10,28,59,20,35,42,42,18,24]

sort=19 [56,46,42,42,40,28,26,24,20,18,14,12,10,3,17,35,49,53,59]

 

Требования: простота, изящность, самодокументируемость кода для понимания студентами.

Реализация планировалась на тех или иных разновидностях Pascal/Delphi/FreePascal/Lazarus.

 

Были предложены решения (код) тремя программистами в качестве междусобойчика уже (про студента быстро забыли).

Два программиста исповедовали стиль аля Си, но на Pascal (Turbo Pascal).

Третий предложил метод "разделяй и властвуй" тоже на Pascal ( PascalABC.Net).

Причем, как было показано, высокоуровенное решение вообще сводится к array.Sort(cmp), где cmp - функция сравнения для сортировки.

Что выбрал студент - к бабке не ходи :)

 

P.S.

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

[=SSN= 0]

Задачка простая:

- есть/создается массив random-целых (integer 32b) чисел;

- требуется отсортировать массив на месте по следующим правилам:

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

 

P.S.

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

Яркий пример некорректно поставленной "задачки".

 

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

 

В противном случае, "задачка" решения не имеет..

Изменено 27 марта, 2017 пользователем =SSN=

[hsoft 0]

Пример:

rnd= 19 [40,14,17,46,12,53,3,49,26,56,10,28,59,20,35,42,42,18,24]

sort=19 [56,46,42,42,40,28,26,24,20,18,14,12,10,3,17,35,49,53,59]

Результаты

[73, 52, 1, 33, 26, 84, 39, 58, 24, 57, 74, 37, 87, 90, 84, 8, 50, 89, 16, 9, 70, 15, 75, 37, 77]

[90, 84, 84, 74, 70, 58, 52, 50, 26, 24, 16, 8, 1, 9, 15, 33, 37, 37, 39, 57, 73, 75, 77, 87, 89]

 

Изменено 27 марта, 2017 пользователем hsoft

[Гость TSerg]

Яркий пример некорректно поставленной "задачки".

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

В противном случае, "задачка" решения не имеет..

Ерунда. Задачка имеет четкое решение, без особенностей.

Надо было понять, что "центр" массива - плавающий индекс, который определяется конкретным набором rnd-чисел.

[=SSN= 0]

Надо было понять, что "центр" массива - плавающий индекс, который определяется конкретным набором rnd-чисел.

Студент не обязан догадываться, что препод "тупит"..

 

Сначала научитесь ясно выражать свои мысли, а потом занимайтесь преподавательством.

[Гость TSerg]

Вот так на Java

..

list.sort(new Comp());

..

Вот и я про это.

[AHTOXA 14]

static int bus_spi_cs(dev_spi_t * dev, bool state)
{
    dev_gpio_t * cs_pin = ((dev_spi_stm32f_hints_t *) dev->hints)->spi_cs_pin;
    ((int (*)(dev_gpio_t *))((uint32_t)cs_pin->setpin*(!state) + (uint32_t)cs_pin->resetpin*(state)))(cs_pin);    
    return 0;
}

Ух ты, это где вы такое нашли?