The C++ Core Guidelines define three safety profiles: type, which bans reinterpreting a value as another type, bounds, which bans accessing beyond an array range, and lifetime, which bans leaks and use of invalid objects. Together with the Guidelines Support Library they give a coding style that removes many memory bugs from C++.
The three profiles
Per the Guidelines text:
- Type. No type violations, such as reinterpreting a T as a U through casts, unions or varargs.
- Bounds. No bounds violations, such as accessing beyond the range of an array.
- Lifetime. No leaks, which means failing to delete or deleting more than once, and no access to invalid objects such as dereferencing a null pointer or using a dangling reference.
Mapping to the earlier posts in this series, bounds covers the spatial family and lifetime covers much of the temporal family.
The support library
The Guidelines Support Library supplies two types that matter most here:
- span. Designates a half open sequence, so a pointer and its length travel together. That removes array decay and a common source of range errors.
- owner. Marks an owning raw pointer when old code cannot be changed, making clear that ownership is transferred.
Applying it without a rewrite
- Replace pointer plus length parameter pairs with a span, one module at a time.
- Replace manual new and delete with owning types, and use the owner marker where you cannot.
- Remove casts and unions that reinterpret data, or isolate them in one reviewed file.
- Turn on compiler warnings and a static analyzer that checks guideline rules, and fix what they report.
- Combine with a hardened standard library so a bad index traps.
What to expect
Style rules reduce bugs in code that follows them. They do not enforce themselves. This post does not confirm how far any particular compiler's checker supports the profiles today, so test your tool chain rather than assuming. The Chromium project, for comparison, writes that it may need custom C++ dialects enforced through compiler plugins and presubmit checks, and may even need to ban raw pointers.
Examples of each profile in code review
For the bounds profile, a reviewer looks for pointer arithmetic, calls that pass a pointer and a separate count, and indexing without a size check. Each one is a candidate for a span or a container.
For the lifetime profile, a reviewer looks for owning raw pointers, a manual delete, a reference or view stored longer than its source, and returning a reference to a local. Each is a candidate for an owning type, or at least for a comment that states who frees the memory.
For the type profile, a reviewer looks for C style casts, reinterpretation through unions and variadic functions. These are legal in C++ but defeat the compiler's ability to help, so move them into one small, reviewed place.
Make it part of the workflow
Add the three profile names to your pull request template as a short checklist. Link each item to an example in your own code base. A guideline that lives in a wiki nobody reads has no effect, while a checklist item on every review does.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a code scan points at the line behind a finding.
Quick check
Which profile covers use after free?
Lifetime. It covers access to invalid objects and double deletion.
Sources
Last reviewed: 19 October 2026.
