5

I want to define a struct in a c++ source code that should be a POD (so it should be compiled based on C standard and not C++)

for example assume that I have the following code inside a c++ file:

struct myStruct
{
   int x;
   int y;
}
class MyClass
{
    int x;
    int y;
}

if I compile this code, struct is POD and should be compiled as POD. So the placement of member variables follow the C standard which is well defined.

But assume that a user may mistakenly, change the code to this code:

struct myStruct
{

   int x;
   int y;
private:
   int z;
}
class MyClass
{
    int x;
    int y;
}

now the struct is not POD and compiler is free on how it would place the member variables in memory.

How can I force the compiler to make sure that a struct is always compiled based on C standard?

Please note that I can not place the code inside a *.c code as I am developing a header only code which can be included into a *.cpp source code.

underscore_d
  • 6,309
  • 3
  • 38
  • 64
mans
  • 17,104
  • 45
  • 172
  • 321
  • 3
    Interesting question, but I wonder what the real problem is here? You just don't want someone else to change your header later to something that is not a POD? – wally Dec 19 '17 at 13:47
  • 1
    https://stackoverflow.com/questions/1041866/in-c-source-what-is-the-effect-of-extern-c See if this helps. Read the answers – Sruthi Dec 19 '17 at 13:48
  • 7
    This feels a little bit XY. What are you actually trying to achieve? – Joe Dec 19 '17 at 13:48
  • _"should be a POD (so it should be compiled based on C standard and not C++)"_ That is not the definition of POD. @SruthiV No, that just changes the linkage of resulting symbols, not the rules used to parse structures etc. – underscore_d Dec 19 '17 at 14:03
  • 2
    If your question boils down to "How can I stop people modifying headers/source files that I give them", ultimately the answer is that you simply cannot and shouldn't worry about it. Anyone doing that and breaking something is their own fault, and you shouldn't waste time saving such people from themselves. People will always find a way to break things if they want to, for some reason, and it's not productive to worry about them doing so, if they ignore your guidelines for using the code. Of course, if you think you have a legitimate use case for this, you should explain what it is. – underscore_d Dec 19 '17 at 14:05
  • @underscore_d It is not about not allowing them to change the source code, but making sure that they are not doing something silly such as changing layout without knowing what they do. So accepted answer is an actual solution which would let them know that something is wrong. – mans Dec 19 '17 at 15:25

1 Answers1

11

You can't force the translator to treat it "as C". But you can add an assertion that it is compatible with C code.

#include <type_traits>

struct myStruct
{
   int x;
   int y;
};

static_assert(std::is_pod_v<myStruct>, "Violated POD-ness of myStruct!");
StoryTeller - Unslander Monica
  • 165,132
  • 21
  • 377
  • 458
  • 1
    @wally: Because it's supposed to be `is_standard_layout`. `is_pod` is needlessly restrictive. – Nicol Bolas Dec 19 '17 at 13:54
  • 1
    @wally - IIRC any mention of "POD-ness" is being expunged from the core language in C++2a. So having a trait to that effect is just plain odd. – StoryTeller - Unslander Monica Dec 19 '17 at 14:04
  • @NicolBolas what is the difference between is_standard_layout and is_pod? I want to make sure that the layout is standard C layout and is not compiler dependent. – mans Dec 19 '17 at 15:23
  • @mans: There's no such thing as a non-compiler dependent "standard C layout". Each platform lays out objects in accord with their own ABI. And therefore, two different platforms need not have the same layout. Neither POD nor standard layout rules prevent a compiler on one platform from giving the struct a different layout from a compiler on another platform. This is true in C++ and in C. – Nicol Bolas Dec 19 '17 at 15:33