Что за тип данных uint32_t?

Это без знаковый int, который занимает 32 бита. А вот t, что значит?

0

Сообщение от COKPOWEHEU Вам - несомненно не нужен. Сидите на своем С++ и радуйтесь. Тем же, кто пишет на Си, нужен. И, заметьте, они в нем не путаются и не видят нужды заворачивать разные функции в макрос.

Как они "не путаются" заметно по существованию ключа компиляции -Wformat-extra-args, как раз и проверяющего не накосячил ли кто в использовании этого зоопарка.

Сообщение от COKPOWEHEU И где противоречие? В стандартной библиотеке обычно не нужны (разве что какая-то редко используемая экзотика). В юзерском коде - это его, юзера, дело, как ему удобнее.

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

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

Сообщение от COKPOWEHEU Это здесь каким боком?! Ну вот какое отношение различие диалектов в семействе ассемблеров (они все разные, если что) имеет к длине имен в Си или типу данных uint32_t?!

То есть, когда у Пети mov копирует слева направо, а у Васи справа налево, это теперь называется "диалект"?
Это здесь таким боком, что язык это правила синтаксиса. Если правила синтаксиса asm() целиком выдуманы авторами C++ компилятора то да, asm() это подмножество C++. Причем, не C++ вообще, а того диалекта, который в вашем компиляторе.

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

Сообщение от COKPOWEHEU Разработчикам gtk тоже Торвальдс мешает? И над программистами контроллеров он стоит с талмудом K&R готовый покарать отступников?

Разработчики GTK давно уже запилили C++ интерфейс gtkmm. При этом Кеды построенные на чисто плюсовом Qt, как я посмотрю, популярнее Гнома будут.
Что до контроллеров, вбил в Гугл "AVR C++". Сразу вылетел на статьи о том, как хреново C++ на AVR реализован. Так что да, на контроллерах на программистов давят.

Сообщение от COKPOWEHEU С этого начали. Логичнее было бы назвать этот тип покороче, но разработчики опасались за совместимость со всякими изобретателями u32.

std_u32 и проблема решена. Так что вывод банален, разработчикам не нужно было по короче. Им скрипя зубами пришлось признать, что нужно подлиннее. А сокращение они воткнули чисто из принципа.
Что до uint, делаем его псевдонимом unsigned и будет он востребован не меньше чем unsigned. Но опять же, разработчикам uint как отдельная сущность не нужен. Только как часть uint32_t.

0

Сообщение от Renji Как они "не путаются" заметно по существованию ключа компиляции -Wformat-extra-args

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

Сообщение от Renji Поэтому, что юзер, что разработчики библиотек находятся в одной и той же ситуации "на (какая-то буква)open уже и так три функции претендуют"

Но, поскольку эти функции делают разные вещи (хотя printf можно считать разновидностью fprintf и то только затем что используется часто) и названы вполне очевидно - никаких проблем с различием не возникает.

Сообщение от Renji И уж если разработчикам здесь длинных имен не нужно

Дальше этот поток мыслей не распарсил. Где не нужно, кому не нужно, для чего не нужно?

Сообщение от Renji То есть, когда у Пети mov копирует слева направо, а у Васи справа налево, это теперь называется "диалект"?

Что, день откровений номер два? Именно так это и работает: если в двух ассемблерах под одну и ту же архитектуру различается синтаксис - это два разных диалекта. Может быть, даже два разных языка, но это было бы уже слишком сильное высказывание.

Сообщение от Renji Если правила синтаксиса asm() целиком выдуманы авторами C++ компилятора

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

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

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

Сообщение от Renji Что до контроллеров, вбил в Гугл "AVR C++". Сразу вылетел на статьи о том, как хреново C++ на AVR реализован. Так что да, на контроллерах на программистов давят.

Да-да, это все заговор.
А вовсе не особенность устройств с малым объемом памяти и скорости, где все эти динамические выделения, перебор наследования и т.п. просто невыгодны.
Но, раз уж у нас сегодня еще один день откровений, я вас обрадую: при желании на С++ можно написать более читаемый и эффективный код, чем на Си. Вот только такой код не будет похож на код типичного плюсовика: придется отказаться от кучи привычных вещей и даже (о, ужас!) следить за памятью и прочими ресурсами самостоятельно. Увы, практика показывает, что лишь единицы способны таки побороть язык и написать на нем качественный код. У остальных же получается Ардуино...

Сообщение от Renji std_u32 и проблема решена

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

Сообщение от Renji Что до uint, делаем его псевдонимом unsigned и будет он востребован не меньше чем unsigned. Но опять же, разработчикам uint как отдельная сущность не нужен.

Именно так. uint как отдельная сущность не нужен.

0

Сообщение от COKPOWEHEU То есть почитать что же это за ключ и за что он отвечает - слишком сложно.

Почему то думал что sprintf("%s",text) оно тоже поймает. Но да не суть, варнинг "format string is not a string literal (potentially insecure)" все равно вылетает. Так что аргумент "если вы ничего, никогда, не путаете, зачем вам такие варнинги?" остается в силе.

Сообщение от COKPOWEHEU Но, поскольку эти функции делают разные вещи (хотя printf можно считать разновидностью fprintf и то только затем что используется часто) и названы вполне очевидно - никаких проблем с различием не возникает.

Теперь применяем ту же самую логику к вопросу "назвать функцию OpenPipe или popen". И получаем что у юзера нет никакой нужды выбирать длинный вариант. А если выбрал, значит дурак.

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

Это называется проблемой "язык или диалект". И решается в первую очередь исходя из того, понимают ли друг друга носители двух "диалектов". Два разных ассемблера друг друга не понимают, поэтому это два разных языка. C++ понимает Си прекрасно, Си понимает C++ с грехом пополам. Так что, извините, диалекты. А то что Петя и Вася называют свой язык одним и тем же словом, имеет значение в самую последнюю очередь.

Что до включения Си в C++, надеюсь, не будет большим откровением что тот же плюсовый <cassert> это просто редирект на сишный <assert.h>. Си-код инклудится в плюсы на регулярной основе. Что тоже аргумент отнюдь не в пользу его независимости и качественного отличия от плюсов.

Сообщение от COKPOWEHEU А вовсе не особенность устройств с малым объемом памяти и скорости, где все эти динамические выделения, перебор наследования и т.п. просто невыгодны.

Так это объемы памяти виноваты в том что avr-g++ пихает в каждый полиморфный объект по копии таблицы виртуальных функций? Тогда как g++ кладет туда только указатель на общую копию. Баг висел семь лет, закрыт без исправления. С итоговым комментарием "как в g++ сделать можно, но сложно... а по чесноку, avg-g++ просто немножко сдох".
Я уж не знаю заговор или еще что, но в хреново реализованном компиляторе виноват явно не C++.

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

Оно короче uint32_t. И уж тем более короче uint_fast32_t. Но все верно, главное то не что короче, а что абы как, лишь бы не как в плюсах. И все верно, на предложение "а давайте unsigned сделаем короче", тоже выясняется что короче не надо. При том что uint/ulong вполне популярные сокращения.

Добавлено через 38 минут

Сообщение от Renji в каждый полиморфный объект по копии таблицы виртуальных функций

UPD А, пардон, он не в объект, а в SRAM копирует. Но да не суть - память используется не рационально, чинить это никто не собирается.

0

Сообщение от Renji Но да не суть, варнинг "format string is not a string literal (potentially insecure)" все равно вылетает.

Все еще проблемы с чтением?
Это предупреждение, что пихать в качестве формата не-константную строку - плохая идея. Мало ли какой формат туда засунут, сколько переменных захотят записать или прочитать. Потому что некоторые личности любят писать printf( str ); вместо printf( "%s", str ); или простого puts( str );
Ну и, раз уж у нас продолжение "дня откровений", со scanf тоже надо быть осторожным и указывать максимально допустимое количество символов: не scanf("%s", str); а scanf("%10s", str);. Увы, указать длину из переменной нельзя. Кстати, это единственное известное мне место, где применение scanf_s было бы оправдано... не считая того, что логичнее было бы добавить флажок в сам scanf и не заниматься нецензурными извращениями с *_s функциями. Как бы то ни было, необходимость в подобном возникает крайне редко, да и fgets никто не отменял. Туда же использование snprintf вместо sprintf.
Естественно, обсуждение функций форматного ввода-вывода не имеет отношения к теме и была приведена просто для общего развития.

Сообщение от Renji Теперь применяем ту же самую логику к вопросу "назвать функцию OpenPipe или popen"

Снова не понял что вы хотите доказать. Что popen удобнее OpenPipe'а? Так это и так видно. Что popen путается с open, fopen и т.п.? Это не так.

Сообщение от Renji Это называется проблемой "язык или диалект".

Это зависит от определения. Я исходил из разделения языков на семейства. Все-таки разные ассемблеры называть разными языками не имеет смысла, не настолько они отличаются, даже под разные архитектуры. Вот Си, Паскаль, Бейсик, С++, Ява, Питон, Фортран - это разные языки. У них отличается синтаксис, библиотеки, да и вообще философия программирования. И у каждого из них могут быть диалекты. Скажем, QuickBasic и VisualBasic отличаются существенно, так что пожалуй находятся как раз на границе диалект-язык.

Сообщение от Renji C++ понимает Си прекрасно, Си понимает C++ с грехом пополам. Так что, извините, диалекты.

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

Сообщение от Renji Я уж не знаю заговор или еще что, но в хреново реализованном компиляторе виноват явно не C++.

Я не говорил про какой-то конкретный компилятор. Я говорил про плюсовый подход в целом. И повторюсь, что "в целом" на плюсах возможно писать более оптимальный код, чем на Си. Вот только крайне немногие на такое способны и приходится здорово бороться с языком, глубоко понимать во что разворачивается та или иная конструкция. В Си это получается само собой, он почти не скрывает реализации.
Например, далеко не каждому плюсовику очевидно, что в контроллерах не надо пользоваться new/delete (равно как и malloc/free) без крайней необходимости. Не очевидно, что использование наследования также нежелательно (а вот сами объекты вполне полезны). Не очевидно, что глобальный объект, который дергают все кому не лень, предпочтительнее постоянного создания локальных. Повторяю, это относится не к avr-g++, это сам подход С++.

Сообщение от Renji Баг висел семь лет, закрыт без исправления. С итоговым комментарием "как в g++ сделать можно, но сложно...

Задумайтесь над этим. Почему считают, что в g++ сложно исправить какой-либо баг. Да потому что сам код компилятора уже здорово накрученный. Он намного сложнее обычного gcc, причем во многом из-за того, что сам язык сложнее. Его сложнее портировать под другую архитектуру.

0

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

Ага, например, туда могут засунуть "формат" double*. И компилятор это схрумкает, только варнингом погрозит.
Это предупреждение именно об опечатке. Что нельзя пихать в качестве формата неконстантную строку нельзя все и так знают. Но вот палец случайно стукнул по "s" не один раз, а два и одна функция превратилась в другую. И аргумент уехал куда-то не туда. А пилить предупреждения об опечатках имеет смысл только если кто-то эти опечатки регулярно делает.

Сообщение от COKPOWEHEU Снова не понял что вы хотите доказать. Что popen удобнее OpenPipe'а? Так это и так видно.

Что popen-ы массово отправляют на свалку истории. И тут уж либо дураки - кучка ретроградов держащихся за сокращения, либо дураки все остальные. Вы со своими "уровнями абстракции" пытаетесь съехать на "от длинных имен отказываются там, где на Си велосипедят ООП"? Ну вот я вам и указываю что даже для пайпов сейчас вводят длинные имена. Хотя, к абстракциям ООП они никакого отношения не имеют.

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

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

Подсчет факториала в Си и C++ идентичен до последней буковки. Но вы почему-то не считаете Си и C++ диалектами одного языка. В разных ассемблерах даже синтаксис команд одного и того же процессора не совпадает. Но это диалекты. Не находите, что в этой логике что-то не так?

Сообщение от COKPOWEHEU Например, далеко не каждому плюсовику очевидно, что в контроллерах не надо пользоваться new/delete (равно как и malloc/free) без крайней необходимости. Не очевидно, что использование наследования также нежелательно (а вот сами объекты вполне полезны). Не очевидно, что глобальный объект, который дергают все кому не лень, предпочтительнее постоянного создания локальных.

Только не new/delete, а std::vector. И не по крайней необходимости, а потому что компилятор на столько уныл, что Буст с static_vector не заводится. Память и без контроллеров стараются вручную не тамагочить. А про глобальный объект постоянно затираемый локальными данными и правда не очевидно. Вы там стек чтоль пытаетесь экономить, за счет выноса объекта в глобальную память? Ну так про "не храни большие объекты в стеке" плюсовикам опять же прекрасно известно.

0

Сообщение от Renji А пилить предупреждения об опечатках имеет смысл только если кто-то эти опечатки регулярно делает.

Все знают, что пользоваться Си надо с осторожностью, там почти нет защиты от дурака. Расплата за простоту и эффективность. Но самые известные ошибки, которые компилятор может отловить, он отловит.
Как бы то ни было, альтернативы стандартному выводу практически нет.
Но какое отношение этот вопрос имеет к теме?
Разные варианты *printf легко перепутать? Очевидно, нет. Использование похожих имен для похожих (но не одинаковых!) целей не имеет смысла? Тоже очевидно нет.

Сообщение от Renji Вы со своими "уровнями абстракции" пытаетесь съехать на "от длинных имен отказываются там, где на Си велосипедят ООП"?

Как раз наоборот, ООП-подобный подход как раз провоцирует длинные имена. Что мы, собственно, по тому же С++ и видим.

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

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

Сообщение от Renji Подсчет факториала в Си и C++ идентичен до последней буковки.

Подсчет факториала на ассемблере и в ассемблерной вставке идентичен до последней буковки! Давайте считать все языки диалектами ассемблера.
Если уж С++ является наследником Си и поддерживает с ним такую совместимость, что почти любой Си-шный код может быть скомпилирован плюсами - это значит именно то, с чего началось: С++ - наследник Си, старающийся поддерживать совместимость. На каком основании вы называете Си придатком С++ никто не знает. Как и то, какое отношение все это имеет к исходной теме, но от вас я другого уже и не жду.

Сообщение от Renji Только не new/delete, а std::vector.

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

Сообщение от Renji А про глобальный объект постоянно затираемый локальными данными и правда не очевидно.

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

Сообщение от Renji Вы там стек чтоль пытаетесь экономить, за счет выноса объекта в глобальную память?

Стек, скорость и читаемость. Все это у глобального объекта лучше. Потенциально такой подход может приводить к ошибкам не-единственной ответственности, но на практике такое встречается крайне редко и решается другими способами.

Сообщение от Renji Ну так про "не храни большие объекты в стеке" плюсовикам опять же прекрасно известно.

Ой ли? Плюсовики как раз не привыкли считать такты и байты. Для них единица кода - объект. Универсальности кода и понятности (для них самих) они назначают более высокий приоритет, чем Си-шники, в сравнении и эффективностью, предсказуемостью и понятностью для других. Согласитесь, плюсовый код, напичканный шаблонами, лямбдами и объектами все же менее очевиден для человека, слабо знакомого с языком, чем Си-шный. Повторюсь: при грамотном использовании объекты существенно повышают читаемость кода и страховку от ошибок. А шаблоны теоретически позволяют добиться той же скорости, что и макросы при (возможно) лучшей читаемости. Хотя бы потому что макросы в Си уж слишком дубовые. Вот только я еще не видел качественного кода под контроллеры на плюсах. На обычном Си видел. На ассемблере видел.
Кстати, было бы интересно узнать ваше мнение о реализации следующих стандартных вещей в контроллерах. Пусть будут AVR, раз уж с них начали - просто для определенности.
1. Порты (три регистра DDRx, PORTx, PINx плюс номер ножки). Что порт не стоит хардкодить - очевидно, но какую абстракцию к нему применить?
1а. Стиль Ардуино: присвоить ножкам порядковые номера (числа), и запилить функции, принимающие эти номера и декодирующие их в те самые регистры. Для пользователя все красиво: порт задается единственным числом, передается в любые функции и т.п.
1б. ООП: объявить каждую ножку классом с полями и методами.
1в. Примитивные макросы: на каждую ножку задается 4 макроса, по одному на регистр.
1г. Продвинутые макросы: на каждую ножку задается один макрос с несколькими "полями", которые обрабатываются другими макросами.
1д. Шаблоны: вот тут подробностей дать не могу, поскольку только видел мельком такой вариант, но не разобрался в нем
1е. Ну и до кучи - свой вариант. Вдруг знаете более красивый способ, чем перечисленные
.
2. Периферия. Например, в контроллере есть два SPI (у каждого свои выводы, скорость, полярность и т.п.)
2а. Стиль Ардуино: по объекту на каждый порт
2б. Макросы: порт кодируется только номером, который макроподстановкой добавляется к именам регистров.
2в. Свой вариант.
.
3. Внешняя периферия. Например, на SPI1 висит дисплей
3а. Ардуино: Объявим объект дисплея, который будет хранить объект SPI-порта
3б. ООП: сам SPI кодируется как-то покороче, вроде адреса регистров SPI или вообще макросом. Но сам при этом завернут в объект.
3в. Процедурный подход: выделенного объекта нет, зато есть кучка функций, читающих номер порта из макроса или откуда-то еще.
3г. Ну как обычно.

0

Сообщение от COKPOWEHEU Все знают, что пользоваться Си надо с осторожностью, там почти нет защиты от дурака. Расплата за простоту и эффективность. Но самые известные ошибки, которые компилятор может отловить, он отловит. Как бы то ни было, альтернативы стандартному выводу практически нет.

Расплата за то что const придумали плюсовики в 1981 году, а сишники стащили только в 1989 году. К тому времени уже давно устоялись сигнатуры, которые про const ничего не слышали. И, подозреваю, устоялась традиция всем рассказывать что контроль типов в Си не нужен. Так что менять чего то было сложно и стыдно. А варнинг он вроде как и не часть языка ("мы не прогнулись под плюсы!"), и проверки как в плюсах делает.

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

Сообщение от COKPOWEHEU Как раз наоборот, ООП-подобный подход как раз провоцирует длинные имена. Что мы, собственно, по тому же С++ и видим.

Видим что плюсовый file.read(buf,size), короче сишного fread(buf,1,size,file). Причем, без каких либо рисков перепутать откуда это read происходит. Вот как раз в ООП методах короткие имена прекрасно себя чувствуют. Потому что живут в отдельном неймспейсе, где ни с чем не пересекаются.

Сообщение от COKPOWEHEU Внешне - отличаются. Но по подходу - нет.

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

Возвращаясь к плюсам.
Если горожанин (C++) понимает почти все фразы деревенского (C), а наоборот нет, мы несомненно можем утверждать что городской диалект развился от деревенского. Но это не повод утверждать что в деревне и городе говорят на разных языках. И уж тем более не повод объяснять заскоки деревенских жителей тем, что их язык лучше городского.

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

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

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

Такое, что оно нужно либо для динамических массивов, либо для деревьев и прочих графов. И только для массивов отказ от malloc не будет выглядеть как "А я сделаю свой malloc! С блекджеком и шлюхами!".

По AVR - у нас оптимизатор кода работает или все как всегда? Если работает, то порты делаются глобальными объектами, наследующими абстрактный интерфейс Port. И port0.put(123) генерирует код идентичный PORTA|=123. Иначе пишем багреппорт "зачем компилятор делает виртуальный вызов, если тип объекта известен на стадии компиляции?". Примерно тоже с прочей периферией.

Разумеется, если вы будете делать somePort.put(123), фокус не сработает. Но я не особо представляю как вы собираетесь уйти от полиморфизма, если функция должна писать в произвольный порт. Свитч по portID это те же яйца, профиль сбоку.

0

Сообщение от Renji Расплата за то что const придумали плюсовики в 1981 году

const-то тут чем поможет?!

Сообщение от Renji устоялась традиция всем рассказывать что контроль типов в Си не нужен.

Почему это не нужен? Еще как нужен и используется.

Сообщение от Renji Что до возможности перепутать разные варианты printf, ну если программу робот набирает, то да, перепутать их сложно. Люди же никогда не делающие опечаток, существа по большей части мифологические.

Я не знаю как вам удается перепутать разные *ptintf. Может, стоит хоть немного читать написанное вами же?! Ведь разница между вариантами даже при простом чтении бросается в глаза, не говоря о ругани компилятора.

Сообщение от Renji Видим что плюсовый file.read(buf,size), короче сишного fread(buf,1,size,file).

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

Сообщение от Renji То что ассемблер от одного компилятора будет понятен другому компилятору никто, никому не обещал.

Это говорит только о том, что языки/диалекты отличаются и не более того. Могу повторить, что ассемблеры слишком близки по подходу, чтобы считать совсем разными языками. Если вам будет проще, можете обозвать языковой группой.
Ну а С++ существенно отличается от Си, они развиваются каждый сам по себе, по своим принципам. Ну да, плюсовики старательно тащат совместимость с Си, это их дело. Забавно, что сами же при этом утверждают, что писать на С++ в стиле Си - плохая идея. Как бы то ни было, это не повод смешивать языки.

Сообщение от Renji Такое, что оно нужно либо для динамических массивов, либо для деревьев и прочих графов.

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

Сообщение от Renji Если работает, то порты делаются глобальными объектами, наследующими абстрактный интерфейс Port.

Ваш вариант не решает ни одной проблемы. Это просто ООП ради ООП, которое только добавляет сложности.
Я не просто так говорил об отдельных выводах порта, потому что это типичная задача переносимости: куда повесить кнопку, светодиод, семисегментный индикатор, чтобы при переносе библиотеки, которая их использует, не пришлось бегать по всему проекту с автозаменой.

Сообщение от Renji Свитч по portID это те же яйца, профиль сбоку.

На самом деле в Ардуино все еще хуже: вместо одной ассемблерной команды на обращение к регистру используется сначала декодирование индекса в PORTx+DDRx+PINx+y, потом битовый сдвиг (1<<y) и только потом битовая операция.

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

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

0

Сообщение от COKPOWEHEU const-то тут чем поможет?!

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

И вот не надо сказок про наличие контроля типов в Си.

Сообщение от COKPOWEHEU Ну, что длиннее - видим. Что скрывается конкретный способ вывода - видим. Поздравляю, вы привели аргумент против себя.

У вас 19 буковок длиннее 22? Видимо, в Си какая-то альтернативная арифметика.

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

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

Сообщение от COKPOWEHEU то есть никакого. Ни деревья, ни динамические массивы не нужны в контроллерах практически никогда.

Значит на контроллере и плюсовики malloc использовать не будут.
По кнопкам и светодиодам - делайте ссылки и не морочьте голову. Port&button=port0;. Опять же, если оптимизатор кода не отвалился, ничего там с производительностью не сделается.
По полиморфизму - делаем библиотечную функцию "отправь в порт строку". Нет, если у вас висящее на этом порту устройство принимает только однобайтовые команды, тогда конечно не стоит весь этот огород городить. Но так возможность лепить PORTA|=123 у вас никто и не отбирает.

0

Сообщение от Renji И вот не надо сказок про наличие контроля типов в Си.

Приведенный вами код не компилируем в С из-за несоответствия типов. Поэтому не ясно, о каких "сказках" вы ведете речь. Строгость контроля типов в С (кроме нескольких деталей, типа преобразований из void *) полностью идентична строгости контроля типов в С++.

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

В стандарте нет ни варнингов, ни ошибок. Есть только диагностические сообщения, требуемые стандартом. А оформлено ли диагностическое сообщение, требуемое стандартом, в виде варнинга или как-то еще - значения не имеет.

Приведенный вами код некорректен в С и требует диагностического сообщения. То есть он некомпилируем.

0

Сообщение от TheCalligrapher Приведенный вами код не компилируем в С из-за несоответствия типов.

rextester.com этот код отлично скушал, хотя и матюкнулся "Invalid memory reference (SIGSEGV)". gcc тоже код отлично скушал. Уж не знаю где он не компилируем, но мне такого места обнаружить не удалось.

0

Сообщение от Renji rextester.com этот код отлично скушал, хотя и матюкнулся "Invalid memory reference (SIGSEGV)". gcc тоже код отлично скушал. Уж не знаю где он не компилируем, но мне такого места обнаружить не удалось.

Это проблемы вашего rextester-а. К языку С они никакого отношения не имеют.

Пробуем: http://coliru.stacked-crooked.... 77a1d1aa6d

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

Однако стоит указать "Show compiler warnings" в rextester и мы получим те же диагностические сообщения. Код некомпилируем.

1

Сообщение от Renji rextester.com этот код отлично скушал

А теперь смотрим набор флагов с которыми Вы производили компиляцию.
Добавляем -pedantic-errors - не компилируется

0

Сообщение от TheCalligrapher Пробуем: http://coliru.stacked-crooked.... 77a1d1aa6d

bash: line 7: 26623 Segmentation fault (core dumped) ./a.out
То есть, исполняемый файл успешно сгенерировался, запустился и грохнулся. Весьма странная "не компилируемость".

Сообщение от Croessmah Добавляем -pedantic-errors - не компилируется

Ок, принято, этот ужас и правда можно отключить. Еще бы этот ключ по умолчанию был...

0

Сообщение от Renji Еще бы этот ключ по умолчанию был...

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

0

Сообщение от Renji То есть, исполняемый файл успешно сгенерировался, запустился и грохнулся. Весьма странная "не компилируемость".

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

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

0

Сообщение от TheCalligrapher "Компилируемость" - это когда процесс компиляции проходит без выдачи стандартных диагностических сообщений.

Извините, а если clang с ключом -Weverything матерится на полиморфные классы с инлайн-онли функциями, это компилируемость или нет ("no out-of-line virtual method definitions; its vtable will be emitted in every translation unit")? А если gcc с ключом "-Wnon-virtual-dtor" матерится на отсутствие виртуального деструктора там где delete запрещен, но на багтрекере отвечают "меняй на -Wdelete-non-virtual-dtor и не морочь голову" это компилируемость или нет?
Делать варнинги мерилом компилируемости это весьма странная идея.

0

Сообщение от Renji Извините, а если clang с ключом -Weverything матерится на полиморфные классы с инлайн-онли функциями, это компилируемость или нет Делать варнинги мерилом компилируемости это весьма странная идея.

Я специально подчеркиваю, что речь идет именно и только о стандартных диагностических сообщениях, т.е. сообщениях, требуемых стандартом языка. Оформлено ли такое сообщение как "варнинг" или как "ошибка" роли не играет. В С и С++ нет такого деления вообще.

А те сообщения, которые не указывают на нарушения правил языка, т.е. сообщения, которые компилятор добавляет "от себя" (как в вашем примере), являются классическими "просто варнингами", которые к теме компилируемости не имеют никакого отношения.

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

1

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

По стандарту и на int x[getchar()]; в C++ коде диагностическое сообщение должно выскакивать. Только вот, gcc промолчит даже при ключе -Wall (в режиме pedantic ругнется, да). Это не компилируемость или все же расширение компилятора, на которое он при определенных настройках может ругнуться?

0

Сообщение от Renji По стандарту и на int x[getchar()]; в C++ коде диагностическое сообщение должно выскакивать.

Совершенно верно.

Сообщение от Renji Только вот, gcc промолчит даже при ключе -Wall (в режиме pedantic ругнется, да).

Это - внутренние особенности gcc.

Сообщение от Renji Это не компилируемость или все же расширение компилятора, на которое он при определенных настройках может ругнуться?

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

Но к языкам С или С++ это уже не будет иметь никакого отношения. Я же веду речь именно о корректности/компилируемости кода в рамках языков С или С++. В своем исходном сообщении о якобы отсутствующем контроле типов в языке С вы тоже вели речь о языке С.

0