New to FreeBASIC? Post your questions here.
MrSwiss wrote:Sorry to butt in on this, but using Integer (in UDT), for file access (any method),
is actually *asking for troubles*, because SizeOf(Integer) varies, with the used
version of FBC (32/64 bit's), making the file unusable, when accessing with a
.exe compiled with the *other* FBC!
No problem, as you're dead right. As I already stated, I coded it in a hurry =D
sero wrote:@paul doe - I didn't know about field alignment until just now. I don't understand the purpose of this. The manual talks about padding which doesn't make any sense to have padding in a binary file. I changed the field = to 1, then 2, then 4 and the file size was not impacted at all. So what exactly does this do?
Effectively, padding in a file doesn't make any sense, only in memory (memory aligned read/writes are faster; also, some architectures don't even support reading from unaligned addresses), but you DO have to take it into account when reading/writing to a file. Another thing you need to take into account is the order of the elements of a structure:
Code: Select all
'' Size of the type is 16 bytes, right?
as ubyte a, b, e, f
as double c
as long d
? sizeOf( myType1 ) '' Wrong!
as long c
as ubyte a, b, e, f
as double d
? sizeOf( myType2 ) ' ' More like it
As you can see, the order can determine the true size of a record in memory, see here: https://wiki.sei.cmu.edu/confluence/display/c/EXP03-C.+Do+not+assume+the+size+of+a+structure+is+the+sum+of+the+sizes+of+its+members. The discussion is about C, but FreeBasic also applies. That's why is very important not only to preserve the size of the elements but also the order of them when you're reading, for example, a file header. Little details that can save you a world of trouble ;)
fxm, is this normal behavior? I mean, writing to an arbitrary position into a binary file opened with 'access write' wouldn't just write the bytes you specify, where you specify, instead of zeroing everything up to that point? Or I am missing something? I've had to open it as 'access read write' to pull this off without erasing all the data before the position I specified. I don't recall having this problem before...
I see, it's a file system quirk, not a FB bug. Thank goodness ;)
paul doe wrote:I don't recall having this problem before...
To my knowledge, there has never been a change in the compiler on this behavior.
fxm wrote:To my knowledge, there has never been a change in the compiler on this behavior.
That's ok, perhaps it was on another language and I don't remember which. Thanks.
Who is online
Users browsing this forum: No registered users and 5 guests