[fpc-pascal] Writing floating points to steams

Sven Barth pascaldragon at googlemail.com
Wed Jan 13 14:47:23 CET 2016


Am 13.01.2016 13:16 schrieb "Torsten Bonde Christiansen" <tc at epidata.info>:
>
> On 2016-01-13 10:40, Mark Morgan Lloyd wrote:
>>
>> Torsten Bonde Christiansen wrote:
>>>
>>> On 2016-01-13 10:06, Mark Morgan Lloyd wrote:
>>>>
>>>> Serguei TARASSOV wrote:
>>>>>
>>>>> On 13/01/2016 08:47, fpc-pascal-request at lists.freepascal.org wrote:
>>>>>>
>>>>>> On 2016-01-12 10:45, Torsten Bonde Christiansen wrote:
>>>>>>>
>>>>>>> Since TStream doesn't have any native WriteFloat/Double and the
likes,
>>>>>>> some conversion is needed - but what is a good strategy for this?
>>>>>
>>>>> Depends on size constraints.
>>>>> In the simple case you should convert float to locale-independent
string value (no spaces, no commas separators) then write it.
>>>>> If the size does matter, you may convert float to corresponding byte
array then write it.
>>>>
>>>>
>>>> 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?
>>
>>
>>> 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.
>>
>>
>> Thanks, I assumed that was the case but thought it worth checking.
>>
>> I suppose that one could stream variants, i.e. the enumeration saying
what one was followed by a value.
>>
>>>> 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?
>>>>
>>> It would be great if storing floating point could be in IEEE, to have a
standard as reference.
>>
>>
>> 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.
>
>
> I'm not even sure how (or even if) TStream decendants handles endianness
for integers.... I'm guessing they are not.

TStream always read in its native order. If you know that the data is of
the opposite endianess you need to convert this yourself as TStream can't
know that.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20160113/8724c064/attachment.html>


More information about the fpc-pascal mailing list