AUTOSAR C++14 Rule A8-5-2

Braced-initialization {}, without equals sign, shall be used for variable initialization

expand all in page

Description

Rule Definition

Braced-initialization {}, without equals sign, shall be used for variable initialization.

Rationale

Braced initialization:

classType Object{arg1, arg2, ...};
is less ambiguous than other forms of initialization. Braced initialization has the following advantages:

  • Prevents implicit narrowing conversions such as from double to float.

  • Avoids the ambiguous syntax that leads to the problem of most vexing parse.

    For instance, from the declaration:

    ResourceType aResource();
    It is not immediately clear if aResource is a function returning a variable of type ResourceType or an object of type ResourceType.

    For more information, see Ambiguous declaration syntax.

The rule also forbids the use of = sign for initialization because the = sign can give the impression that an assignment or copy constructor is invoked even in situations when it is not.

Polyspace Implementation

In general, the checker flags initializations of an object obj1 of data type Type using these formats:

  • Type obj1 = obj2;
  • Type obj1(obj2);

The checker allows an exception for these cases:

  • Initialization of variables with type auto using a simple assignment to a constant, a variable, a lambda expression, a standard initializer list or a function call.

  • Initialization of reference types using a simple assignment

  • Declarations with global scope using the format Type a() where Type is a class type with default constructor. The analysis interprets a as a function returning the type Type.

  • Loop variable initialization in OpenMP parallel for loops, that is, in for loop statements that immediately follow #pragma omp parallel for

The checker is enabled only if you specify a C++ version of C++11 or later. See C++ standard version (-cpp-version).

Troubleshooting

If you expect a rule violation but Polyspace® does not report it, see Diagnose Why Coding Standard Violations Do Not Appear as Expected.

Examples

expand all

class ResourceType {
      int memberOne;
      int memberTwo;
    public:
      ResourceType() {memberOne = 0; memberTwo = 0;}
      ResourceType(int m, int n) {memberOne = m; memberTwo = n;}
      ResourceType(ResourceType &anotherResource) {
          memberOne = anotherResource.memberTwo;
          memberTwo = anotherResource.memberOne;
      }
};

void func() {
    ResourceType aResourceOne(); //Noncompliant
    ResourceType aResourceTwo(1, 2); //Noncompliant
    ResourceType aResourceThree = {1,2};   //Noncompliant
     
    ResourceType aResourceFour{1,2}; //Compliant

}

In this example, the function func declares four objects of type ResourceType. Only the declaration of aResourceFour does not violate this rule.

The declarations of aResourceOne, aResourceTwo and aResourceThree violate the rule. In particular:

  • The declaration of aResourceOne suffers from the problem of most vexing parse. It is not clear whether aResourceOne is an object of type ResourceType or a function returning an object of type ResourceType.

  • The declaration of aResourceThree seems to suggest that the copy constructor ResourceType(ResourceType &) is invoked for initialization. The copy constructor initializes the data member memberOne to 2 and memberTwo to 1. However, the constructor ResourceType(int, int) is invoked. This constructor initializes the data member memberOne to 1 and memberTwo to 2.

Check Information

Group: Declarators
Category: Required, Automated

Version History

Introduced in R2019a

See Also

| | | | |

Topics