MISRA Discussion Forums - 4.15 Special member functions

Rule 15.1.2

Thu, 19 Feb 2026 13:33:04 +0000

Hi,

We are having a discussion internally about how to interpret rule 15.1.2. In particular, the rule exception says that a class is considered empty "when it has [...], no virtual member functions, [...]".
The question is whether a virtual (defaulted) destructor is considered a virtual member function in this context. For example, whether the following class is considered empty or not for the sake of this rule:

Code:
struct Base () {

    virtual ~Base() = default;

};

My personal interpretation is that this class is not considered empty (it will contain the v-table), so it does not qualify as an exception w.r.t. rule 15.2 when used as a base class. Can you confirm that this interpretation is correct?

Thank you very much and best regards,
Daniel "Merge" Merget

15.1.4 potentially incomplete wording

Fri, 16 Jan 2026 13:09:53 +0000

Hi,

For the following code, to the best of our knowledge, the C++ standard guarantees that m1 and m2 are both properly initialized when creating an object of type C ([class.base.init]p9 and [dcl.init]p7).

Code:
class M { M() {} };

class C {

  M m1;

  M m2[2];

  C() {}

};

However, being strict with the amplification given for rule 15.1.4, data member m2 cannot be considered initialized: neither is C() delegating, nor does m2 have a default member initializer, nor does it appear in the member initialization list, nor does its (array) type feature a constructor.
m1 is considered initialized as its type M has a constructor.

We think the code example should be compliant, but the rule amplification wording seems incomplete.
Can you confirm this interpretation or do we miss a reason for this code to be non-compliant w.r.t. 15.1.4?

Thanks in advance!

Application of Rule 15.0.1 to Abstract Interface Classes

Tue, 14 May 2024 18:19:24 +0000

It seems rule 15.0.1 has conflicting requirements for pure virtual / abstract classes with no data members. e.g. if we create the following classes:

Code:
class CanMessage {

public:

  CanMessage();

  // Required for inheritance

  virtual ~CanMessage() = default;

  // Want to move and copy through derived classes

  CanMessage(const CanMessage&) noexcept = default;

  CanMessage(CanMessage&&) noexcept = default;

  CanMessage& operator=(const CanMessage&) & noexcept = default;

  CanMessage& operator=(CanMessage&&) & noexcept = default;

  virtual uint32_t Id() = 0;

  virtual uint8_t DataLength() = 0;

  virtual std::span Data() = 0;

};

class CanClassicMessage : public CanMessage {

public:

  CanClassicMessage(uint32_t id, uint8_t data_length) : CanMessage{}, id_{id} data_length_{data_length} {}

  ~CanClassicMessage() noexcept override = default;

  CanClassicMessage(const CanClassicMessage&) noexcept = default;

  CanClassicMessage(CanClassicMessage&&) noexcept = default;

  CanClassicMessage& operator=(const CanClassicMessage&) & noexcept = default;

  CanClassicMessage& operator=(CanClassicMessage&&) & noexcept = default;

  uint32_t Id() override { return id_; }

  uint8_t DataLength() override { return data_length_; }

  std::span Data() { return data_; }

private:

  uint32_t id_;

  uint8_t data_length_;

  std::array data_;

};

class CanFDMessage : public CanMessage {

public:

  CanFDMessage(uint32_t id, uint8_t data_length) : CanMessage{}, id_{id} data_length_{data_length} {}

  ~CanFDMessage() noexcept override = default;

  CanFDMessage(const CanFDMessage&) noexcept = default;

  CanFDMessage(CanFDMessage&&) noexcept = default;

  CanFDMessage& operator=(const CanFDMessage&) & noexcept = default;

  CanFDMessage& operator=(CanFDMessage&&) & noexcept = default;

  uint32_t Id() override { return id_; }

  uint8_t DataLength() override { return data_length_; }

  std::span Data() { return data_; }

private:

  uint32_t id_;

  uint8_t data_length_;

  std::array data_;

}

Per the rule, we either need

a protected non-virtual destructor.
Unmovable class that has a public virtual destructor.

However these prevent us from being able to create a std::unique_ptr to the base class (and allow the derived classes to manage their data through their destructors), or prevents us from being able to copy or move one CanClassicMessage to another CanClassicMessage, if the base copy/move constructors are deleted.

There is an exception for Aggreagate types, but it seems there needs to be an other one for an Interface/Abstract class which holds no data.