Jump to content
  • Advertisement
Sign in to follow this  
iam73

Having a hard time logging data to a file...

This topic is 2587 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi guys,

Having a hard time figuring this (probably simple) challenge with logging data read from a binary file to a txt file.

First I have this struct:


struct objHeader{
float fRadius;
float fMountingOffsetX;
float fMountingOffsetY;
float fMountingOffsetZ;
ushort sVersion;
ushort sColorFormat;
} header;



Using this code to get the data:

objHeader *pheader;
pheader = (objHeader *)walker;


I can validate that all my struct members have the right values stored in them.

Now I'm unable to put any of the struct member into a char buffer to output in a messagebox or to my txt logfile (using strcpy_s or strcat_s), fails with everything I've tried and can't find infromation on what I'm trying to do... I'm doing trials and errors now and hate that.


Any tips?

Thanks for helping,

Fred

Share this post


Link to post
Share on other sites
Advertisement

Now I'm unable to put any of the struct member into a char buffer to output in a messagebox or to my txt logfile (using strcpy_s or strcat_s), fails with everything I've tried and can't find infromation on what I'm trying to do... I'm doing trials and errors now and hate that.


Is the problem lack of formatting / converting those values to a string? Ala sprintf to format to buffer, or fprintf to format directly to the output?

Share this post


Link to post
Share on other sites
String mangling is boooring.
I mean, you're not going to learn much.

Have you considered JSON instead? I have been using jsoncpp for a while right now, I love it.

Share this post


Link to post
Share on other sites

How are you trying to use strcpy or strcat? Show us what you've tried.


What I've tried is really not relevant as I've been trialing and erroring for hours with delirious concepts, until I did some more googling and finally found a way that is almost doing what I want.

By using this code, I can get the data in my message buffer as chars:


strcpy_s(messBuff, sizeof(messBuff), (char *)&pheader->cVersion);


So this code is "reading" from the right memory location and stores the result as chars allright in my buffer. but I'm facing a different problem now.

The "sVersion" struct member (see first post for objHeader struct) is an unsigned short, so I was expecting to read only 2 bytes from the address of pheader->sVersion. Problem is, it reads/stores 4 bytes and I don't understand why.

Memory look like this at the address of pheader->sVersion:


01 80 03 00 55 00 00 00


I was expcting to get "80 01" in messBuff, but I actually get "00 03 80 01". So why am I reading 4 bytes eventhough sVersion is delcared as an unsigned short ???
When checking this in the debugger: sizeof((char *)&pheader->sVersion), it gives me 4 bytes. When checking sizeof(&pheader->sVersion), it gives me 2 bytes.
I'm confused...

Any tips?

Thanks guys.

Share this post


Link to post
Share on other sites
Although you may have found your answer I just wanted to offer suggestions for anyone else that happens across this thread and is looking for more answers. File Streams. I'll spare you the long winded tutorials and what not as there are ample sources on google that can do a much better job then I. However when you are working on saving data from an object into a file, or really any data stream for that matter I highly recommend looking up File Streaming and Object Serialization. It provides much more flexibility when used properly and allows you to store data types as is without having to add additional overhead of casting to and from characters.

Share this post


Link to post
Share on other sites

The "sVersion" struct member (see first post for objHeader struct) is an unsigned short, so I was expecting to read only 2 bytes from the address of pheader->sVersion. Problem is, it reads/stores 4 bytes and I don't understand why.
[/quote]
That is structure padding. You can disable it via pragmas on some compilers, or you can serialise the data field by field:

// If you're using C++ this would be better as a template function
#define FSERIALISE_FIELD(field, stream) fwrite(&(field), sizeof(field), 1, stream)

void serialise(FILE *out, objHeader *pheader)
{
FSERIALISE_FIELD(pheader->fRadius, out);
FSERIALISE_FIELD(pheader->fMountingOffsetX, out);
FSERIALISE_FIELD(pheader->fMountingOffsetY, out);
FSERIALISE_FIELD(pheader->fMountingOffsetZ, out);
FSERIALISE_FIELD(pheader->sVersion, out);
FSERIALISE_FIELD(pheader->sColorFormat, out);
}
#undef FSERIALISE_FIELD

And similarly for reading the structure back in.

Reading/writing a struct out directly is convenient, but it doesn't take into account padding, data size and endian issues. If you want to support files that will work across platforms, serialising field by field is better. You can also (de)serialise (from)to a byte buffer (after)before (reading)writing it to a file.

When checking this in the debugger: sizeof((char *)&pheader->sVersion), it gives me 4 bytes. When checking sizeof(&pheader->sVersion), it gives me 2 bytes.
[/quote]
Generally speaking, sizeof(pointer) should be a fixed size, usually 4 bytes for 32 bit systems and 8 bytes for 64 bit systems. I would expect both those expressions to evaluate to the same number. If you want to find the number of bytes in the field, just use sizeof(pheader->sVersion).

Note that sizeof is an odd operator. In sizeof((char *)...), the ... part here is redundant, the compiler only cares about the type of the expression, and here the cast is forcing the type. You generally don't care about the size of pointers, as they shouldn't be serialised to bytes.

Share this post


Link to post
Share on other sites
Dan and rip-off, thank you VERY much for the extra information!

I'll take that into account and do some more research on what you suggested.



Cheers!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!