<p>Am 13.01.2016 10:40 schrieb "Mark Morgan Lloyd" <<a href="mailto:markMLl.fpc-pascal@telemetry.co.uk">markMLl.fpc-pascal@telemetry.co.uk</a>>:<br>
><br>
> Torsten Bonde Christiansen wrote:<br>
>><br>
>> On 2016-01-13 10:06, Mark Morgan Lloyd wrote:<br>
>>><br>
>>> Serguei TARASSOV wrote:<br>
>>>><br>
>>>> On 13/01/2016 08:47, <a href="mailto:fpc-pascal-request@lists.freepascal.org">fpc-pascal-request@lists.freepascal.org</a> wrote:<br>
>>>>><br>
>>>>> On 2016-01-12 10:45, Torsten Bonde Christiansen wrote:<br>
>>>>>><br>
>>>>>> Since TStream doesn't have any native WriteFloat/Double and the likes,<br>
>>>>>> some conversion is needed - but what is a good strategy for this?<br>
>>>><br>
>>>> Depends on size constraints.<br>
>>>> In the simple case you should convert float to locale-independent string value (no spaces, no commas separators) then write it.<br>
>>>> If the size does matter, you may convert float to corresponding byte array then write it.<br>
>>><br>
>>><br>
>>> Can I ask a naive question here please: does a binary stream store endianness anywhere? In other words, is there any indication that something running on ARM is about to get into trouble by reading something written by (big-endian) MIPS?<br>
><br>
><br>
>> Not that I'm aware of - i would think of it as a stream of bytes. Endianess is defined by the CPU not by the file.<br>
><br>
><br>
> Thanks, I assumed that was the case but thought it worth checking.<br>
><br>
> I suppose that one could stream variants, i.e. the enumeration saying what one was followed by a value.</p>
<p>That's not the task of TStream however. For that you should use a custom class that uses TStream under the hood.</p>
<p>><br>
>>> Should writing binary floating point to a stream note that it's IEEE format, just in case anybody ever tries to process it on a platform that supports alternatives?<br>
>>><br>
>> It would be great if storing floating point could be in IEEE, to have a standard as reference.<br>
><br>
><br>
> I'm not at all sure about this, but I think I've seen something that suggested that byte ordering in external representations was covered by the standard.</p>
<p>I've checked recently due to big endian problems in the Castle game engine and found out that endianess isn't really covered for floating points...</p>
<p>Regards,<br>
Sven</p>