Как писать на C в 2016 году

Дык MIPS же! На них целая куча роутеров сделана!

Дык MIPS же!

Как писать на C в 2016 году (комментарий)

И на всякий случай: Microblaze - часть того же мира, в котором x86, ARM и прочие.

C99-AnnexF
This annex specifies C language support for the IEC 60559 floating-point standard. The IEC 60559 floating-point standard is specifically Binary floating-point arithmetic for microprocessor systems, second edition (IEC 60559:1989), previously designated IEC 559:1989 and as IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE 754−1985). IEEE Standard for Radix-Independent Floating-Point Arithmetic (ANSI/IEEE 854−1987) generalizes the binary standard to remove dependencies on radix and word length. IEC 60559 generally refers to the floating-point standard, as in IEC 60559 operation, IEC 60559 format, etc. An implementation that defines __STDC_IEC_559__ shall conform to the specifications in this annex. Where a binding between the C language and IEC 60559 is indicated, the IEC 60559-specified behavior is adopted by reference, unless stated otherwise.

То есть, если есть макрос __STDC_IEC_559__, тогда float - 32, double - 64, если нет, - зависит от реализации.

А либы таки бывают, тот же AMR...

Ошибся, бывает...

А это проблемы компиляторов. ИМХО правильнее решать их, чем использовать неоправданное goto.

А это проблемы компиляторов.

Это вы немного не про то - это вы про ИИ.

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

Могу привести пример задания, которое можем вместе запрограммить.

Вы без, а я с goto.

Пробуем?

То есть, если есть макрос __STDC_IEC_559__, тогда float - 32, double - 64, если нет, - зависит от реализации.

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

А либы таки бывают, тот же AMR...

Линк на исходники? Интересно посмотреть.

Как байтофаг могу сказать, что статья однобокая.

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

Спорные моменты в статье:

1. Не под все архитектуры (даже совсем новые!!!) есть компиляторы чего-либо помимо Си, а переносимость кода обеспечивать надо...

Так что призывы отказаться от Си и использовать Rust, - мягко говоря, не торт.

2. Даже если целевая платформа современная, и на нее есть компилятор Си, то не обязательно он будет поддерживать C99 и C11.

Так что советы по поводу char, int, long, unsigned, объявления переменных где угодно, #pragma once, некорректны.

3. Про размеры float и double уже говорили.

4. Автору следовало вначале статьи обозначить целевую аудиторию, чтобы читатель мог не тратить время зря.

Вот: https://github.com/android/platform_external_opencore/tree/master/codecs_v2/a...

Реализация тянута прямиком из рекомендаций ITU, максимум, перевели с Си на Плюсы.

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

Что-то не заметил там этой мысли, можно попдробнее, где он это говорит?

И как называется эта библиотека?

И что тебе скажет название моей собственной рабочей библиотеки для опроса микроконтроллером его Модбас-слейвов и выдачи, при необходимости, телеметрии на ПК по тому же Модбасу? Тем более, что я навскидку и не помню, типа libmodbus_slave_чо-то_там. А дома исходники не держу — ещё не хватало.

Совсем хорошо, если в ней будет использоваться хотя бы float.

Там плавающая точка вообще мало где используется, только для телеметрии, насколько помню. И упаковывается в 16-битные Модбасовские регистры (Модбас в этом смысле тоже не подарок с его парадигмой «или отдельный бит, или 16-битное слово»). А вот чтобы один и тот же исходник с упаковкой/распаковкой можно было собрать и на МК, и на ПК (на всякий случай — именно это и называется «переносимость») — и начинаются пляски с макросами, дефайнами и прочим. И заблуждение насчёт того, что «float = 32 бита, double = 64» тут не поможет никак.

А ошибся, автор в комментах вместо Сей предлагает использовать Эрланг...

Хотя, не так уж и ошибся...

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

Я чаще всего встречаю goto в сишном коде, имитирующем RAII

Вот: https://github.com/android/platform_external_opencore/tree/master/codecs_v2/a...

«OpenCORE is the multimedia framework of Android» - как бы автоматически это не экзотичные процессоры. Или изначальные исходники ITU подразумевали что-то более широкое?

Что-то не заметил там этой мысли, можно попдробнее, где он это говорит?

Именно этих слов он, естественно, не говорит. Это мое понимание посыла статьи.

«OpenCORE is the multimedia framework of Android» - как бы автоматически это не экзотичные процессоры. Или изначальные исходники ITU подразумевали что-то более широкое?

Естественно более широкое.

Именно этих слов он, естественно, не говорит. Это мое понимание посыла статьи.

Зато он говорит:

A few people seem to have read this as an «I hate C» page,
but it isn't. C is dangerous in the wrong hands (not enough
testing, not enough experience when widely deployed), so
paradoxically the two kinds of C developers should only be
novice hobbyists (code failure causes no problems, it's just
a toy) or people who are willing to test their asses off
(code failure causes life or financial loss, it's not just a
toy) should be writting C code for production usage. There's
not much room for «casual observer C development.» For the
rest of the world, that's why we have Eglang

Что как бы намекает нам...

Ну понятно, что бывают float и double одного размера

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

Значит надо не использовать даблы, да? Значит надо просто не писать. А уж если пойти дальше и учесть, что и флоатов может не быть, то и флоаты использовать то же не надо.

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

«OpenCORE is the multimedia framework of Android» - как бы автоматически это не экзотичные процессоры. Или изначальные исходники ITU подразумевали что-то более широкое?

Естественно более широкое.

И вот об этом где можно узнать? Если честно, я сильно сомневаюсь, что ITU рассчитывали на экзотику.

Что как бы намекает нам...

На что?

И что тебе скажет название моей собственной рабочей библиотеки для опроса микроконтроллером его Модбас-слейвов и выдачи, при необходимости, телеметрии на ПК по тому же Модбасу?

Тот факт, что ты написал библиотеку для микроконтроллера, но проверял ее на ПК, наводит на размышления. Не было эмулятора или по каким-то причинам он был неюзабельным?

https://github.com/nginx/nginx/blob/645697f111983089fdcee0694d17480e0a05a3a5/...

-Werror только конкретно под gcc, а выше по файлу костыли, чтобы на разных версиях работало. Для остальных компиляторов аналогичные костыли по месту (в шланге чисто, в icc костыли, в ccc пц костыли, и т.п.). Это как раз демонстрирует мои слова.

Недолго царь звиздел...

ITU писали референсную реализацию для проверки работоспособности алгоритмов...

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

Сайт называется «РУССКАЯ информация об ОС Linux». А ты сюда иносранщину без перевода притащил. Фу таким быть.

Тебе уже мозги импортозаместили?

Ага... Понял ононимусам отвечать сам дурак... Ок...

Хотя звёзды мне нафиг не нужны и не стремлюсь.

Нет времени на эту фигню. И даже не понимаю зачем они.

Просто общаюсь с людьми.

Никому не грублю.

Намекает нам на то, что автор любитель ФП, и в тайне ненавидит императивщину.

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

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

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

Да и использование одной либы для «клиента» и «сервера» сильно упрощает жизнь, знаете ли.

Разумное. Но возможно ли? Во встраиваемых системах практически все на С. bash -> busybox. Хорошо, если порой sed и/или awk встречается... Ну а python например вряд какой нибудь вендор захочет «тащить» в свой девайс (тяжеловато будет).

Но тут есть другая проблема, компилеры старые, многие фичи (особенно по оптимизации), для архитектур ARM, MIPS не поддерживаются.

Ну а python например вряд какой нибудь вендор захочет «тащить» в свой девайс (тяжеловато будет).

Есть micropython. И я точно знаю что он используется для съема показаний счетчиков воды/электричества в DC.

Варианты всегда есть.

Ок, посмотрим, за этим и пришел сюда.

За информацией.

А оно умеет ООП в питоне?

Разумное. Но возможно ли?

Я знаю, что избежать Си не всегда возможно. Сам на нем пишу.

Во встраиваемых системах практически все на С. bash -> busybox.

Ну, если у тебя достаточно жирная система для Linux (с busybox или настоящим bash), она достаточна и для Си++. По моему опыту, это окупается.

Да.

Согласен. Но «плюсовиков» «чистых» я имею в виду, не особо и берут на работу в embedded, работодатель часто требует понимания системы (взаимодействия us - ks), а не построения иерархии классов...

Но, вот, чтобы реализовать например CLI(command line interface), не хуже, чем это сделано у Cisco, нам нужен плюсовик, чтобы не заморачиваться с ежесекундными сегфолгами, при построении дерева команд и при auto completion.

Но «плюсовиков» «чистых» я имею в виду, не особо и берут на работу в embedded, работодатель часто требует понимания системы (взаимодействия us - ks), а не построения иерархии классов...

Опять же, по моему опыту, чистый плюсовик и не нужен. И развесистые иерархии классов не нужны - это же embedded, а не проектирование нового Photoshop (это уже не говоря о том, что развесистые иерархии наследования считаются плохим тоном).

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

Современный Си++ (начиная с C++0x) сильно легче в применении, чем, например, C++98. Но инерция мышления...

Ему придется все переписывать?

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

Но инерция мышления...

Угу... Тем не менее, проект обрастает таким множеством костылей, что надо что-то уже делать. Не уверен, что g++, используемый в проекте поддреживает С++0х.

Интересно, а clang поддерживает, хотя, уверен, что да.

Не уверен, что g++, используемый в проекте поддреживает С++0х.

Версия?

Сейчас не могу сказать. В РФ же праздники... удаленного доступа нет, политика компании. Да я и сам загуглю, если что.

У меня сейчас 4.3, в котором даже unique_ptr стандартно нет. Но это всё равно лучше, чем Си (и как минимум 2 реализации unique_ptr есть в Сети, одна - в cxxomfort, другую я нашел где-то в списках рассылки gcc).

Ок.

Затащить новый компилер в проект, мне кажется, хрен получится. Тем более, что он разбросан по континентам... Боссы не пойдут на это, нужны убедительные пруфы и бенчмарки... К тому же, gcc текущий генерит достаточно оптимизированный код, что удовлетворяет заказчика. )))

Но я попробую.

подкрепишь списком неподдерживаемых оптимизаций?

К тому же, gcc текущий генерит достаточно оптимизированный код, что удовлетворяет заказчика.

откроешь секрет сей чудо архитектуры для эмбэдщены?

С чего ты взял, что только «проверял»? Она работает как в контроллере, так и в ПК-шном клиенте.

На самом деле не исключено, что ПК-шный клиент ещё переделаем сто раз — проект меняется постоянно — и переносимость будет уже не особенно нужна. Она, как бы, и сейчас не критична, но если есть возможность — почему бы не сделать? Ну да, хотя бы потому что «проверить на ПК» можно, если что.

С чего ты взял, что только «проверял»?

Где ты увидел «только»?

Она работает как в контроллере, так и в ПК-шном клиенте.

Но ты писал ее, _точно зная_ что она должна работать на МК.

но если есть возможность — почему бы не сделать?

Потому что это не нужно чуть менее чем всем.

Нет SIMD, хотя проц поддерживает.

Нет.

и как минимум 2 реализации unique_ptr есть в Сети

Ну и буст (scoped_ptr).

Но «плюсовиков» «чистых» я имею в виду, не особо и берут на работу в embedded,

«Чистый» плюсовик - такой же долбоеб, как и чистый джавист и чистый phpшник. Их никуда брать не стоит.

Никогда не понимал, зачем нужен scoped_ptr, если есть unique_ptr.

Вот считают, что питон в микроконтроллерах - норм.

Аналогичные штуки видел для Java и JavaScript.