24-03-2021, 01:57 PM
Hi,
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:
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:
Now, since `Foo` contains a `std::string`, and `std::string` 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*`:
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:
`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::string`, and `std::string` 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?