reading binary -> C++ structs

I'm writing a program in C++ to read in .geo format binary 3d graphic files.  I have a file spec that gives me plainly the struct of the various data blocks.  As a result, I can do this:

tPolygonObject getObjectEntry (ifstream& geoFile, udword address)
{  tPolygonObject tmpobj;
   geoFile.seekg(address);
   geoFile.read((char*)&tmpobj, sizeObjectEntry);
   return tmpobj; }

// function call
polyObject[i] = getObjectEntry(geoFile, memFinger);

Meaning, I can simply read a chunk and plunk it down into my struct variable, and all the data members will be what they're supposed to be without me worrying about them lining up.

The problem is, what if I alter the structs, by adding more member variables? If I put them at the end, will it fill up the original ones in the same way, and leave the new members empty? Or will it just FUBAR everything?

If you add it at the end, you probably won't have a problem, provided you only fill the struct one at a time.

A better question is why you haven't tried. How many seconds would it take you? Please tell me you aren't using waterfall here.

>>1

Perhaps.

This depends on the architecture in question, as well as the compiler, optimizations, and perhaps even the order that the members of the struct are defined in.  If your compiler is optimizing alignment within the data structure, e.g., and you add more members, the end optimization might be different and a direct binary plunking may no longer be valid.  Or it may be valid.  Who knows?

(This is why >>2's suggestion is only good for informal dev't or a very specific problem space, btw.  The fact that it builds and works on your machine doesn't imply that it will build and work on mine.  I might have a different compiler that optimizes alignment differently.  I might have an architecture with a different sort of alignment.  Etc.)

If you're insistent on modifying the existing struct, and you expect a limited use-space, go ahead and try it, see if it works.  You could also inspect the actual binary representation in memory to double check everything's as expected.

What you should be asking yourself, though, is why you want to change what exists instead of simply eating the cost of a copy, or (even better) the cost of a struct that contains your desired struct.  E.g.:

struct tPolygonObject{
  // blah
};

struct tMyPolygonObject{
  tPolygonObject p;
  // extra things you want on tPolygonObjects
};

You could still do your copy by referencing p.

>>3
Why would adding elements to the end of a struct change the data alignment of prior elements?

>>4
Optimizations
--funrol-loops just kicked in yo!

OP here, it didn't work.  So i just made it a seperate var. But now something else is wrong.

memFinger = sizeHeader;        // first obj entry follows header
for (int i=0; i < nPolyObjects; i++)
{  polyObject = getObjectEntry(geoFile, memFinger);
   sName = getObjectName(geoFile, polyObject.oName);
   outputObjectEntry(polyObject, sName);
   memFinger += sizeObjectEntry;  // sizeObjectEntry = 112
}

For some unfathomable reason, "i" is getting reset to 0 somewhere, so the loop does not end. I just can't imagine what could possibly be happening, since it's not even used out of the controlling expression.  (I realized I didn't need to have all the objects loaded at once, so I discarded the struct array polyObject[i].)

>>5
I know full well optimizations can change things in the background, but I still fail to see how it would have an effect on a struct.

All optimizations are premature optimizations

>>8
True words.

>>8 Otherwise known as "Only the compler knows how to optimize."

Yeah, always use bubblesort. The compiler will automatically replace it with quicksort.

>>9 That has nothing to do with anything. Bubble- and quicksort are entirely different, so implement one or the other.

>>11
No, use the sorting algorithm the language's library provides.  std::sort in the case of C++.

I'm >>8, and I was actually trolling. I like to do as follows:

1. Design that's not braindamaged.
2. Optimize algorithms, i.e. complexity.
3. Write your program in a comfortable way.
4. If your application is critical, then bother optimizing some of it (maintainability/speed tradeoff is common though).
5. Let the compiler do its job. It'll be good.

>>13
Which was written and optimized by (gasp) humans.

>>15
Aye, and it's always kept up-to-date on the latest and fastest sorting algorithm.

>>16
Wasn't QuickSort the fastest sorting algorithm since the 60s? A non-recursive implementation of QuickSort in place should be VROOM VROOM.

>>17
Depends what you mean by "fastest". It's a fast sort, but has a poor worst-case complexity (polynomial). Heapsort may be a better choice.

Mergesort uber alles.

>>18
So it would be wise to perform HeapSort when you are sorting elements that are expected to be in a really random order, and QuickSort everywhere else? Then it would be useful to have both.

>>19
How does MergeSort compare to QuickSort and HeapSort?

http://en.wikipedia.org/wiki/Introsort

How does MergeSort compare to QuickSort and HeapSort?
Same time complexity, benches slower, doesn't suffer from quicksort's worst-case scenario. Space complexity is worse if you're using arrays, the same if you're using linked lists.

>>21
Interesting...

>>21
+1 Insightful
Thanks, I'll implement this instead.

So it would be wise to perform HeapSort when you are sorting elements that are expected to be in a really random order, and QuickSort everywhere else?

A naive quicksort implementation's worst case case occurs on a sorted list. Of course, nobody uses a naive implementation, since sorting a list that's close to sorted is really common.

Having said that, I wish heapsort and mergesort were widely available in the standard C library. All three algorithms have sets of characteristics that make them desirable in different circumstances.

This is interesting: http://www.azillionmonkeys.com/qed/sort.html

Shellsort ftw

so what sorting algorithm is the fastest for a best case scenario?

best case scenario

None. It's already sorted.

ok, how about almost best case scenario then?

>>27 is a tard.
If it's already sorted you still need linear time to check that fact. And if you don't check it, quicksort will crap itself.

>>29
Next time I'll add a big WARNING: HUMOR just for you.

>>28
Plenty of algorithms handle near best-case scenarios well, but most of them perform terribly if a worst-case comes along (usually O(n^2)).

If you're sorting a long list that's probably near best-case, but not guaranteed, smooth sort seems to be a contender.

Hmm, well im thinking of sorting sprites according to the y-axis to get them painted in the correct order, so im going to have a almost sorted list, only minor changes.
However from what i have understood, sorting can be quiet a time-consuming process, and since im trying to create a game, time is of the essence.

>>31
Yeah, it's pretty bad when you have like 2,000,000 sprites on screen :/

<OP attempts to wrestle topic back to original subject>

This is my latest incarnation, after taking >>3's advice, and nesting the original struct. I also folded some functions into it and made it a class.

memFinger = SIZE_HEADER;  // first obj entry follows header, SIZE_HEADER is 68 bytes, and both are unsigned ints.
for (int i=0; i < nPolyObjects; i++)
{ object.getRoot(geoFile, memFinger);
  object.getLists(geoFile);
  object.show();
  memFinger += SIZE_OBJECT_ENTRY; }

i is fine, but now 'memFinger' is getting set to zero.  WTF is going on?

>>31
I've done this exact thing in the program I maintain at work. I used merge sort and it's acceptably fast. I haven't bothered profiling it or comparing it, because if it aint broke don't fix it amirite.

Gay gay gay gay gay gay

Yaranaika?

Hi, I can spam /prog/ too, you faggot.

Also, smoke weed everyday.

39 Name: Sgt.Kabu䭕kiman鬁ࡵ 2012-05-28 19:08

Bringing /prog/ back to its people
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy
All work and no play makes Jack a dull boy