Note that there are some explanatory texts on larger screens.

plurals
  1. POLooking for something similar to offsetof() for non-POD types
    text
    copied!<p>I'm looking for a way to obtain offsets of data members of a C++ class which is of non-POD nature.</p> <p>Here's why: </p> <p>I'd like to store data in <a href="http://www.hdfgroup.org/HDF5/whatishdf5.html" rel="noreferrer">HDF5</a> format, which seems most suited for my kind of material (numerical simulation output), but it is perhaps a rather C-oriented library. I want to use it through the C++ interface, which would require me to declare storage types like so (following documentation from <a href="http://www.hdfgroup.org/HDF5/doc1.6/cpplus_RM/classH5_1_1CompType.html#a16" rel="noreferrer">here</a> and <a href="http://www.hdfgroup.org/HDF5/doc1.6/UG/11_Datatypes.html" rel="noreferrer">here</a> (section 4.3.2.1.1)): </p> <pre><code>class example { public: double member_a; int member_b; } //class example H5::CompType func_that_creates_example_CompType() { H5::CompType ct; ct.insertMember("a", HOFFSET(example, member_a), H5::PredType::NATIVE_DOUBLE); ct.insertMember("b", HOFFSET(example, member_b), H5::PredType::NATIVE_INT); return ct; } //func_that_creates_example_CompType </code></pre> <p>where HOFFSET is a HDF-specific macro that uses offsetof.</p> <p>The problem is of course, that as soon as the example-class becomes it little bit more featureful, it is no longer of POD-type, and so using offsetof will give undefined results.</p> <p>The only workaround I can think of is to first export the data I want to store to a simpler struct, then pass that to HDF. That does however involve data copying, which is exactly what HDF is trying to avoid (and why they have this CompType which enables the library to reach into your objects to save their data to file).</p> <p>So I was hoping you'd have better ideas. Ideally I'd be looking for a portable workaround for this problem, but if short of that you could give me an idea that works on x86 and x86_64 with GCC I'd already be immensely grateful.</p> <p>----- appended later: -----</p> <p>Greg Hewgill suggested below to store the data in a simple struct, then build the actual class by inheriting from that. For HDF specifically, I think that may not practically work. A more elaborate usage scenario than above:</p> <pre><code>class base_pod { public: double member_a; int member_b; }; //class base_pod class derived_non_pod : private base_pod { public: //the following method is only virtual to illustrate the problem virtual double get_member_a() {return member_a; } }; //class derived_non_pod class that_uses_derived_non_pod { public: void whatever(); private: derived_non_pod member_c; }; //class that_uses_derived_non_pod </code></pre> <p>Now, when we're storing instances of the class that_uses_derived_non_pod, we cannot describe its memory layout as if it had a base_pod as member_c. This would get the offsets wrong because derived_non_pod adds funky stuff (like a virtual function table, I guess?).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload