C++ create an array of nested class objects in a class

Started by
11 comments, last by rip-off 10 years, 11 months ago

That's great ta:

Firstly I was just trying to encapsulate the code as it seemed the natural progression if I were creating objects in objects. Is it wrong to try this kind of nesting? Would I be better off just creating a separate class?

I tend to use nested classes in cases where the classes never need to be accessed publicly (i.e. they are only used in private areas of a class). It's just a stylistic thing really, and there's no real problem doing either.

Secondly I was trying to avoid vectors as I thought that you couldn't save them in .bin files. only vars and arrays! Is that a falsehood?


#include <cstdio>
 
void save(std::FILE* fp, const std::vector<cTroupObj>& objs)
{
 uint32_t num = objs.size();
 std::fwrite(&num, 1, sizeoff(uint32_t), fp);
 if(objs.size()) //< important! (otherwise you'll hit NULL if empty)
 {
    std::fwrite(&objs[0], objs.size(), sizeof(cTroupObj), fp);
 }
}
 
void load(std::FILE* fp, std::vector<cTroupObj>& objs)
{
 uint32_t num = objs.size();
 std::fread(&num, 1, sizeoff(uint32_t), fp);
 objs.resize(num);
 if(objs.size()) //< important! (otherwise you'll hit NULL if empty)
 {
    std::fread(&objs[0], objs.size(), sizeof(cTroupObj), fp);
 }
}
Advertisement

Oh that's great news, I was reading one website that said .bin files don't really like vectors. Is it stable enough to use in games saves for release titles?

Thanks again guys, you've cleared up quite a few things there.

If you get near a point, make it!

There is but one problem with it. When reading in the data, the constructors will be called when you call resize, and then the values will be written over with your file data. If you had 6 million troups, this may cause a (very small) slow down due to memory bandwith / CPU cache issues. If however it's just for a few troups (i.e. <10000) you'll be fine. Ultimately, you've got to look at the simplicity of using a std::vector here to add and remove troups, vs the faffery of managing that yourself. It works, It's simple, and you can spend your time worrying about the more important aspects.

If the binary data you're reading in is generally going to be constant (for example all of the mesh & collision data in your level), then that could be an area where you might want to consider something else (if, and only if, you're writing a game for xbox/ps4 and expect to be loading that data off DVD). For data being loaded off hard drive, that effort isn't really going to be worth it. For data such as a save game, it definitely isn't worth it.

Firstly, a ".bin" file isn't a type, just a hint that the data is not textual and not in a well-known format.

You cannot write a vector's bit pattern to a file and expect it to be meaningful. This is not an issue with vector, it is an issue with any object which is not Plain Old Data (POD for short). For example, writing an array of pointers directly to a file isn't meaningful.

RobTheBloke's code shows how to write a vector in general, write the size and write the elements. The thing to remember is that this is only legal if cTroopObj is a POD type. Now, the linked article earlier disqualifies cTroopObj:

Moreover, a POD class must be an aggregate, meaning it has no user-declared constructors, no private nor protected non-static data, no base classes and no virtual functions

A final note is that if you want the data files to be platform independent, you'll need to take care of the data size, padding and the "endian" nature of the data.

This topic is closed to new replies.

Advertisement