Are class members guaranteed to be contiguous in memory?

by

It is guaranteed that they appear with increasing addresses in the order declared. This is true in general of data members without intervening access specifiers, so if there are other data members in the class then the only way they could intervene is if there are access specifiers in there.

I don’t think it’s guaranteed to be safe to modify padding bytes. I don’t think it’s guaranteed that the implementation won’t put “something important” in between data members, although I can’t immediately think of anything an implementation would want to put in there. Type information for a strangely-designed accurate-marking GC? Recognizable values to test for buffer overruns?

It’s not guaranteed that all-bits-zero represents a null function pointer.

You could deal with the issue of the all-bits-zero representation using something like:

std::fill(&func1, &func4 + 1, (void(*)(void))0);

but that would still leave the issue of padding. You’re guaranteed no padding in an array, but not (by the standard) in a class. The ABI used by your implementation might specify struct layout to the degree necessary to ensure that your class above is laid out the same as an array of 4 function pointers.

An alternative is to do the following:

struct function_pointers {
    void (*func1)();
    void (*func2)();
    void (*func3)();
    void (*func4)();
};

class C : private function_pointers
{
public:
    C() : function_pointers() {}
};

The initializer function_pointers() dictates that (since it doesn’t have a user-declared constructor) the members of function_pointers are zero-initialized even if the instance of C itself is only default-initialized. function_pointers could be a data member rather than a base class, if you prefer to type a bit more to access func1 etc.

Note that C is now non-POD in C++03. In C++11 C remains standard-layout after this change, but would not be standard-layout if there were any data members defined in C, and it is not a trivial class. So if you were relying on POD/standard/trivial-ness then don’t do this. Instead leave the definition of C as it is and use aggregate initialization (C c = {0};) to zero-initialize instances of C.

More Related Contents:

  1. stl::map assert [closed]
  2. Pointers with c++ [duplicate]
  3. No member named ” in ”. Why did it happen and how do I fix it?
  4. Question 1: execution time of calling the function
  5. How do I print the content of a file?
  6. My attempt at value initialization is interpreted as a function declaration, and why doesn’t A a(()); solve it?
  7. to_string is not a member of std, says g++ (mingw)
  8. Accessing class members on a NULL pointer
  9. Are “anonymous structs” standard? And, really, what *are* they?
  10. Initializing a two dimensional std::vector
  11. C++ cout hex values?
  12. How to create minidump for my process when it crashes?
  13. Why does “extern const int n;” not work as expected?
  14. Does a c++ struct have a default constructor?
  15. How to get total cpu usage in Linux using C++
  16. Conditional operator used in cout statement
  17. How does weak_ptr work?
  18. Is the “one-past-the-end” pointer of a non-array type a valid concept in C++?
  19. Printing all environment variables in C / C++
  20. Should I use virtual, override, or both keywords?
  21. Building Qt5 with Visual Studio 2012 / Visual Studio 2013, and integrating with the IDE
  22. Creating N nested for-loops
  23. Understanding glm::lookAt()
  24. Which is faster/preferred: memset or for loop to zero out an array of doubles?
  25. How to get the precision of high_resolution_clock?
  26. Will I be able to declare a constexpr lambda inside a template parameter?
  27. What is the cyclic dependency issue with shared_ptr?
  28. Does C++11 unique_ptr and shared_ptr able to convert to each other’s type?
  29. Proper way to receive a lambda as parameter by reference
  30. When to use functors over lambdas

Leave a Comment