8

Is there a term for a class/struct that is both trivial and standard-layout but also has no pointer members?

Basically I'd like to refer to "really" plain-old-data types. Data that I can grab from memory and store on disk, and read back into memory for later processing because it is nothing more than a collection of ints, characters, enums, etc.

Is there a way to test at compile time if a type is a "really" plain-old-data type?

related:
What are POD types in C++?
What are Aggregates and PODs and how/why are they special?

PPenguin
  • 269
  • 1
  • 8
  • @BartekBanachewicz Hmm... that's a good point. For my purposes, "non-pointer" would be adequate, but yes I guess the more general concept would be "trivially serializable". – PPenguin Jan 24 '18 at 14:58
  • 1
    There is a [std::is_pod](http://en.cppreference.com/w/cpp/types/is_pod) function. – Ron Jan 24 '18 at 14:58
  • 2
    *"I can grab from memory and store on disk,"* There is still endianness... – Jarod42 Jan 24 '18 at 14:58
  • 1
    @Ron `struct A { int* p; }` is a POD. – Bartek Banachewicz Jan 24 '18 at 14:59
  • Storing pointers would still constitute as POD even if the type is trivially constructible and destructible. Even a type storing integers might suffer from invalidation issues if the integers are indexing something in memory that you unload and store on disk, e.g., and then add back later to a different index position. Unfortunately there's not an easy and automatic way to solve this typically by just looking at data types. You have to kind of consider the design and nature of the data in a less generalized way typically and write the appropriate kind of serialization code. –  Jan 24 '18 at 15:01
  • Also it's a [potential duplicate](https://stackoverflow.com/questions/32880990/how-to-check-if-class-has-pointers-in-c14#comment53592777_32880990), but I don't want to dupehammer that because it asks a subtly different question. – Bartek Banachewicz Jan 24 '18 at 15:02
  • 2
    I don't think there is a term for that, and testing it at compile time would be very hard. For instance, you could store addresses existing only in the execution context as integers, and the compiler is not aware of the meaning of what you stored. – Benjamin Barrois Jan 24 '18 at 15:04
  • Consider a case like struct `Foo {int idx};` with `idx` indexing an object of `struct Bar {float x, y};` stored in `std::vector`. If you write Bar to disk and remove it from the vector and then add it back later in a different position, `Foo` would still be invalidated. To me the most practical solution to this kind of problem is going to be a lot less generalized and really consider the context and nature of the data you're trying to write to disk and then read back out again later on. –  Jan 24 '18 at 15:07

1 Answers1

3

This can depend on semantics of the structure. I could imagine a struct having int fields being keys into some volatile temporary data store (or cache). You still shouldn't serialize those, but you need internal knowledge about that struct to be able to tell1.

In general, C++ lacks features for generic serialization. Making this automatic just on pointers is just a tip of the iceberg (if possibly pretty accurate in general) - it's also impossible in a generic way. C++ still has no reflection, and thus no way to check "every member" for some condition.

The realistic approaches could be:

  • preprocessing the class sources before build to scan for pointers
  • declaring all structs that are to be serialized with some macros that track the types
  • the regular template check could be implemented for a set of known names for fields

All of those have their limitations, though, and together with my earlier reservations, I'm not sure how practical they'd be.

1 This of course goes both ways; pointers could be used to store relative offsets, and thus be perfectly serializable.

Bartek Banachewicz
  • 38,596
  • 7
  • 91
  • 135