шаблоны класса ring_buffer, channel - гибкость или наоборот? Опции

[aliko]

В scmrtos используются преимущества С++ в часнтости шаблоны.
например так объявляется шаблон класса кольцевого буфера

Код

template<typename T, uint16_t Size, typename S = uint8_t>
class ring_buffer

аналогично объявляется шаблон класса channel

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

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

[dxp]

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

Буфера разной длины - это разные типы, как ни крути. Если вы объявили int A[10]; и int B[20];, то это разные типы, хотя и похожие.

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

Тут не понял.

В итоге вместо гибкости получаем противоположный эффект.

Вопрос в том, что вы понимаете под гибкостью. С++ с помощью поддержки параметризованных типов предлагает автоматическую генерацию кода, который в противном случае пришлось бы писать вручную. Если вас не устраивает сгенерированный код, не используйте.

Может есть какое-о просто решение о котором я не знаю, подскажите товарищи!

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

Уж очень не хочется менять код ОС или дублировать то что там уже написано...

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