Arduino.ru

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

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

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

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

а изначально массив описан как некий байтовый буфер (не кольцевой) в котором могут быть разнотипные данные

может сначала сделать (void*) а потом его кастануть?

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

А чем это должно помочь ?

"Вот так кури :"

Вариант 1: *((uint16_t*)(&(data_device[9])))

Вариант 2 : *((uint16_t*)(data_device+9))

Только вот объясните мне, если вы путаетесь в этих преобразованиях, то нахрена вы их юзаете, если есть понятные вам ?

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

int16_t GetT(const uint8_t *data_device) {
  return *((int16_t*)&data_device[9]);
}
void SetT(uint8_t *data_device, const int16_t Term) {
  *((int16_t*)&data_device[9]) = Term;
}

Еще можно по-модному через static_cast, но я что-то синтаксиса не помню.

наверно так то-же будет верно

  int16_t GetT(const uint8_t *data_device) { return *((int16_t*)(data_device+9)); }
  void SetT(uint8_t *data_device, const int16_t Term) { *((int16_t*)(data_device+9)) = Term; }

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

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

в паскале есть record типа структуры но инвариантный (принимающий разные варианты в зависимости от типов данных), вроде в с++ простых аналогов я не видел, хотя возможно просто не увидел.

В си это называется юнит (unit). Почитайте, создаете альтернативные структуры, а потом объединяете их в юнит. Правда могут возникнуть проблемы с выравниванием данных, они , как правило, обходятся нормально. 

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

Т.е. Вы не знаете, чего хотите? А чего делать с тем, что не знаете - знаете? А как опознаете, то, что не знаете?

Херня какая-то.

а так не прокатит? пропробуй

int16_t *ptr = reinterpret_cast<int16_t *>(&data[9]);
return *ptr;

Это как раз заскоки паскаля :) Скорее всего он хочет получив массив по сигнальному признаку его разобрать  прям в буфере, типа память экономит.

int16_t *ptr = reinterpret_cast<int16_t *>(&data[9]);
return *ptr;

Ты конечно жОстко рубанул :) Вот так ошибется, а где никада не узнает :)

O_O   

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

Я вроде не говорил, что проблема....

я хочу получить универсальную шину данных с которой будет работать любой объект созданый на основе базового класса, что-то вроде EnterpriseData в 1с,  там она собрана на XML, здесь такой формат невозможно организовать из-за малой памяти. По существу пытаюсь сделать аналог фабрики XDTO на обьектной модели c++.

Совсем универсально у меня не выйдет, но для меня вполне пойдет

для начала я реализовал аналог TListCustom (по существу массив ссылок) , каждый новый объект регистрирует в нем ссылку на объект и на выделеную из кучи память под данные, для каждого объекта памяти может быть разное количество, например для датчиков температуры регистрируется один объект по номеру шины OneWire и место для хранения нескольких измерений температуры, плюс статус для каждого датчика. Этим я конечно не сильно экономлю память а просто делаю доступным данные объекта любым другим объектам.

То есть я реализовываю динамическое определение и подключение датчиков (и других устройств) к общей шине без создания новых объектов а только добавлением памяти и включением их в TList.

vde69, это для систем где есть CD карточка, куда вы будете пихать ваши файлы 1с.  Создать виртуальный диск из кучи в ОЗУ у вас не выйдет.