<![CDATA[MISRA Discussion Forums - 6.11 Member access control (C++)]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 15:13:52 +0000 MyBB <![CDATA[Rule 11-0-1 and POD types]]> https://forum.misra.org.uk/showthread.php?tid=1569 Wed, 24 Mar 2021 13:57:44 +0000 cgpzs]]> https://forum.misra.org.uk/showthread.php?tid=1569
I have a few questions about rule M11-0-1:

Rule 11–0–1
(Required)
Member data in non-POD class types shall be private.

* As posted in a previous question, "class types" here means "class, struct or union". Is my understanding correct?
* Why should the fact that a type is POD or not influence access control?

Let's have the following controversial example. Having the following POD type:

Code:
struct Foo
{  
   int x;
   int y;
};

The design for this struct is to aggregate 2 variables together, but there's no invariance to hold. x and y can vary independently. The struct is POD, so it's compliant with M11-0-1.

Now, in the future we want to extend `Foo` with another variable independent from x and y:

Code:
struct Foo
{
    int x;
    int y;
    std::string name;
};

Now, since `Foo` contains a `std:Confusedtring`, and `std:Confusedtring` is not a POD, then `Foo` becomes a non-POD. In turn, this now violates M11-0-1, which forces us to make these fields private. This leads to adding trivial boilerplate getters and setters to `Foo`, and every consumer of this struct needs to change their way of interacting with `Foo`.

This wouldn't happen if `name` was a `char const*`:

Code:
struct Foo
{
    int x;
    int y;
    char const* name;
};

The semantics of `Foo` are identical to before, just using a different type for one of its members. Why should that lead to such dramatic changes?

A similar example:

Code:
struct Bar
{
    std::vector points_x;
    std::vector points_y;
};

`Bar` is a collection of points that are independent from each other; there's no invariant.

Besides, POD types are types that are "compatible with the types used in the C programming language". Why should this be a concern if we are programming in C++? Why should we make our structs "C-compatible", if they are meant to be used in C++ code?]]>
I have a few questions about rule M11-0-1:

Rule 11–0–1
(Required)
Member data in non-POD class types shall be private.

* As posted in a previous question, "class types" here means "class, struct or union". Is my understanding correct?
* Why should the fact that a type is POD or not influence access control?

Let's have the following controversial example. Having the following POD type:

Code:
struct Foo
{  
   int x;
   int y;
};

The design for this struct is to aggregate 2 variables together, but there's no invariance to hold. x and y can vary independently. The struct is POD, so it's compliant with M11-0-1.

Now, in the future we want to extend `Foo` with another variable independent from x and y:

Code:
struct Foo
{
    int x;
    int y;
    std::string name;
};

Now, since `Foo` contains a `std:Confusedtring`, and `std:Confusedtring` is not a POD, then `Foo` becomes a non-POD. In turn, this now violates M11-0-1, which forces us to make these fields private. This leads to adding trivial boilerplate getters and setters to `Foo`, and every consumer of this struct needs to change their way of interacting with `Foo`.

This wouldn't happen if `name` was a `char const*`:

Code:
struct Foo
{
    int x;
    int y;
    char const* name;
};

The semantics of `Foo` are identical to before, just using a different type for one of its members. Why should that lead to such dramatic changes?

A similar example:

Code:
struct Bar
{
    std::vector points_x;
    std::vector points_y;
};

`Bar` is a collection of points that are independent from each other; there's no invariant.

Besides, POD types are types that are "compatible with the types used in the C programming language". Why should this be a concern if we are programming in C++? Why should we make our structs "C-compatible", if they are meant to be used in C++ code?]]> <![CDATA[Rule 11-0-1 and protected members]]> https://forum.misra.org.uk/showthread.php?tid=1355 Mon, 03 Jul 2017 14:42:21 +0000 tw39124]]> https://forum.misra.org.uk/showthread.php?tid=1355
I fail to see how protected members diminish the "control" over the object state that the implementation has. Can someone explain in more detail why protected member variables specifically are disallowed? A subtype has an "is-a" relationship with the base type, after all, so I don't see why it shouldn't benefit from inheriting the base type's member variables.]]>
I fail to see how protected members diminish the "control" over the object state that the implementation has. Can someone explain in more detail why protected member variables specifically are disallowed? A subtype has an "is-a" relationship with the base type, after all, so I don't see why it shouldn't benefit from inheriting the base type's member variables.]]> <![CDATA[Clarification for rule 11-0-1]]> https://forum.misra.org.uk/showthread.php?tid=1295 Thu, 01 Dec 2016 13:40:58 +0000 dg1980]]> https://forum.misra.org.uk/showthread.php?tid=1295
the rule text only mentions classes, not structs.
Now, in C++ struct and class are synonyms, except that by default everything is public in a struct.
So, does this rule implicitly apply to all structs as well?
Thank you.]]>
the rule text only mentions classes, not structs.
Now, in C++ struct and class are synonyms, except that by default everything is public in a struct.
So, does this rule implicitly apply to all structs as well?
Thank you.]]> <![CDATA[11.0.1 and static data members]]> https://forum.misra.org.uk/showthread.php?tid=1263 Fri, 08 Jul 2016 15:46:04 +0000 grunwald]]> https://forum.misra.org.uk/showthread.php?tid=1263
In particular, I'm interested whether the constant in this code violates 11.0.1:

Code:
class MyClass {
    std::string non_pod_class;
public:
    static const int CONSTANT = 10;
};

const int MyClass::CONSTANT;
]]>
In particular, I'm interested whether the constant in this code violates 11.0.1:

Code:
class MyClass {
    std::string non_pod_class;
public:
    static const int CONSTANT = 10;
};

const int MyClass::CONSTANT;
]]> <![CDATA[Use of STL, friend, reinterpret_cast etc..]]> https://forum.misra.org.uk/showthread.php?tid=653 Thu, 07 May 2009 17:18:27 +0000 vijayendra]]> https://forum.misra.org.uk/showthread.php?tid=653 1. Use of STL (cstring, vector etc) which are internally based on dynamic allocations
2. Use of friend keyword to access private members of another class
3. Use of reinterpret_cast
4. Use of struct rather than classes - in case the set of data does not have specific operations on it, hence no need to encapsulate them in a class
5. Casting from struct to byte pointer - usually needed to send set of data like array of struct
6. Use of string functions which are not unbounded, e.g. strncpy, memcpy, bcopy, memset etc. All these functions accept size as an argument and access only the given area in memory.

Can you pl. clarify the guidelines on the above?]]> 1. Use of STL (cstring, vector etc) which are internally based on dynamic allocations
2. Use of friend keyword to access private members of another class
3. Use of reinterpret_cast
4. Use of struct rather than classes - in case the set of data does not have specific operations on it, hence no need to encapsulate them in a class
5. Casting from struct to byte pointer - usually needed to send set of data like array of struct
6. Use of string functions which are not unbounded, e.g. strncpy, memcpy, bcopy, memset etc. All these functions accept size as an argument and access only the given area in memory.

Can you pl. clarify the guidelines on the above?]]> <![CDATA[Can I get by with a little help from My Friends?]]> https://forum.misra.org.uk/showthread.php?tid=582 Fri, 12 Sep 2008 18:50:36 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=582
Quote:Member data in non-POD class types shall be private.
with the rationale:
Quote:By implementing class interfaces with member functions, the implementation retains more control over how the object state can be modified, and helps to allow a class to be maintained without affecting clients.
Does the above mean non-POD structure types should not contain any friend declarations? A friend declaration would by definition allow for the circumvention of the access restrictions.]]>
Quote:Member data in non-POD class types shall be private.
with the rationale:
Quote:By implementing class interfaces with member functions, the implementation retains more control over how the object state can be modified, and helps to allow a class to be maintained without affecting clients.
Does the above mean non-POD structure types should not contain any friend declarations? A friend declaration would by definition allow for the circumvention of the access restrictions.]]>