- 
	- Интересно. Хотя итераторы массива и вектора скорее всего являются
обёртками указателей, они не приводятся к указателям ни неявно, ни
с помощью static_cast. По крайней мере, в VS19 и IAR. Чтобы из
итератора получить указатель, проходится использовать безумнуюконструкцию &*. - йцyкeн(06.01.2021 16:32)- Как я понял это следствие implementation defined природы итераторов
и работает только на gcc. Так что это говнокод, буду исправлять. - evgeniy1294(06.01.2021 21:27)
					- Переделал интерфейс, теперь вместо указателя end нужно передать
size.  evgeniy1294(48 знак., 07.01.2021 05:47, ссылка, ссылка)
							- Зачем тащить (CRC_TypeDef* crc) в интерфейс каждого метода? Шаблоны
так шаблоны. Пример.  VladislavS.(706 знак., 07.01.2021 08:41)
									- Crc в этом плане уникален, он может использоваться разной
периферией с разными моделями. Дополнительно, хардварных
калькуляторов может быть 2 или 3. Поэтому, чтобы не делать лишние
using-и, тем самым сократив описание, сделано вот так.  evgeniy1294(370 знак., 07.01.2021 15:22)
											- Кто кроме вас может что-то по ошибке запихнуть? Библиотека
написана, из неё торчит интерфейс, который не подразумевает
запихивания в него чего-либо. Зачем пользователь полезет в кишки? - VladislavS.(07.01.2021 15:28)
													- Все равно это требует отдельного описания под каждый чип внутри библиотеки. Лишнего кода будет много, да, он будет только в библиотеке, но ошибиться и я могу. Я думаю над это проблемой, потом все "специальное" перетащу в основной заголовочник, тогда можно будет сократить писанину. - evgeniy1294(07.01.2021 15:45)
 
 
- Кто кроме вас может что-то по ошибке запихнуть? Библиотека
написана, из неё торчит интерфейс, который не подразумевает
запихивания в него чего-либо. Зачем пользователь полезет в кишки? - VladislavS.(07.01.2021 15:28)
													
 
- Crc в этом плане уникален, он может использоваться разной
периферией с разными моделями. Дополнительно, хардварных
калькуляторов может быть 2 или 3. Поэтому, чтобы не делать лишние
using-и, тем самым сократив описание, сделано вот так.  evgeniy1294(370 знак., 07.01.2021 15:22)
											
 
- Зачем тащить (CRC_TypeDef* crc) в интерфейс каждого метода? Шаблоны
так шаблоны. Пример.  VladislavS.(706 знак., 07.01.2021 08:41)
									
 
- Переделал интерфейс, теперь вместо указателя end нужно передать
size.  evgeniy1294(48 знак., 07.01.2021 05:47, ссылка, ссылка)
							
 
- Как я понял это следствие implementation defined природы итераторов
и работает только на gcc. Так что это говнокод, буду исправлять. - evgeniy1294(06.01.2021 21:27)
					
- Словить hardfault по невыровненному доступу можно даже на
Cortex-M4. Так что, лучше в принципе не делать таких опасных вещей.  VladislavS.(924 знак., 06.01.2021 10:27)
			- Самый быстрый вариант, который у меня получился:  evgeniy1294(1570 знак., 06.01.2021 15:23)
					- У вас на RISC-V пример с невыровненным доступом был, я
соответственно так же и написал. Если на Cortex-M0, то конечно,
надо как у вас. - VladislavS.(06.01.2021 16:10)
							- Для RISC-V я тоже либу поправил, зарезав все потенциально опасное. - evgeniy1294(06.01.2021 16:13)
 
- Чота я не понял, что тут дают плюсы кроме жуткого головняка. Почему
бы не наваять на голых сях? - SciFi(06.01.2021 15:25)
							- На голых сях тот же самый головняк с выравниваниями. Ну будет
вместо reinterpret_cast обычное приведение типов через (), в
остальном тоже самое. - evgeniy1294(06.01.2021 15:28)
									- Букофф меньше будет без потери смысла. Ящетаю, это будет чистый
вин-вин. Плюсовые зануды опечалятся, конечно, но предлагаю их
мнение игнорировать :-) - SciFi(06.01.2021 15:33)
											- Я согласен с тем, что С++ очень многословен, а всякие
reinterpret_cast<>, на мой взгляд, отвратительные решения
в языке. Можно было бы сделать как-нибудь покороче сделать. - evgeniy1294(06.01.2021 15:37)
													- Пока плюсы поддерживают старые способы приведения типов, то
применение вместо них reinterpret_cast<> это настоящее
мозго@бство. Ни одного преимущества от этого код не получает.
Только нечитаемым становится. - VladislavS.(06.01.2021 16:13)
															- Статические анализаторы уже ругаются матом на old-style cast. - evgeniy1294(06.01.2021 16:15)
																	- Да и хрен с ним. Программист для анализатора или анализатор для программиста? Поддержку никогда не уберут. - VladislavS.(06.01.2021 16:42)
 
 
- Статические анализаторы уже ругаются матом на old-style cast. - evgeniy1294(06.01.2021 16:15)
																	
 
- Пока плюсы поддерживают старые способы приведения типов, то
применение вместо них reinterpret_cast<> это настоящее
мозго@бство. Ни одного преимущества от этого код не получает.
Только нечитаемым становится. - VladislavS.(06.01.2021 16:13)
															
 
- Я согласен с тем, что С++ очень многословен, а всякие
reinterpret_cast<>, на мой взгляд, отвратительные решения
в языке. Можно было бы сделать как-нибудь покороче сделать. - evgeniy1294(06.01.2021 15:37)
													
 
- Букофф меньше будет без потери смысла. Ящетаю, это будет чистый
вин-вин. Плюсовые зануды опечалятся, конечно, но предлагаю их
мнение игнорировать :-) - SciFi(06.01.2021 15:33)
											
 
- На голых сях тот же самый головняк с выравниваниями. Ну будет
вместо reinterpret_cast обычное приведение типов через (), в
остальном тоже самое. - evgeniy1294(06.01.2021 15:28)
									
 
- У вас на RISC-V пример с невыровненным доступом был, я
соответственно так же и написал. Если на Cortex-M0, то конечно,
надо как у вас. - VladislavS.(06.01.2021 16:10)
							
- Без кода такой косяк поймать можно: проц STM32L151, рядом GSM модем на плате, при работе на передачу - хард фаулт был пока антенну на 90 градусов не развернул. А программисты то, да в шоке были. - Visitor(06.01.2021 14:13)
 
- Самый быстрый вариант, который у меня получился:  evgeniy1294(1570 знак., 06.01.2021 15:23)
					
 
- Интересно. Хотя итераторы массива и вектора скорее всего являются
обёртками указателей, они не приводятся к указателям ни неявно, ни
с помощью static_cast. По крайней мере, в VS19 и IAR. Чтобы из
итератора получить указатель, проходится использовать