[Variant99 7]

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

/**
 * @brief Класс "Кэш I2C устройства"
 */
class I2C_Cache{
public:
	/**
	 * @brief Конструктор класса.
	 * @param bussAddress - адрес устройства на шине.
	 */
	I2C_Cache(u8 bussAddress)
	{
		this->bussAddress = bussAddress;
	}

	/**
	 * @brief Структура регистров устройства
	 */
	struct Regs{
		u8 reg1;
		u8 reg2;
		u8 regN;
	}registers;

	/**
	 * @brief Чтение регистра.
	 * @param reg - регистр
	 * @return Содержимое регистра
	 */
	static u8 getReg(const u8 &reg)
	{
		return reg;
	}

	/**
	 * @brief Обновление кэша устройства.
	 * @param device - ссылка на объект устройства
	 */
	static void Update(I2C_Cache &device)
	{
		/* Тут чтение регистров из микросхемы в кэш */
		this->registers.reg1 = Ш2С_Read(bussAddress);
		//... и так далее

	}

private:
	u8 bussAddress;		// адрес устройства на шине
};

====================================
  	I2C_Cache device1(0x71);		// создание кэша устройства
	I2C_Cache::Update(device1);		// обновление кэша устройства

	u8 val;
	val = I2C_Cache::getReg(device1.registers.reg1);	// чтение регистра из кэша

 

[Forger 17]

Variant99

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

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

(извиняйте за офф, если эта тема не интересна, закроем)

 

[one_eight_seven 3]

49 minutes ago, Forger said:

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

Это же зачатки документации для Doxygen.

[Variant99 7]

Да, это комменты в стиле Doxygen, написаны для пояснения автору вопроса. Многострочные с @brief, @param, @return генерируются в коде автоматически средой разработки, потом добавляю только описание. Да, я использую Doxygen, это классная штука для документирования кода в целом. Не комментирования, а документирования. Doxygen оформление выпиливать не стоит, по нему собирается HTML документация. Всё, что в тексте начинается вот так: /** и заканчивается */  это Doxygen. У него свой синтаксис внутри этих блоков. Между прочим, такие Doxygen-страницы вы смотрите например на сайте ARM. Думаете, они там вручную писали это всё? Нет, это работа встроенной в код "бестолковой литературы", которую поленились вырезать :))) 

А разбираться в коде вообще без документации и без комментов, да еще когда названия тупые и сокращенные до 4 букв, это ваще нивкайф.

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

Изменено 4 декабря, 2022 пользователем Variant99
добавил пример документации

[Arlleex 131]

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

[Variant99 7]

Ну, это личные предпочтения, тут никто никого не заставляет 🙂 

Хорошо, что вы помните, что вчера написали в своём коде. А откройте его через полгодика. Вспомните ли, что такое например  mux[4]; Вот нам со стороны ну ваще непонять, че это за хреновинка приляпана, че она там содержит. Или isValid - это валидность чего? ХЗ. Мы тут потратили 2 страницы на объяснения, чтобы понять, что ж вы там пытаетесь написать то. 

[Forger 17]

4 hours ago, Variant99 said:

Да, я использую Doxygen, это классная штука для документирования кода в целом.

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

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

Также по моему доксиген хорош для жирных библиотек неких функций, какая нить gui на голых сях.

Кстати, заметил, что код на плюсах требует гораздо меньше комментариев 😉

 

4 hours ago, Variant99 said:

написаны для пояснения автору вопроса.

У вас названия типов, методов, параметров уже сделаны хорошо читаемыми. Остальное - масло масляное.

 

10 minutes ago, Variant99 said:

Вспомните ли, что такое например  mux[4]; Вот нам со стороны ну ваще непонять, че это за хреновинка приляпана, че она там содержит.

Для этого этому "mux" следует дать нормальное имя или разместить его внутри полей класса, который имеет имя и осмысленный функционал. Или скрыть этот mux в очень узкой области видимости (внутри функции, целиком).

 

10 minutes ago, Variant99 said:

Или isValid - это валидность чего?

Если это - метод некого класса, то очень легко понять о чем речь.

 

для примера приведу в сравнение две абстрактные литературные книги:

1) изобилует тысячами сносок

2) обычную литература без сносок, читается легко и непринужденно.

Вот и хорошо читаемый код должен отвечать варианту 2.

Если вы желаете тому, кто будет пользоваться вашим кодом, суровой анальной боли, то пишите его по варианту 1. Читатель это оценит, уверяю ))

[Variant99 7]

1 минуту назад, Forger сказал:

Остальное - масло масляное.

Потому что не реализовано в натуре, а лишь набросано для демонстрации, вот и кажется "маслом". Я ж тут не буду полностью писать все методы вместе с обменом по I2C. 

16 часов назад, Arlleex сказал:

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

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

 

4 минуты назад, Forger сказал:

Если это - метод некого класса, то очень легко понять о чем речь.

А у автора - вовсе не метод. Просто переменная (поле) bool isValid; Вот и думайте, верность чего она означает. Догадаться конечно можно, зная это в контексте разговора. Мы тут 2 страницы на эту тему разговариваем, поэтому более-менее понятно.

[Forger 17]

5 hours ago, Variant99 said:

А разбираться в коде вообще без документации и без комментов, да еще когда названия тупые и сокращенные до 4 букв, это ваще нивкайф.

Документация должна быть для проекта: структура его кода, модули, иерархия классов, общие описания. Хотя бы для себя лично, на будущее, если работа в одиночку.

А вот код должен быть самодокументирован. Для хорошего кода - это признак его качества. Для примера посмотрите на исходники GUI TouchGFX и на их документацию.

 

3 minutes ago, Variant99 said:

А у автора - вовсе не метод. Просто переменная (поле) bool isValid; Вот и думайте, верность чего она означает.

Так исправить название или вставить внутрь структуры, которая сама имеет свое осмысленное название и делов-то ))

Это куда логичнее, чем обвешивать эту бестолковую сущность многострочными комментариями )

[Variant99 7]

2 часа назад, Forger сказал:

кто будет пользоваться вашим кодом, суровой анальной боли, то пишите его по варианту 1

Скажем так, вы на сайте  Arm® когда-нить бывали? Документацию по CMSIS, DSP CMSIS когда-нить читали? Она сгенерирована в Doxigen. Ну как, "жопная дырка" болела? А если заглянете в сырые исходники без документации? Разберетесь? Ой ли.

 

Цитата

Документация должна быть для проекта: структура его кода, модули, иерархия классов, общие описания.

Ну дак не вручную же её писать же! Doxygen через вставку вот таких вот блоков и формирует документацию проекта. Вы просто не работали с Doxygen, вот и думаете, что блоки комментов лишние. Ну а как прикажете составлять документацию по проекту тогда? Вручную копипастить и описывать чтоль? Ога, да щаз! Даже когда в проекте десяток файлов и сотня фукнций, вы задолбаетесь вручную сотворять иерархию. Doxygen же собирает её автоматически, просматривая файлы и собирая все эти дополнительные блоки.
Ну а я уж не виноват, что IDE вставляет автоматически doxygen-комменты. Конечно это я её так настроил, но блин, не отключать же систему ради двух поцыков, обделавшихся от ужаса при виде системы документирования :)))
 

Изменено 4 декабря, 2022 пользователем Variant99

[Forger 17]

2 minutes ago, Variant99 said:

Скажем так, вы на сайте  Arm® когда-нить бывали?

Вы смешиваете теплое и мягкое. 

2 minutes ago, Variant99 said:

Ну как, "жопная дырка" болела?

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

[Variant99 7]

11 минут назад, Forger сказал:

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

Нет, ну это ваше конечно право, исправлять, переделывать... Никого не заставляю. Хотя мне приходилось работать с большими проектами со сложной иерархией, да еще и с чужими модулями. И если они были бы написаны без единого комента, чтобы применить любую функцию из модуля мне пришлось бы вначале пролистать её от начала до конца, чтобы понять, что вообще на входе она хочет видеть и что дает на выходе.
Я ничего не смешиваю. Я лишь просто говорю, что если бы вы сунулись в DSP CMSIS, написанный без документирования и комментирования, вы бы ё##нулсь уже через 15 минут.
Ну кто ж знал, что автор вопроса не понимает документирования и предпочитает е%%ться в каше. Потому то у него и не получается сия простецкая затея. Он смешал в одной куче массивы, структуры, статические константные поля и сидит, не зная почему там чето не работает. 

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

Изменено 4 декабря, 2022 пользователем Variant99

[Forger 17]

6 minutes ago, Variant99 said:

Хотя мне приходилось работать с большими проектами со сложной иерархией, да еще и с чужими модулями.

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

 

6 minutes ago, Variant99 said:

Ну-с, ваши предложениея, как замутить и организовать это дело - то есть кэширование I2C устройств.

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

Будет больше исходных данных, можно и продолжить.

[Variant99 7]

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

За код, написанный в стиле автора вопроса, я бы и не взялся. Потому как даже с этой простецкой структурой пришлось задавать несколько наводящих вопросов, уточнений, и уже после этого понять-таки, что же в результате должно получаться. А получаться должна простая ОЗУ-копия регистров из микросхемы, причем есть 4 таких одинаковых (одинаковых?) микросхемы, сидящих на разных адресах шины I2C. То есть, фактически задача очень проста, но оказалась сложнопонимаемой из-за каши в коде и отсутствии хоть каких-то пояснений в нем.

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

43 минуты назад, Forger сказал:

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

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

Исходные данные в общих чертах ясны. Показанный выше класс I2C_Cache в принципе реализует запрошенный функционал, нужно только написать конкретные реализации методов. 
Download и Upload реализует загрузку и выгрузку кэша целиком, то есть синхронизацию между внешней микросхемой и кэшем. 
getReg читает указанный регистр из кэша, setReg записывает новое содержимое в указанный регистр кэша. Можно добавить шаблоны разных типов, если регистры могут быть разными, например 8-битные, 16-битные, 32-битные.
struct Regs - собственно ОЗУ-копия регистров внешней микросхемы. Можно вложить внутрь структуры и организовать имена полей в точности как если бы кэша не было. 
busAddress - адрес микросхемы на шине. Он заполняется в конструкторе в момент создания объекта класса, и используется в методах Download и Upload для обращения к конкретной микросхеме по её адресу.

Ну и как бы всё. Особо придумывать там больше нечего. А если выяснится, что микросхемы вдруг разные и имеют разные регистры, то тогда нужно сделать класс шаблонным и с наследованием структуры регистров, которую передавать при создании объекта класса. Тоже показывал.
 

Изменено 4 декабря, 2022 пользователем Variant99

[Arlleex 131]

"Массивы были в Си, в плюсах классы"... блин как послушаю, на смех пробирает, ей-богу.
Камон, я решил свою проблему, причем полностью так, как хотел - с блекджеком и массивами в плюсах.
isValid - bool-переменная структуры-класса sRegCache (кэша), которая указывает, актуально ли значение кэша или нет. Не актуально это содержимое, например, после включения питания до первого чтения из микросхем. Тяжело догадаться, валидность чего означает isValid, который расположен в структуре-классе кэша, да? Напомню, автор (я) не спрашивал мнения о вкусе устриц, автор спрашивал конкретный технико-лексический момент в C++. Я на 100% уверен, что дайте ваш код кому-то левому, найдется процент толковых программистов, которые скажут, что этот код говно. Это нормально, с этим можно и нужно жить.

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