Обратите внимание в какой теме и в каком разделе мы все это пишем ...
C-исходник в подавляющем числом компиляторов под МК не поддерживает С99, поэтому мы не можем где ни попади объявлять локальные переменные.
И, честно говоря, не вижу смысла строчить в С или С99, когда есть плюсы. Но это - по-ходу уже другая тема )))

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


Да, это именно оно ))
По сути, лишь для этого я и использую слово struct, так сразу видно в коде, о чем идет речь.
А все остальные сущности - class. Даже для примитивных, т. е. не имеющих своих методов (но в будущем, возможно, будут).


Автоматизация "мартышкиного" труда еще не отменяет самого факт такого труда )))
К тому же даже в данный момент далеко не все среды (тоже обратите на тему и раздел где мы сидим) поддерживают такие вещи по ВСЕМУ проекту.
Речь в данном случае не про внешние редакторы, а целиком про среды проектирования (Keil, Eclipse, Crossworks и др).

В Eclipse это Alt + Shift + R с древних времен и да ПО ВСЕМУ проекту...

так то я ТС ))) и тема не про стиль кода, а про библиотеки для стм32 ))

в Eclipse этo Alt+Shift+R. На базе эклипса много сред (кокос, CCS, NIOS-IDE). Вообще эклипс - рулит. Остальные среды .... но это уже новый холивар )))
Да даже в IAR-e, со своим редактором, застрявшим в 90-х годах, можно сделать поиск с заменой в пару кликов. Ни какого мартышкиного труда ))

ps что ещё вкусного в эклипсе - автоматическое форматирование кода. берёшь чужой код... там фигурные скобки не так как у меня стоят, отступы не те, пробелы не так, выравнивание schitch/case/break по другому. жамкаешь ctrl+shift+F - весь файл перефарматируется в мой стиль (только естественно стиль должен быть настроен и/или подключен. я один раз стиль настроил и всегда его подключаю, во всех эклипсонаследовательных ИДЭ)

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



Под мартышкиным трудом понимаю переделывание своего кода, а не чужого.

А ни разу не сталкивались, когда при очередной модификации кода (через 10*N месяцев) в 16 бит переменной (поле структуры) нечаянно пытались освоить биты >16?

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

Кроме шуток, существует весьма полезная вещь - sizeof, или для более продвинутых: (1 << ( sizeof(...)*8 ) ) - 1

нет, ни разу. никогда к битам не обращяюсь напрямую типа a |= (1 << 24); Только через дефайны. a |= STATE_A;
хидере пишу что-то типа такого

определяя новый дефайн всегда помню(проверяю) про размерность переменной. это раз....

и второй подход - это битовые поля. например так
при таком написании вообще пофиг в каком месте биты стоят.... printCheck2 - 4-ый или 8-ой. при таком подходе... не возможно ошибиться и вылезти за размер 16 бит.

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

А, если еще компилятор поддерживает безымянные объединения, то получается полный феньшуй:



nodeId при присвоении проверяется на граничные значения внутри соотв. метода соотв. класса, т.е. в одном месте, а не размазаны по всему коду ...
functionCode вообще может принимать лишь фиксированные значения:



вот так используется:




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

Счастливчик.
Только увы, биты можно освоить и простым сложением величин... А потом долго не втыкать, почему же с = a+b не работает...Или с = a - b, если b > a...
А все было бы гораздо прозрачней, если usC = iA - iB

Еще интересней случаи, когда
Data = N;
вместо
*Data = N;

а с
*pData = N;
сделать ошибку куда сложней.

© "Ежики кололись, но все равно ели кактус"



Только что попробовал такую конструкцию:


Тут же получил от компилятора (keil) по носу:

error: #513: a value of type "int" cannot be assigned to an entity of type "int *"

Но это проглатывает:

Хотя я никогда так не пишу, а использую вместо нуля эту штуку (ее нет в С++):


Тогда при попытке присвоить обычной переменной эту NULL:

получим от компилятор опять щелчок по носу:
error: #513: a value of type "void *" cannot be assigned to an entity of type "int"





зы. Честно, прям дикости какие-то вы тут пишите

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

Хотя раньше указатели я именовал, но не шифровками типа - "p" или "ptr", а с полностью - с припиской "Pointer" в конце названия.
В данный момент указателей практически нет, кроме редких случаем в низкоуровневых драйверах да и то крайне редко, всегда стараюсь избегать указатели в коде.
Это несложно, т. к. пишу под плюсами, поэтому использую ссылки, а не указатели.
Так безопаснее да и код читается лучше, т.к. нет "->".

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

+100
какие биты у величин? Биты - это флаги. Вам нужно проверить 3, 6 и 18 флаг по "И", проверяйте if(a & ((1<<3) | (1<<6) | (1<<18)){}
по "ИЛИ" - проверяйте if(a | ((1<<3) | (1<<6) | (1<<18)){} Грамозко, непонятно, требует комента? сделайте дефайн
#define IS_PRESENT_ALL ((1<<3) | (1<<6) | (1<<18))
if(a | IS_PRESENT_ALL){}
а также
a |= (1<<7);//выставить 7-ой бит
a &= ~(1<<19);//сбросить 19-ый бит
Какое у битов сложение? Если нужно переменную в 2 и более бита - используйте битовые поля, обращайтесь к ним как к простым переменным.

Там "из коробки" специально для этого есть nullptr.

Forger, juvf, вы сильно зацикливаетесь на своем коде. Я рад за вас, что вы сразу пишете идеальный код.
Не у всех так получается. А люди еще бывает работают в команде. А еще бывает, люди пишут код, который потом будут массово пользовать другие (как те же библиотеки stm32).

Это относится лишь к компиляторам, которые поддерживают C++11.

В ARM-компиляторе (Keil) есть частичная поддержка C++11, nullptr в его редакторе подкрашивается, это удобно ))
"Из коробки" не заработает, нужно обязательно включать опцию компилятора "--cpp11".

Но обязательно возьму на вооружение! Спасибо


Неправда - у всех это получается, ничего тут сложного нет.
А дело, возможно, в другом - не все хотят учится и переучиваться


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


Какое странное оправдание ..

.

Ладно, последняя попытка
Не все пишут на С++ и С++11
Те же библиотеки stm32 написаны на С. А ему пофиг на

Это тут ни при чем.
Я использую C-библиотеки stm32 в C++. Неразрешимых проблем не было.


Так смените свой компилятор на нормальный, которому это не пофиг!
Или покопайтесь в настройках компилятора, чтобы он ругался на такие вещи хотя бы warning-ми.
Честно слово, как дети малые ...

зы. Скажите, при сборке всего проекта вы сразу добиваетесь, чтобы не было ни одного warning-а или откладываете это на потом?

Я не зациклен. Я предложил свой стаил. Он не единственно верный. Гугл стайл мне не понравился... тип переменной в имя сувать - тоже мне не по вкусу. раньше вроде так писали int *pName; Сечас..... посмотрите другие стайлы.... мой стаил гавно? посмотрите гугл, Qt,.... посмотрите исходники Linux - это пуре СИ.
иаровски СИШНЫЙ компилятр не скомпилировал такое, ругнулся

gcc тоже такое не проглотит. Не нужно нормальный компилятор. мне кажется не один компилятор такое не проглотит. Или я ошибаюсь? Какой компиллер такое проглитит?

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

Отцы, вам самим не смешно такие примеры приводить?

Позвольте зацитировать первооснователей (K&R):
int х = 1, у = 2, z[10];
int *ip; /* ip - указатель на int */
ip = &x; /* теперь ip указывает на х */
y = *ip; /* у теперь равен 1 */
*ip =0; /* х теперь равен 0 */

выделено мной.

не в тему сказал. войди в тему, начни читать с 109 поста. вместе посмеёмся.

Такую "кашу" из букв даже при желании сочинить трудно, определенно нужен "талант"!

Из #109

Пожалуй, всплакну. Не прёт меня логические операции арифметическими реализовывать.



Никакой отсебятины. Brian Kernighan and Dennis Ritchie. Pure. (; Скриншот, надеюсь, не заставите представлять…

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

С таким же успехом можно сравнивать паровую машину с современной )))

Он - старенький; Риччи 6 лет как помер.
Так ведь с тех "дремучих времён" текст в книжке можно ж было и поправить. Не раз.

Нормально на "Электронике-60" было, желание надо было просто иметь…

"… да и программы тогда были очень простые в сравнении с современными..." ой простыыыыми, что целый Unix накатали (;

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

нормальная каша. на пальцах разжёвано что такое адрес и указатель. всё понятно. Вот только там нет рекомендаций про стиль кода. А для учебника Си, для 5 строк кода, особенно для раздела указателей (и ссылок в с++), наверно даже нужно в имя переменной втолкнуть тип.

IAR

Как заставить ругаться на все неправильные варианты?



Таких

бывает много. На остальные всегда смотрится.

Шаг за шагом, по каждому warning-у, а можно ещё и remarks

Workspace -> Options -> C/C++ Compiler -> Diagnostics -> птички "Enable remarks", "Treat all warnings as errors"
Workspace -> Options -> Linker -> то ж самое
меню Tools -> Options -> Messages… -> Show build messages -> All

Во-первых, не писать такой код, где фигурируют магические числа (кроме числа ноль).
Заменяйте ваши ноунейм указатели указателями на структуры, дав им логичные имена.
Используйте встроенный оператор sizeof, чтобы уйти от магических цифр.
Учтите, что sizeof указателя будет давать размер указателя, но не данных, куда он указывает. Поэтому в sizeof() ставьте тип данных, а не сам объект.
Используйте приведение типов, это вносит хотя бы дополнительную полезную информацию в и без того куцый и корявый код ))
Смело используйте typedef, создавая свои осмысленные типы. Это приучает к порядку в коде.
Указатели используйте как можно реже и старайтесь ограничивать область их видимости и применения хотя бы в пределах одного файла.
Не нужно раньше времени заморачиваться на экономии ОЗУ или FLASH, в современных МК это не проблема.

В вашем примере я бы отказался от memcpy и использовал копирование в самописном цикле. Это будет явно и избавит от детских ошибок.

Если пишите под плюсами, пользуйтесь ссылками, а указателей быть не должно.

За глобальные указатели - расстрел на месте!


На них вообще не приходится смотреть, если их вообще нет, т.е. "Warnings: 0". По-моему, это проще ))

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

Короче, мой вам совет - читайте книжки опытных программеров (здесь они озвучивались), двигайтесь вперед и все получится, БЕЗ КОСТЫЛЕЙ

И чем эти советы помогут в этом?

не использовать memcpy?


Если честно, то сымый лучший код, который я видел - это исходники WINCE. прочее и рядом не стояло. особенно озвучивамый тут linux.

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

А в чем memcpy непонятный?

я за то, что

, снабженный комментарием, ЗАЧЕМ мы это делаем - самый понтяный вариант.

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

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

что за бред? а если WorkData, InData вы назавете pWorkData, pInData - это сильно поможет?

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

сплошь и рядом указатели. Ссылка должна быть там, где она должна быть, а указатель - где указатель. Eсли с++, то там ооп. а ооп - это сплошь и рядом указатели... всякие createWindow(), getSender()... паттерны - тоже указатели. обращение к регистрам перефирии процессора - опять указатели. Куда без них?

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


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

Вы противоречите самому себе


Скорее всего, и имелось ввиду использовать вместо memcpy присвоение неких структур через указатели на них.
вот, только массивы в структурах могут быть открытими... (в С)

Назад на пальму к корням в ассмы!!! Шутка…

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

P.S. ИМХО, логичные и информативные названия переменных ничуть не хуже венгерской нотации работают, еще и код более "читабельный" получается.

Подгружать весь проект вместо того, чтобы в блокноте бегло глянуть на кусок кода? (когда тип определен где-то в дебрях кучи *.h)

И да, тут уже был ответ:

не куда не назад. пока единственный путь.

2Alechek Где я противоречу? где я в имеми переменой в своем примере вставил хоть что-то от типа переменной?

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

void f(LPSTREADMATA pInData) - встретив такую запись не понятно что передается? вызывается ли копирющий контруктор, делается ли копия переменной/структуры типа LPSTREADMATA. вам необходимо в имя переменной воткнуть pInData, иначе не видно, что передается указатель. вам, чтоб не запутаться, нужны наверно и в имя типа вставка LPSTREADMATA, и в имя переменной вставка pInData.

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

Используемый нынче у меня редактор умеет более-менее успешно вытягивать и без проектов такие штуки из "дебрей кучи *.h"

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



Кстати да, специальные типы с указателями это зло. Как-то с libpng возился, a там любители typedefов наплодили и указателей, и указателей на указатели - жесть...

оффтоп по поводу переделки тайпдефов.... тут говнолидер - это Texas Instuments.... со своею TI-RTOS и SPL.

их код создание таска

хорошо, что идэ у них на эклипсе.... что такое Void? ctrl+ЛКМ улетаем в какой-то хидер
ещё раз ctrl+ЛКМ, ултетаем в
ну да ладно.... Void интуитивно понятно что это void. А вот что такое UArg arg0? ctrl+ЛКМ (ещё раз спсибо эклипсу, чтоб я без него делал?) улетаем в хидер

далее ctrl+ЛКМ - полёт по хидерам...
-
uintptr_t вроде всё понятно.... u - значит unsigned, int - это int, ptr - т.е. pointer, т.е. указатель, _t - тип. делаем контрольный ctrl+ЛКМ


NO COMMENT!!!

а вы говорите заглянул по быстрому в блокнот ))))

Оо! Зря я наехал на libpng

Вам, чтобы видеть лучше тип, надо *, но при этом вы против некоторго символа в другом месте.
Хотя и то и другое способствует повышению скорости писания кода одновременно с уменьшеним вероятности ошибки.


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



вот и я о том же.
При:

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

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


Дык, они открыты по-умолчанию и в С++ ))

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

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

Я не говорю по какие-то исключения - бывает всякое, я про нормальную работу.

мне не видно.... пусть я слеп. Но вам видно?! УКАЗАТЕЛИ!? Одну ногу отстрелили! ))) я же раскрыл все тайпдефы. это не указатели, это unsigned int

Мне видно, что это указатель c конкретным размером в 32 бит:


Кстати, такое есть и в WINDOWS:

Отличный пример того, как буковки в префиксах имён могут быть неверно истолкованы.
(Но вообще-то uintptr_t - это стандартный тип (из stdint.h), и его название означает "беззнаковое целое, размер которого достаточен для хранения указателя").


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

Выстрел!!! Вторую ногу отстрелили. в си/с++ нет типа uintptr_t, где-то должно быть определение... в каком-нить хидере. И оно у TI есть

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

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

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

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

Каждый выбирает свои грабли.

Скажем, имеем указатель на класс.
Компилятор не позволит присвоить ему абы что и не позволит присвоить сам указатель чему-то левому.
Попытка неправильного разыменования полей такого класса тоже невозможна - не получится использовать "." вместо "->"...
Отсюда простой вопрос: зачем в имени указателя на класс указывать тот факт, что он указатель?
Приведите пример, где без этого никак не обойтись.

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

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


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

С этим трудно не солгаситься