Всем ку! Появилась необходимость писать в файл байты. И писать не просто байты, а поиметь возможность сделать на подобии "WriteFloat(float Value);", где функция просто запишет в файл все-провсе. Первым делом что пришло на ум это union. Учитывая загадочность спецификации С++ (во первых за неимением онной. Во вторых за неимением знания тех. англ) пришлось лазить по форумам. Ну ничего... вроди бы инфу найти удалося. Значит коварнейшие POD. Вроди бы, как бы, получается что.... char это POD, char[4] это не POD по той причине, что расположение ячеек может быть произвольным и... в случае если выделялка памяти не найдет место под целый массив, чейки так и пойдут в разнобой. Правильно ли я понимаю? Ладно, с union тайна, но есть еще шаблоны. Что бы не путаться во всяких там memcpy по месту необходимости, сварганил вот такой класс на шаблонах

Класс на шаблонах


Ну и само собой его использование в функции WriteFloat(float Value)


Уважаемые знатоки! Вопрос тупой до безумия. Правильно?   

Это сообщение отредактировал(а) NYX - 30.5.2012, 14:26

нет. они располалаются подряд.
и да, это POD.


ну...можно сказать да))


но лучше бы ты union использовал)

То есть мои предрассудки на счет этого кода ->

Они лишние? Я просто не разу в своей жизни не дебажил программы на сях. В том смысле что с асмом ваще дело не имел, заморачивался одно время написанием шуточной ОС, с целью без цели. А разбором опкода С++ компиляций не занимался, не эксперементировал и не совсем в курсе всей подноготной.
Значит union вполне себе пригоже, и нет необходимости ИМЕННО В ТАКОМ случае использовать шаблоны?  Дешевле выйдет. Шаблоны же вроди бы приведут к созданию классов в разных типах и память не сэкономят вовсе.

то есть данное условие всегда true?


Это сообщение отредактировал(а) NYX - 30.5.2012, 15:24

тут все корректно.

по поводу остального - юзай union.

Добавлено через 39 секунд

да, для char`ов 

Шаблон

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

правда, if какой-то странный)

Да скобка лишняя  У меня температура просто, я мальца не адекватный в написании, мелкие ошибки сыпятся    

для любых типов - да (там же нет ни одного приведения типов, а -1 делается для типизированного указателя)


http://liveworkspace.org/code/9bac509c80ea...20181409c259323

кстати да.

В смысле для типизированного? В смысле (void*) не айс? Ну ваще его использовать как бы не планируется. Приведения тоже как бы не планируются... в данной части по крайней мере. Где вся телега с записью байт в файл.

к void* вообще нельзя применять адресную арифметику
я же имел в виду, что в приведённом примере нет приведения адреса к целому числу. Например такой код

будет работать только для char, unsigned char и bool (да и то только на 32-х битной системе). У Вас же в коде единица отнимается от указателя. и это - нормально.

а вообще-то, void* - не айс.

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

Правильно, только с серьезными ограничениями:

• Записанные типы должны быть только POD. (например не вздумайте записывать в файл std::string, это ни к чему хорошему не приведет!)
• Данные записанные в файл, непереносимы. т.е. они можгут быть корректно прочитаны только той-же самой программой, (скомпилированной тем-же самым компилятором, на той-же самой системе).

volatile, разумеется про типы и запись данных в файл размером с тип машины это дадададада. А вот на счет POD счас в серьез задумался, можно ли как то ограничить КРУГ поступающих типов данных? Ну, как то провоерить. является ли данный тип встроенным или это юзертип? Никогда не задавался этим вопросом. Вот в PHP знаю есть такая фишка, можно сравнить тип данных...
гуголь гласит о #include <typeinfo> и typeid(t).name()
Но там же на первой ссылке нашел предупреждения о том что это ваще лучше не использовать для рабочего кода...
И допустим заюзать... еще одна задача для меня... ведь можно как то макросами задать выходную ошибку копилятора? Ну типо определить ошибку прямо непосредственно в модуле и что бы компилятор ее выдавал если чо?

Это сообщение отредактировал(а) NYX - 31.5.2012, 01:13

есть проверка времени компиляции в boost boost::is_pod()
а вообще "писать байты" для простых типов (не содержащих указатели)) можно минуя всякие memcpy, просто write (&var, sizeof var)
какая разница где будет sizeof?