Default Constructors and PODs

I got what POD means, and I know that when I declare a structure in C ++ as

struct f {}; 

there is a default constructor, a default copy constructor, a default destructor, etc. (if I understood correctly)

My question is: how can I declare a POD structure with simple data (e.g. 4 int values) without implicit constructors / destructors / etc, interfering?

Did I miss something?

+2
source share
4 answers

Each type of object has a constructor - otherwise how would you build it? - and the destructor - otherwise, how will it be destroyed? They don’t “bother” anyone, because the default implementation is non-ops in the case of POD fields, as if you said:

 struct f { f() {} ~f() {} int a, b, c, d; }; 

However, if you write an empty constructor, the type becomes a non-POD. C ++ 11 resolves this with default:

 f() = default; ~f() = default; 

The situation is slightly different from copy constructors where implicitly generated is just a convenience that does the “right thing” for POD types:

 f(const f& other) : a(other.a), b(other.b), c(other.c), d(other.d) {} 

There is no reason to rewrite this yourself. If you want to make the type noncopyable, you can mark the copy constructor as deleted with f(const f&) = delete; or declare it private .

It is also important to note that member functions are not stored in the object as member variables. You can think of a class or struct as two things:

  • Data Layout Description

  • A namespace containing functions and types for managing this data

The C ++ object-oriented programming model simply combines these two things in one place.

+7
source

how can I declare a POD structure with simple data (e.g. 4 int values) without implicit constructors / destructors / etc, interfering?

Like this:

 struct f { int i1, i2, i3, i4; }; 

The constructors generated by the compiler do not prevent it from being a POD.

9 Classes [Class]

10) The structure of POD 109 is a non-unit class, which is both a trivial class and a standard layout class, and does not have non-static data members such as non-POD struct, non-POD union (or an array of such types). Similarly, a POD union is a union that is a trivial class and a standard layout class and has no non-static data members like non-POD struct, non-POD union (or an array of such types). The POD class is a class that is either a POD structure or a POD union.

So it should be

a) Trivial class and
b) Standard layout class.

which are described below:

7) The standard layout class is a class that:
- does not have non-static data elements such as non-standard layout (or an array of such types) or links,
- does not have virtual functions (10.3) and there are no virtual base classes (10.1),
- has the same access control (section 11) for all non-static data members,
- does not have base classes of non-standard layout,
- either does not have non-static data elements in the derived class itself and no more than one base class with
non-static data members or do not have base classes with non-static data members and
- does not have base classes of the same type as the first non-static data element.

and

6) [...] A trivial class is a class that has a trivial default constructor (12.1) and can be trivially copied

Detailed description:

12.1 Constructors [class.ctor]

5) [...] The default constructor is trivial if it is not provided by the user , and if:
- its class does not have virtual functions (10.3) and there are no virtual base classes (10.1) and
- the non-static data element of its class has a peer-to-peer-initializer mechanism and
- all direct base classes of its class have trivial default constructors and
- for all non-static data members of its class that belong to the class type (or its array), each such class has a trivial default constructor.

Like all of the above conditions, the class is a POD.

+5
source

First, all of these implicit member functions exist only conceptually. In fact, this does not affect until you actually try to use them. This means that they should not "interfere" if you do not want to.

Secondly, non-virtual member functions (whether explicitly declared or not) do not affect the data structure of the class. That is, they do not "interfere" in this regard (if this is what you had in mind).

+2
source

Yes, the definition of POD explicitly excludes implicitly created special member functions. It gets harder if you specify one of them that does exactly the same as the default: your type is no longer a POD. In C ++ 11, this problem is solved using the default keyword.

In this case, the definition of POD (usually) will be the same as that of the C code:

 struct X { int a, b, c, d; }; 
+1
source

Source: https://habr.com/ru/post/1208064/


All Articles