Page History

...

Noncompliant Code Example

In this This noncompliant code example , a nonstandard-layout type object is passed across execution boundaries. The object type is defined in a header file used by both a library and an application. The application creates an instance of the objectassumes a library, whose header is library.h, and an application (represented by application.cpp), and the library and application are not ABI-compatible. Therefore, the contents of library.h constitute an execution boundary. A nonstandard-layout type object S is passed across this execution boundary. The application creates an instance of an object of this type, then passes a reference to the object to a function defined by the library. However, in this code example, , crossing the execution boundary. Because the layout is not guaranteed to be compatible across execution boundaries because the compilers do not conform to the same ABI, and so it is a portability issue that the boundary, this results in unexpected behavior.

// library.h
struct S {
  virtual void f() { /* ... */ }
};
 
void func(S &s); // Implemented by the library, calls S::f()
 
// application.cpp
#include "library.h"
 
void g() {
  S s;
  func(s);
}

Compliant Solution

If Note that this example would be compliant if the library and the application conform to the same ABI, either explicitly through vendor documentation or implicitly by virtue of using the same compiler version to compile both.

 Compliant Solution

Because the library and the application, then the noncompliant code example is instead a compliant solution. However, because the library and application do not conform to the same ABI, the this compliant solution requires modification of modifies the library and application to work with a standard-layout type. This compliant solution Furthermore, it also adds a static_assert() to help guard against future code changes accidentally modifying S to no longer be a standard-layout type.

...