C++ Style Comparison: Google Style Guide vs CppCore Guidelines

[AlexanderLanin]

Intro

We'll follow MISRA, that's not the question here. The core guidelines is an alternative to MISRA (no judgement here), however that's not the point of this comparison. Here I want to focus on "style" only. Whatever "style" means.
I'll attempt to map the guidelines and highlight the differences.
No idea whether that will work out or not.

References

• Google C++ Style Guide (no specific version, accessed in 2025-03)
• C++ Core Guidelines (no specific version, accessed in 2025-03)
• Guidelines for the use of the C++14 language in critical and safety-related systems (Version 19-03... although the link states 22-11???)

Mapping

We'll use the categories from the Google Style Guide, as they provide a clearer structure.

Caution

The following is provided by ChatGPT. ChatGPT can make mistakes. Check important info.

---

Google C++ Style Rule	C++ Core Guidelines	AUTOSAR C++14	Summary
C++ Version (target C++20)	⚠️ No explicit rule. Core Guidelines assume use of modern C++ (they reference C++17/20 features) – generally in line with using latest standard (Google C++ Style Guide).	❌ Conflict. AUTOSAR rules are based on C++14 ([[PDF] Coverity Support for AUTOSAR Coding Standards	Black Duck](https://www.blackduck.com/content/dam/black-duck/en-us/datasheets/ds-coverity-autosar-standards.pdf#:~:text=,Automated)), so C++20-only features (e.g. concepts, designated init) are not allowed.
Self-contained Headers (each header compiles on its own)	✅ Aligned. Core Guideline SF.11: “Header files should be self-contained” (SF: Source files – C++) – headers must include all prerequisites.	✅ Aligned. Rule A3-1-1: “It shall be possible to include any header in multiple TUs without ODR violations” (Guidelines for the use of the C++14 language in critical and safety-related systems) (i.e., headers must be self-sufficient).	Headers self-sufficient – All require headers to include what they need so they compile standalone.
The #define Guard (header include guards)	✅ Aligned. Core Guideline SF.8: “Use #include guards for all .h files” (SF: Source files – C++). Also advises making guard unique (e.g. include project/component in macro) (SF: Source files – C++).	✅ Aligned. Rule A3-1-2: Headers must have include guards. AUTOSAR forbids other multiple-inclusion techniques (Guidelines for the use of the C++14 language in critical and safety-related systems) (pragma once not standardized).	Include guards – All standards require include guards in headers (unique macro names, e.g. PROJECT_PATH_FILE_H_).
Include What You Use (no reliance on transitive includes)	✅ Aligned. Core Guidelines advise including all needed headers (don’t depend on indirect includes) (SF: Source files – C++) (SF: Source files – C++). E.g., SF.10 forbids usage of symbols without including their defining header.	✅ Aligned. AUTOSAR (via MISRA C++ 3-1-1) requires that any header can be included alone, implying it must include its dependencies (Guidelines for the use of the C++14 language in critical and safety-related systems). (No implicit reliance on includes from other headers.)	Direct includes – All agree: every file should include headers for symbols it uses (no transitive include reliance).
Forward Declarations (avoid where possible)	⚠️ Partial. No specific core rule forbidding forward declarations. Core encourages minimizing dependencies, but forward declarations are acceptable to reduce coupling (as long as ODR is not broken). No direct guideline; implicitly allowed when appropriate.	⚠️ Partial. AUTOSAR has no explicit rule against forward declarations. Forward declarations can be used if needed for efficiency, as long as they don’t violate ODR or other rules.	Forward declarations – Google discourages them (include headers instead), whereas Core/AUTOSAR permit them when useful. (All agree forward decls must not break ODR or clarity.)
Inline Functions (define inline only if small)	✅ Aligned. Core Guidelines prefer not to expose large functions in headers. Non-trivial functions should be out-of-line. (E.g., SF.2 forbids non-inline function definitions in headers (SF: Source files – C++), implying only small functions inline.)	✅ Aligned. AUTOSAR follows the same principle: avoid inline definitions for non-trivial functions (for maintainability and to prevent code bloat). No explicit size limit, but functions should be inline only if very simple.	Inline sparingly – Inline only small, trivial functions (≈10 lines or fewer) in all standards. Larger functions should be defined in source files (not inline).
Names and Order of Includes (include order: related header, then C, C++, others…)	⚠️ Partial. Core Guidelines do not mandate a specific include order beyond logical grouping. They do recommend using quotes "" for project headers and <> for others (SF.12 (SF: Source files – C++)) and to include headers before other declarations (SF: Source files – C++). No fixed global->local order rule, but consistency is advised.	⚠️ Partial. AUTOSAR does not specify a strict include order. (It emphasizes avoiding order-dependent behavior (AUTOSAR C++14 Rule M7-3-6 - MathWorks).) Common practice is to include standard library headers before project headers, but this is not a formal rule in AUTOSAR.	Include order – Google prescribes an order (own header, then system, then project). Core/AUTOSAR do not enforce a specific order (just use a consistent, logical order and correct include syntax). No fundamental conflict – just a style preference.
Namespaces (all code in a namespace, no using-directives)	✅ Aligned. Core Guidelines: SF.20: “Use namespaces to express logical structure” (SF: Source files – C++). They also forbid using namespace at global scope in headers (SF.7 (SF: Source files – C++)). All code should be in namespaces (except main or special cases).	✅ Aligned. AUTOSAR requires naming namespaces and forbids using namespace (e.g., MISRA C++ 2008 Rule 7-3-4 forbids unnamed namespaces in headers and Rule 7-3-5 forbids using-directives in headers (Guidelines for the use of the C++14 language in critical and safety-related systems)). Code is expected to be organized into namespaces (to avoid name collisions).	Namespaces – All agree to wrap code in namespaces (with project-unique names) and avoid using namespace at global scope. (Unnamed namespaces for internal linkage are allowed in .cpp, but not in headers.)
Internal Linkage (unnamed namespaces or static for internal definitions)	✅ Aligned. Core Guideline SF.22: Use unnamed namespaces for “internal” (non-exported) entities (SF: Source files – C++). Also, avoid unnamed namespaces in headers (SF.21). In .cpp files, static or unnamed namespace is recommended for internal linkage.	✅ Aligned. AUTOSAR/MISRA require that objects/functions not intended for use outside a file have internal linkage. E.g., Rule 7-5-1 (MISRA C++) requires internal objects to be static or in an unnamed namespace. AUTOSAR echoes this to keep internal symbols local to the translation unit.	Internal linkage – All standards advise giving internal symbols internal linkage (via static or unnamed namespace) in implementation files, to avoid polluting global namespace and prevent ODR violations.
Nonmember, Static Member, and Global Functions (avoid global functions, no “static method only” classes)	✅ Aligned. Core Guidelines: Prefer free functions or namespace-scope functions to static class methods when no object state is needed (Principle of free functions). Also, I.2: “Avoid non-const global variables” (C++ Core Guidelines - GitHub Pages) (which extends to minimizing global state). Core encourages designing modules without unnecessary singletons or global functions if not needed.	✅ Aligned. AUTOSAR advises minimizing global functions and objects. There’s no explicit AUTOSAR rule against “all-static” utility classes, but best practice in AUTOSAR is to use namespaces or free functions for utilities (and avoid global mutable state). Global functions are allowed if necessary, but should be used judiciously.	Global vs. member – All agree to avoid unnecessary global state/functions. Use free functions (in namespaces) for utilities rather than static-member-only classes, and limit truly global functions. (Google explicitly bans classes that exist only to group static functions; Core/AUTOSAR share that intent.)
Local Variables (minimize scope, initialize where declared)	✅ Aligned. Core Guideline ES.26 (and others) emphasize declaring variables in the smallest possible scope and initializing upon declaration ([PDF] C++ Coding Standards for EECS 381). This is an established C++ best practice and is encouraged throughout the Core Guidelines.	✅ Aligned. AUTOSAR (via MISRA C++ 8-0-1) advises that variables should be defined in the scope that requires them and initialized when declared. This avoids usage of uninitialized variables and makes code clearer.	Narrow scope – All agree: declare variables in the narrowest scope possible and initialize them immediately ([PDF] C++ Coding Standards for EECS 381). This improves readability and reduces errors.
Static and Global Variables (forbid non-trivial static objects)	⚠️ Partial. Core Guidelines I.2: “Avoid non-const global variables” (C++ Core Guidelines - GitHub Pages) – Core is even stricter, recommending no non-const global unless absolutely necessary. Google’s rule forbids globals with non-trivial destructors (due to static init/destruction order issues), which aligns with avoiding most global state. Core also warns about static initialization fiasco, suggesting to prefer trivial or constant initialization for static objects.	✅ Aligned. AUTOSAR Rule A3-3-2: “Non-POD type objects with static storage duration shall not be used” (Guidelines for the use of the C++14 language in critical and safety-related systems). This is effectively the same as Google’s rule (only trivial types or POD allowed as global statics). AUTOSAR allows POD globals but generally discourages mutable global state for safety.	Static objects – All ban or discourage non-trivial global/static objects. Google/AUTOSAR explicitly forbid static objects with non-trivial destructors (to avoid static init/destruct order issues) (Guidelines for the use of the C++14 language in critical and safety-related systems). Core Guidelines similarly avoid global state (and recommend const or literal initialization if used). (Core is stricter about global mutability, while Google/AUTOSAR focus on destructor issues.)
thread_local Variables (must have constexpr initializers)	⚠️ Partial. Core Guidelines have no special rule for thread_local. They implicitly allow thread_local usage. Best practice in core/C++ is that thread_local objects follow the same rules as other static-duration objects regarding initialization (const-initialized if possible). Core would expect thread_local to be used judiciously (e.g., for POD types or with constant initialization to avoid surprises).	⚠️ Partial. AUTOSAR has no explicit rule on thread_local (which is a C++11 feature). AUTOSAR emphasizes that any static-duration object (including thread_local) should have deterministic initialization. There is an expectation (not a formal rule) to initialize thread_local variables with constant expressions to avoid dynamic initialization issues at runtime, in line with Google’s rule.	thread_local init – Google requires thread_local variables to be initialized with a compile-time constant (prevent dynamic init) (Google C++ Style Guide). Core/AUTOSAR do not explicitly call this out, but implicitly prefer static-duration objects (including thread_local) to have constant initialization for safety. No direct conflict – more of a Google-specific emphasis.
Doing Work in Constructors (avoid complex or failing work in ctors)	⚠️ Partial. Core Guidelines agree on avoiding calling virtual functions in constructors (C.82: “Don’t call virtual functions in constructors or destructors” (C: Classes and class hierarchies - C++ Core Guidelines)). They also suggest using factory functions if object creation can fail (since core allows exceptions, throwing in ctor is an acceptable way to signal failure). Core does not forbid all failing work – it encourages using exceptions for constructor errors (Google C++ Style Guide) (Google C++ Style Guide).	⚠️ Partial. AUTOSAR also advises against calling virtual methods in constructors (to avoid surprises). Exceptions in constructors are allowed in AUTOSAR (they follow MISRA’s “exceptions only for error handling” (Guidelines for the use of the C++14 language in critical and safety-related systems) and do not ban throwing). So AUTOSAR differs from Google in that it permits exceptions for ctor failures.	Constructors – All agree not to call virtual methods during construction (object not fully formed) (C: Classes and class hierarchies - C++ Core Guidelines). Google additionally forbids any error that can’t be handled (since exceptions are banned, they prefer factory functions for failures) (Google C++ Style Guide) (Google C++ Style Guide). Core/AUTOSAR allow exceptions in ctors for error handling, so they don’t require separate init functions in those cases.
Implicit Conversions (single-arg ctor/operator must be explicit)	✅ Aligned. Core Guideline C.46: “By default, declare single-argument constructors explicit” (C: Classes and class hierarchies – C++) (C: Classes and class hierarchies – C++). Core also requires conversion operators to be marked explicit (in C++11 and above) unless truly intended to be implicit. This matches Google’s rule to not allow implicit conversions.	✅ Aligned. AUTOSAR (MISRA C++ 2008 Rule 12-1-3) requires that constructors callable with a single argument of fundamental or enum type be explicit (Guidelines for the use of the C++14 language in critical and safety-related systems). In practice, AUTOSAR insists on explicit for single-parameter ctors to prevent unintended conversions.	explicit – All enforce using the explicit keyword for single-argument constructors and conversion operators to avoid unintended implicit conversions (Google C++ Style Guide) (C: Classes and class hierarchies – C++). (Copy/move constructors are exceptions and remain non-explicit.)
Copyable and Movable Types (specify copy/move support or deletion)	✅ Aligned. Core Guidelines have extensive rules for copy/move. C.21 and others: if a class should not be copyable, =delete the copy operations; if it is copyable, ensure the copy ctor and assign are defined or defaulted. They also advise making move operations noexcept and default or delete as needed (C: Classes and class hierarchies – C++). This aligns with Google’s requirement to explicitly declare or delete copy/move constructors and operators so the class’s copyability is clear (Google C++ Style Guide) (Google C++ Style Guide).	✅ Aligned. AUTOSAR requires following the Rule of Three/Five. For example, if a class defines a destructor or copy ctor, it should define (or explicitly =delete) the others. This is inherited from MISRA C++ (e.g., Rule 12-8-1/2). AUTOSAR emphasizes that a class’s copy and move behavior be clear and safe (similar to Google’s guidance).	Copy/Move semantics – All agree that a class should explicitly declare its copy/move constructors and assignment operators (or delete them) to make its value semantics clear (Google C++ Style Guide). Copyable classes should behave like values; move-only or non-copyable classes should disable copying.
Structs vs. Classes (use struct for passive data objects)	⚠️ Partial. Core Guidelines do not set a hard rule for struct vs class. They note that struct and class differ only by default access. However, the intent (as per C++ community practice) is similar to Google’s: use struct for simple data aggregates with public data and no invariants, and use class for types with invariants or complex behavior. (This isn’t an explicit Core rule, but it’s a common guideline consistent with Google’s.)	⚠️ Partial. AUTOSAR doesn’t mandate choosing struct or class based on content. It treats them interchangeably except for access control. Typically, AUTOSAR code will use class for most user-defined types (with appropriate access specifiers), but this is not a strict rule. There is no prohibition on using struct for POD types; it’s left to project style.	struct vs class – Google explicitly says to use struct only for plain data holders (all-public, no invariants) (Google C++ Style Guide) (Google C++ Style Guide). Core/AUTOSAR do not have a formal rule, but generally agree in spirit: if an object has no invariants and is just data, struct is acceptable. (It’s a matter of style; not enforced outside Google.)
Structs vs. Pairs/Tuples (prefer meaningful struct over std::pair/std::tuple)	⚠️ Partial. The Core Guidelines don’t explicitly mention this, but they emphasize self-documenting code. Using a named struct with clear field names can be considered more readable than an anonymous std::pair or std::tuple. (In the community, it’s advised to use pair/tuple only for very short-lived or obvious cases; otherwise define a struct.) So core’s philosophy aligns, though no explicit rule text.	⚠️ Partial. AUTOSAR has no specific rule here. However, readability is a general concern in safety code. Defining a struct with named members is not mandated but is often encouraged for clarity over using raw std::pair or std::tuple. (AUTOSAR does allow std::pair and std::tuple since they are part of C++14, but expects judicious use.)	Named structs – Google prefers a custom struct with well-named fields over std::pair or std::tuple for readability (Google C++ Style Guide). Core and AUTOSAR have no formal rule, but generally value clarity – using a struct with descriptive member names is usually recommended for maintainability (especially in long-lived or widely used interfaces).
Inheritance (composition vs inheritance, public only for “is-a”)	✅ Aligned. Core Guidelines: “Prefer composition to inheritance unless inheritance is required” (various rules). C.128 and C.135: multiple inheritance should be used only for combining independent base interfaces (Guidelines for the use of the C++14 language in critical and safety-related systems). Core says make base classes abstract if they’re not meant to be object instances (to avoid slicing), and mark overrides with override. These match Google’s points (only use public inheritance for true is-a, minimize multiple/base classes).	✅ Aligned. AUTOSAR echoes MISRA C++ rules: e.g., Rule 10-3-1: base classes should be abstract if derived objects are sliced (no slicing). Multiple inheritance is heavily restricted – AUTOSAR permits at most one concrete base with interfaces (JSF AV Rule 88) (Guidelines for the use of the C++14 language in critical and safety-related systems). Public inheritance should model is-a; private inheritance is discouraged (use composition instead).	Inheritance design – All agree on restrained use of inheritance. Use public inheritance only for true subtype relationships (“is-a”). Avoid multiple inheritance of implementation (if using MI, it should be multiple interfaces) (Guidelines for the use of the C++14 language in critical and safety-related systems). Prefer composition over inheritance for code reuse. (Google and AUTOSAR also remind to mark overrides and use final appropriately; core has similar guidance with the override specifier.)
Operator Overloading (only overload with conventional meaning)	✅ Aligned. Core Guidelines provide many rules for operators (e.g., don’t overload `&&,		, ,because you can’t replicate short-circuit or sequencing semantics). **C.162**–**C.168** cover overloading conventions (e.g., if you overload==, also overload !=, etc.). They align with Google’s note to overload operators judiciously and only in intuitive ways ([Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html#:~:text=Operator%20Overloading)) ([Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html#:~:text=,may%20require%20a%20search%20tool)). Core also discourages user-defined literals in most cases (no specific rule, but they are rarely used in the standard library except for suffixes like _s` etc.).
Function Overloading (only if semantics identical)	⚠️ Partial. Core Guidelines allow overloading freely but stress that overloads should represent the same logical operation on different parameters. They warn against overloading in ways that could confuse (e.g., drastically different behavior for different arg types). For instance, having overloads that do the same thing on string and const char* is fine, but if semantics differ, use different function names. (This is in line with Google’s rule, though core doesn’t have a single rule number for it – it’s general advice.)	⚠️ Partial. AUTOSAR has no explicit rule on overloading, but it inherits C++ standard behavior. The expectation is the same: functions overloaded should perform similar tasks. If an overload would do something unrelated, that would be a design smell. AUTOSAR focuses on safety, so as long as overloads aren’t ambiguous or misleading, it’s acceptable. Default arguments vs overloads are left to the project’s style (AUTOSAR doesn’t forbid either, but both must follow MISRA rules if used).	Overloads – All agree in principle: overload functions only when they conceptually perform the same operation. Google explicitly emphasizes this (Google C++ Style Guide). Core and AUTOSAR implicitly follow that for clarity. (If different semantics are needed, choose a different function name rather than overload.) Overloading purely for convenience is fine (e.g., different types) as long as it doesn’t confuse the reader about the function’s intent.
Default Arguments (be mindful, prefer overloads if unsure)	✅ Aligned. Core Guidelines permit default arguments. They caution to avoid defaults on virtual functions (C.140: don’t redefine default for overrides (C++ Core Guidelines: The Remaining Rules about Class Hierarchies)) – Google also bans default params on virtuals (Google C++ Style Guide). Core notes that default args and overloads are two ways to achieve the same goal, and each has trade-offs (no outright ban on either) (F: Functions - C++ Core Guidelines). This aligns with Google’s stance to use default args when it clearly improves readability, otherwise consider overloads (Google C++ Style Guide) (Google C++ Style Guide).	✅ Aligned. AUTOSAR allows default arguments (they are part of C++14). It follows the same restrictions: default arguments should not be used on virtual functions (to avoid confusion when overridden). MISRA C++ 2008 had Rule 8-4-2 prohibiting default parameters on virtual methods, which AUTOSAR adopts. In general, AUTOSAR doesn’t discourage default parameters otherwise, as long as they don’t introduce ambiguity.	Default parameters – All three allow default function arguments on non-virtual functions. They agree not to use defaults for virtual functions (due to dynamic dispatch vs static default binding issues) (Google C++ Style Guide). Google leans toward using overloads for complex cases for clarity, but this is a matter of judgment. Core/AUTOSAR similarly leave it to the developer but emphasize consistency and caution in use.
Trailing Return Type Syntax (auto func() -> Type)	✅ Aligned. Core Guidelines have no objection to trailing return types. They note it can be useful in template code or with lambdas. Generally, core suggests using the normal pre-declaration return type for clarity except in cases where trailing syntax improves readability (e.g., in function templates where the return type depends on template parameters). This matches Google: “use trailing return only when it significantly clarifies or is required” (Google C++ Style Guide) (Google C++ Style Guide).	✅ Aligned. AUTOSAR allows trailing return types (it’s a standard C++11 feature). There’s no specific rule forbidding or requiring it. It’s expected to be used in scenarios like templates or in conjunction with decltype. For typical functions, AUTOSAR code usually uses the conventional return type syntax, aligning with Google’s advice to prefer the ordinary syntax unless trailing form is clearer.	Trailing return types – All agree that the ordinary return type syntax is preferred in general, and the trailing -> Type syntax should be used only when it improves readability (e.g., in complex template situations or for lambda declarations) (Google C++ Style Guide). No guideline forbids it – it’s a matter of clarity. Google explicitly advises against overusing trailing returns, which is consistent with general practice.
Inputs and Outputs (function param passing)	✅ Aligned. Core Guidelines (e.g., F.20 & F.21 in Functions) advise: use return values for output rather than output parameters when possible (F: Functions - C++ Core Guidelines). They also suggest passing inputs as const T& or value, and using pointers or references only for in-out parameters, which mirrors Google’s rules for parameter passing (inputs by value or const-ref, outputs as pointer or returned) (Google C++ Style Guide) (Google C++ Style Guide).	✅ Aligned. AUTOSAR follows standard C++ best practices for parameter passing. Although not explicitly spelled out in a rule, AUTOSAR (and MISRA) prefer that functions return results rather than use non-const reference parameters for outputs. Optional output parameters should be pointers that can be null to indicate “no output” (this is exactly Google’s pattern). These conventions are widely adopted in AUTOSAR-based code for clarity and safety.	Parameter passing – All three share the same conventions for function parameters: inputs should be values or const& (and use std::optional if an input is optional), outputs should ideally be returned or, if multiple outputs, passed as pointers (which can be null to signify “unused”) (Google C++ Style Guide). This makes it clear at call sites what is an out-param. Google’s specific guidance on using pointers for optional outputs is consistent with AUTOSAR practices.
Write Short Functions (keep functions limited in length and focus)	⚠️ Partial. Core Guidelines don’t set a numeric line limit, but they encourage keeping functions logically small and focused. They emphasize that each function should do one thing well (Single Responsibility). Long functions aren’t outright forbidden, but the guidance is to refactor if it aids clarity or reuse. This aligns with Google’s advice (no hard limit, but ~40 lines as a soft guideline) (Google C++ Style Guide) (Google C++ Style Guide).	⚠️ Partial. AUTOSAR does not impose a strict function length limit. However, in practice, readability and traceability in safety code means functions should be understandable and not overly long. AUTOSAR documents (like development guidelines) often suggest keeping functions manageable in size. It’s a recommendation rather than a rule – similar in spirit to Google’s style.	Function length – All agree in principle that functions should be as short as practical for readability and maintainability. Google gives a ballpark of 40 lines as a cue to consider refactoring (Google C++ Style Guide). Core/AUTOSAR similarly value clarity but have no fixed line count – they rely on the programmer’s judgment. (No conflict; it’s a soft rule everywhere.)
Exceptions (use of C++ exceptions)	❌ Conflict. Core Guidelines encourage using exceptions for error handling. E.3: “Use exceptions for error handling only” (Guidelines for the use of the C++14 language in critical and safety-related systems) – implying exceptions are the preferred mechanism for errors (not for normal flow). Google’s rule flatly forbids exceptions (Google C++ Style Guide), which is directly opposite to Core’s guidance. Core Guidelines assume exceptions are enabled and provide numerous rules on how to use them safely, whereas Google turns them off entirely.	❌ Conflict. AUTOSAR allows exceptions but restricts their use: they should only be used for error conditions, not normal flow (MISRA C++ 15-0-1 and AUTOSAR rules require exceptions to signal “can’t happen” errors only (Guidelines for the use of the C++14 language in critical and safety-related systems)). AUTOSAR explicitly rejected a rule that would ban exceptions altogether (Guidelines for the use of the C++14 language in critical and safety-related systems). Thus, AUTOSAR code can throw/catch exceptions for error handling in controlled ways. This conflicts with Google, which disallows using exceptions at all.	Exceptions – Google bans C++ exceptions in all code (Google C++ Style Guide). In contrast, Core Guidelines and AUTOSAR allow exceptions for error handling (and prefer them for that purpose) (Guidelines for the use of the C++14 language in critical and safety-related systems). AUTOSAR and Core both mandate not using exceptions for routine control flow, only for errors – but they fundamentally diverge from Google’s blanket no-exception policy.
noexcept (use of noexcept specifier)	✅ Aligned. Core Guidelines recommend using noexcept for functions that are not supposed to throw. For example, move constructors/assignments should be noexcept (C.66). They caution that noexcept should reflect true no-throw guarantees. This aligns with Google’s advice to mark functions noexcept when they won’t/can’t throw (especially important in exception-enabled code for optimization) (Google C++ Style Guide) (Google C++ Style Guide).	✅ Aligned. AUTOSAR encourages noexcept for functions that are guaranteed not to throw (since AUTOSAR allows exceptions, noexcept helps optimizations and clarity). There’s an AUTOSAR rule (A15-3-3) that destructors should be noexcept by default, and recommendations to declare move constructors noexcept. No conflict here with Google, which also suggests noexcept where applicable (even though Google’s code typically doesn’t throw, they use noexcept for things like move ops).	noexcept usage – All agree on using noexcept for functions that are meant not to throw (particularly special member functions like moves) (Google C++ Style Guide). Google notes it’s hard to guarantee in exception-disabled builds, but still encourages marking functions noexcept for clarity/performance. Core and AUTOSAR, working with exceptions, explicitly use noexcept to enable optimizations (e.g., in containers) and to denote non-throwing functions.
Run-Time Type Information (RTTI) (dynamic_cast, typeid)	⚠️ Partial. Core Guidelines do not forbid RTTI but advise designing without it if possible. C.131: “Avoid casting down to derived” (i.e., prefer polymorphic interfaces to checks). They accept that dynamic_cast/typeid have legitimate uses (when type-safe downcast is needed), but suggest alternatives like visitor pattern or virtual functions first. This is less strict than Google’s “avoid RTTI” stance (Google C++ Style Guide) (Google C++ Style Guide).	✅ Aligned. AUTOSAR (MISRA C++ 2008 Rule 5-2-8) effectively bans dynamic_cast in safety critical code. The AUTOSAR guidelines say RTTI “is prone to abuse” and should be avoided. It permits it only in test or very controlled scenarios. This is very close to Google’s rule to avoid RTTI (Google C++ Style Guide) (Google C++ Style Guide). (If RTTI-like behavior is needed, AUTOSAR would prefer alternative designs as well.)	RTTI – Google urges avoiding RTTI entirely in production code (use polymorphism or other patterns instead) (Google C++ Style Guide). Core Guidelines also prefer alternative solutions but do not ban using dynamic_cast when necessary (they consider it a tool for specific cases). AUTOSAR is closer to Google here: RTTI is essentially forbidden in high-integrity code. Summary: Google/AUTOSAR disallow or strongly discourage RTTI; Core allows it with caution.
Casting (use C++ casts or braces, not C-style casts)	✅ Aligned. Core Guidelines: ES.49 and ES.50 advise to avoid C-style casts. Use static_cast, const_cast, reinterpret_cast as appropriate, and prefer avoiding casts overall if possible. This matches Google’s rule to use C++-style casts (and brace-initialization for numeric conversions) (Google C++ Style Guide) (Google C++ Style Guide). Core also mentions using gsl::narrow or similar for narrowing conversions (Google uses brace-init to catch narrowing).	✅ Aligned. AUTOSAR follows MISRA C++ rules that ban C-style casts. Rule 5-2-1 (MISRA) requires static_cast/dynamic_cast/reinterpret_cast/const_cast instead of C casts. AUTOSAR additionally states that casting away const or downcasting should be done carefully (or not at all). Google’s recommendations (use C++ casts and only when necessary) line up exactly.	Casts – All three enforce no C-style casts. Use static_cast/const_cast etc. for explicit conversions (Google C++ Style Guide) (Google C++ Style Guide). They also agree on using brace initialization for safe numeric conversions (Google explicitly says so (Google C++ Style Guide), Core/AUTOSAR concur in principle on avoiding unchecked narrowing). Overall, casting is to be done in a controlled, explicit manner in all standards.
Streams (use of iostream and operator<<)	⚠️ Partial. Core Guidelines do not provide special rules on iostream usage; iostreams are considered a standard facility. Core would agree with Google’s sentiment to use streams “where appropriate” and keep output operators simple. (For instance, don’t overload << with non-standard semantics, and don’t expose internal state in operator<< – these align with general best practice rather than explicit Core rules.) Core’s focus is more on not using printf in modern C++ when streams suffice, which is implicitly aligned with Google.	⚠️ Partial. AUTOSAR has no explicit ban on <iostream>, but in practice, heavy use of iostreams in embedded/safety code is rare (due to performance and determinism concerns). AUTOSAR guidelines don’t forbid it for debugging or logging. Google’s advice to keep streaming simple (only user-visible content, no complex hidden side effects) is generally good practice and would be expected in AUTOSAR code if streams are used.	Streams – Google permits use of <iostream> for logging/debug output and simple formatting, and cautions to keep overloaded << operators straightforward (only output user-visible state) (Google C++ Style Guide) (Google C++ Style Guide). Core/AUTOSAR have no contrary rules – they accept iostreams as standard. (AUTOSAR developers may limit iostream use for performance, but that’s contextual.) All agree that if you do overload output operators, do so in an unsurprising, simple way.
Preprocessor Macros (avoid macros except for include guards, etc.)	✅ Aligned. Core Guidelines ES.30, ES.31, ES.32 explicitly advise avoiding macros when alternative C++ features exist (Daily C++ Core Guidelines). Macros should be used only for header guards or truly necessary cases. Core says use constexpr, inline, templates, etc. instead of #define. If macros are needed, they suggest naming them ALL_CAPS (and possibly with a project-specific prefix to avoid collisions) (SF: Source files – C++). This is fully in line with Google’s rule (which also requires a project prefix on macro names and discourages macro APIs) (Google C++ Style Guide) (Google C++ Style Guide).	✅ Aligned. AUTOSAR strongly restricts macros. Rule A16-2-1: “The preprocessor shall only be used for file inclusion and include guards.” (Guidelines for the use of the C++14 language in critical and safety-related systems). Other MISRA/AUTOSAR rules (M16-0-2, etc.) require that macros be all-caps and not used to define inline code or constants (use inline or const instead) (Guidelines for the use of the C++14 language in critical and safety-related systems). This completely aligns with Google: macros are last resort (and must be all-caps with meaningful prefixes when used).	Macros – All three discourage macros. Google and AUTOSAR basically forbid macros for anything other than include guards (Google: and rare cases where absolutely needed). Core guidelines likewise prefer modern C++ alternatives. When macros must be used, all agree to use screaming caps and unique prefixes to avoid name collisions (Google C++ Style Guide) (Guidelines for the use of the C++14 language in critical and safety-related systems).
Type Deduction (auto) (use auto only when it aids clarity)	⚠️ Partial. Core Guidelines encourage use of auto to avoid repetition, but with judgement. They state to use auto when the type is obvious from context or unimportant to the reader (Improving Stability with Modern C++, Part 3 — The auto Keyword). This is similar to Google’s rule of using type deduction only if it makes code clearer or safer, not just to save typing (Google C++ Style Guide) (Google C++ Style Guide). Core might endorse auto slightly more (to avoid long type names), but they also warn against cases where it hinders understanding. Overall, the philosophy is the same; the emphasis differs slightly.	⚠️ Partial. AUTOSAR has no ban on auto. It can be used (C++14). The AUTOSAR/MISRA view is that auto is fine if it does not impair code clarity. Tools in safety-critical projects might flag overuse of auto if it obscures types. In practice, AUTOSAR code uses auto in obvious situations (iterators, lambdas) but not in cases where the type’s meaning isn’t clear. This practically aligns with Google’s guidance.	auto deduction – All agree that auto should be used with caution. Use it when it makes code cleaner (eliminating noise or obvious redundancy) (Google C++ Style Guide), but not when it would make the code less readable to someone unfamiliar. Google explicitly says not to use auto just to avoid typing a type name (Google C++ Style Guide). Core/AUTOSAR share that intent – they allow auto, but expect developers to maintain clarity.
Class Template Argument Deduction (CTAD) (C++17 feature)	⚠️ Partial. Core Guidelines (updated for C++17) have no specific rule against CTAD. They generally welcome template argument deduction that makes code cleaner. However, Core expects templates to be designed for CTAD or used with care. (There’s an implicit assumption: if CTAD is supported by the library, it’s fine to use it – e.g., std::make_unique was preferred pre-C++17, but CTAD for smart pointers isn’t available. Core hasn’t flagged CTAD as problematic.) Thus, Core is more permissive whereas Google says only use CTAD when the template author explicitly intended it (to avoid surprises).	❌ Conflict. AUTOSAR C++14 doesn’t include CTAD (introduced in C++17). Using CTAD would violate the language subset. Even aside from that, AUTOSAR tends to favor explicitness. So in AUTOSAR contexts, one would continue using factory functions like make_unique or providing explicit template args. Google’s rule effectively prohibits CTAD unless guaranteed safe – but AUTOSAR outright cannot use it until they update to C++17 or later (not within AUTOSAR C++14 guidelines).	CTAD – Google is cautious: use class template argument deduction only if the template’s maintainers have provided deduction guides or clearly expect CTAD (to avoid unexpected deductions) (Google C++ Style Guide) (Google C++ Style Guide). Core has no prohibition – CTAD is a standard feature and is generally considered safe for well-designed templates. AUTOSAR (C++14) doesn’t allow CTAD at all. So Google’s stance is stricter than Core’s, and AUTOSAR’s is moot (CTAD not available, hence any use would be non-compliant).
Designated Initializers (C++20 feature)	✅ Aligned. Core Guidelines haven’t stated rules on designated initializers, but since it’s a standard C++20 feature that improves clarity for aggregate initialization, it’s acceptable. There is no conflict – Core would support using them in modern C++ when appropriate (to initialize aggregates by name).	❌ Conflict. AUTOSAR C++14 does not support designated initializers (they were a non-standard GCC extension until C++20). Using them would violate the language subset. Code targeting AUTOSAR cannot use the C++20 designated initializer syntax. Google allows them in C++20 code (and requires using the standard-compliant form) (Google C++ Style Guide) (Google C++ Style Guide), which is incompatible with AUTOSAR’s C++14 limitation.	Designated init – Google permits designated initializers introduced in C++20 (with the restriction that field designators appear in struct-declared order to be standard-compliant) (Google C++ Style Guide). Core has no issue (it’s part of standard C++20). AUTOSAR (limited to C++14) cannot use this feature, so code must stick to positional aggregate initialization.
Lambda Expressions (use and capture style)	✅ Aligned. Core Guidelines encourage using lambdas for functional programming patterns and callbacks. They advise that lambdas should capture explicitly by value or reference as needed (and caution that capturing by reference is safe only if the lambda doesn’t escape). This aligns with Google’s rule to “prefer explicit captures when the lambda escapes the current scope” (Google C++ Style Guide) (Google C++ Style Guide). Core also says to mark a lambda mutable only if needed, and not to copy mutable data inadvertently – generally consistent with Google’s best practices on lambdas.	✅ Aligned. AUTOSAR has no objection to lambdas (they are C++14). The main concern is to avoid pitfalls: capturing by reference and then storing the lambda or using it asynchronously (which Google’s guidance covers). AUTOSAR guidelines (informally) encourage clarity in lambdas – capture only what’s needed and preferably by value if there’s any doubt about lifetimes, similar to Google’s advice. There’s no AUTOSAR rule, but the common understanding matches Google’s stance.	Lambdas – All agree that lambdas are useful and should be used appropriately. Google specifically notes to capture variables explicitly (especially when the lambda might outlive the captured scope) (Google C++ Style Guide) (Google C++ Style Guide). Core/AUTOSAR concur: careless [&] captures can be dangerous if the lambda is called later (e.g., on another thread). The recommendation is to capture only what you need, by value where possible – consistent across all.
General Naming Rules (choose clear, descriptive names)	✅ Aligned. Core Guidelines (NL.5, NL.6) emphasize self-documenting, descriptive names and consistency in style (Google C++ Style Guide) (Google C++ Style Guide). They don’t allow acronyms or abbreviations that aren’t widely known, similar to Google’s “names should be clear even to people on a different team” (Google C++ Style Guide). Both stress consistency and avoiding shorthand that sacrifices clarity.	✅ Aligned. AUTOSAR’s guidelines echo the need for meaningful naming (this is a general programming principle). For safety, names should reflect their purpose to avoid misuse. AUTOSAR does not permit obfuscated or overly abbreviated names. This is in line with Google’s general naming philosophy (e.g., no cryptic abbreviations) (Google C++ Style Guide).	Name clarity – All three sources agree on using clear, intention-revealing names and being consistent in style. Uncommon abbreviations are discouraged (Google C++ Style Guide). (Google explicitly states this; core and AUTOSAR implicitly require it for maintainability.) Overall, readability trumps brevity in naming across the board.
File Names (file naming conventions)	⚠️ Partial. Core Guidelines suggest .h for headers and .cpp for implementation files by default (SF: Source files – C++) (SF: Source files – C++), but also say consistency in a project is more important than the specific extension. Google uses .h for headers and .cc for sources. This is a minor difference in convention (Google’s use of .cc vs “.cpp” is just a style choice). Core and Google both agree filenames should be all lower-case. Core doesn’t mention underscores vs dashes explicitly, but consistency is implied.	⚠️ Partial. AUTOSAR permits header extensions .h, .hpp, or .hxx (Guidelines for the use of the C++14 language in critical and safety-related systems) (and expects consistency). Source files typically use .c for C and something like .cpp or .cxx for C++ (AUTOSAR doesn’t mandate one, but .cpp is common). Google’s preference for .cc is not used in AUTOSAR contexts (not a technical issue, just convention). Filenames in AUTOSAR are also lower-case (often with underscores).	File names – All-lowercase is standard for all. Google allows underscores or hyphens and leans toward underscore if no project pattern (Google C++ Style Guide). Core doesn’t enforce underscore vs hyphen, just consistency. AUTOSAR also allows underscore (most AUTOSAR file names use snake_case). The only slight difference is file extensions (.cc vs .cpp), which is a matter of project style – marked partial but it’s a trivial convention difference.
Type Names (class/struct/enum names)	❌ Conflict. Google uses PascalCase (CapitalizedCamelCase) for all type names (Google C++ Style Guide). Core Guidelines’ default naming suggestions (NL.9, NL.10) actually lean toward snake_case or lowerCamel for user-defined types to match the standard library style (the Core Guidelines suggest avoiding CamelCase in general). The C++ standard library itself uses snake_case for most types. So Google’s MyTypeName vs a core-guidelines style of my_type_name is a stylistic clash. Core acknowledges that naming style is arbitrary but requires consistency – their examples (e.g., in guidelines and STL) tend to use lower-case types.	⚠️ Partial. AUTOSAR does not enforce a particular case convention for type names. Many AUTOSAR-based projects use CamelCase or PascalCase for class names (because that’s a common C++ practice outside STL). However, AUTOSAR’s example guidelines also show some lower_case types for structs. There isn’t a mandated style in AUTOSAR C++14 – just be consistent. In practice, Google’s PascalCase for types would be acceptable in AUTOSAR, but it’s not required (hence partial).	Type naming – Google: MyConcreteClass (PascalCase). Core: tends toward my_concrete_class (following STL conventions) – or at least Core doesn’t insist on PascalCase. AUTOSAR is agnostic but often follows general C++ trends. This is primarily a style divergence: Google’s style guide and many internal codebases use PascalCase for types, whereas the C++ Core Guidelines favor a more STL-like all-lowercase approach.
Concept Names (template concept naming)	❌ Conflict. Google treats concept names like type names – PascalCase (Google C++ Style Guide). The C++ Core Guidelines haven’t set rules for concepts, but the C++20 standard library concepts use lower_case (e.g., std::integral). It’s likely core would recommend following the standard’s convention for concepts (i.e., snake_case). Thus, Google’s SameAs vs. core’s expected same_as is a conflict in naming style.	❌ Conflict. AUTOSAR C++14 has no concepts (not available). If AUTOSAR were to adopt concepts in the future, they would probably mirror whatever convention is common (possibly lower_case like the STL). Google’s capitalization of concept names would not apply in AUTOSAR until C++20 is in use – at which point this difference would mirror the type naming conflict.	Concept naming – Google uses CamelCase for concepts (e.g., Sortable), treating them as types. This differs from the standard library and likely core style, which use snake_case (e.g., sortable) for concepts. AUTOSAR currently doesn’t support concepts at all (C++14), so any usage is non-compliant. In summary, Google’s concept naming style doesn’t match the lower_case style that core/standard favor, and AUTOSAR can’t use concepts in its current standard.
Variable Names (including class data members)	⚠️ Partial. Google uses snake_case for variables (Google C++ Style Guide). Core Guidelines also prefer lowercase (likely snake_case) for variable names – this aligns. The difference: Google requires a trailing underscore for class data members (foo_ for a member vs foo for a local) (Google C++ Style Guide) (Google C++ Style Guide). Core Guidelines do not mandate a member naming convention like trailing underscore; they leave it to project style. Some core-guideline-following projects might use m_ or no prefix at all. So the general casing aligns (lowercase), but the member suffix is a Google-specific convention.	⚠️ Partial. AUTOSAR follows a similar lowercase convention for variables. There is no AUTOSAR rule about suffixing member variables. Many AUTOSAR projects use e.g. mVariable or _variable or no notation, depending on legacy or team preference. Google’s trailing underscore for private members is not universally practiced in AUTOSAR space. However, this is just an naming style detail. The basic lowercase underscore style is common ground.	Variable naming – All use lower_case_with_underscores for variable names. Google adds a _ suffix for class data members (to distinguish them) (Google C++ Style Guide). Core/AUTOSAR don’t require that, though it’s allowed. So, naming case is aligned (snake_case), but the member-variable underscore suffix is a Google-specific style.
Constant Names (constexpr or const variables)	❌ Conflict. Google prefixes constants with k (e.g., kMaxValue) (Google C++ Style Guide). Core Guidelines do not prescribe this convention. In fact, Core suggests that macros be ALL_CAPS and other constants follow normal variable naming (or use uppercase only if they are immutable and want to distinguish, but this is not in the guidelines explicitly). The STL and most C++ code do not use a k prefix for constants. Thus, Google’s constant naming (sometimes called “Hungarian-ish” by others) is a unique style.	⚠️ Partial. AUTOSAR doesn’t mandate a special naming for constants. Many AUTOSAR codebases use ALL_CAPS or CamelCase for global constants (following older MISRA C practices of macro constants in caps), but since constexpr is available, they might just treat it as a variable. There is no single rule – just be consistent. Google’s kName style is not required in AUTOSAR, but it’s not harmful either. It’s simply different.	Constant naming – Google uses a k prefix (e.g., kBufferSize) for constants and constexprs that have static storage duration (Google C++ Style Guide). Core/AUTOSAR do not use this convention (they either use ALL_CAPS for macros or just treat constant variables like other variables). This is a stylistic conflict – Google’s convention vs others. (All agree these constants should be const/constexpr and not macros; only the naming differs.)
Function Names	❌ Conflict. Google uses UpperCamelCase for function names (except accessors which may be named like variables) (Google C++ Style Guide) (Google C++ Style Guide). Core Guidelines suggest using a consistent style, often demonstrated as lower_case for functions (to match the standard library). In the Guideline support library and examples, function names are typically lower_case. The recommendation NL.10 “Avoid CamelCase” indicates core leans toward lower_case function names. Thus, Google’s style is opposite in capitalization.	⚠️ Partial. AUTOSAR does not dictate function name case. In practice, many AUTOSAR projects use lower_case or lowerCamelCase for function names (especially ones mimicking C style). However, using PascalCase for functions (as Google does) isn’t forbidden and some projects do it for consistency with class names. There is variation. So Google’s style might not match a particular AUTOSAR project’s style, but AUTOSAR as a standard doesn’t enforce one or the other.	Function naming – Google: DoSomethingImportant() (CapitalizedCamelCase) (Google C++ Style Guide) (Google C++ Style Guide). Core: tends toward do_something_important() (lower_case). AUTOSAR: no enforced rule, but many codebases use lower_case or mixedCase for functions. So, Google’s function naming convention is a different style from core’s default and some AUTOSAR practices. This is a pure naming-style difference (no functional impact).
Namespace Names	✅ Aligned. Google and AUTOSAR both use all-lowercase names for namespaces (often based on project or module name) (Google C++ Style Guide). Core Guidelines agree (e.g., the standard library and examples use lowercase). There’s consensus that namespace names should be lowercase to avoid confusion with types. If multiple words, Google uses underscores (e.g., my_project::sub_module) (Google C++ Style Guide), which is common practice and not contradicted by core or AUTOSAR.	✅ Aligned. AUTOSAR follows the general rule of lowercase namespace names. For example, an AUTOSAR component might have a namespace like diagnostic or calibration. This matches Google’s requirement. Underscores in namespace names are also acceptable if needed (AUTOSAR doesn’t forbid it).	Namespace naming – Uniform agreement: namespace names are lowercase (and underscored if multi-word). Google explicitly says this (Google C++ Style Guide), and core/AUTOSAR naturally follow that convention too. No conflicts here.
Enumerator Names (enum values)	❌ Conflict. Google treats enum values like constants: kEnumName style (Google C++ Style Guide) (for scoped and unscoped enums). Core Guidelines don’t have a stated convention, but the prevailing style in modern C++ is to treat enumerator names as scoped members, often lowercase (especially for enum class). The standard library’s few enum class (like std::endian) use enumerators like little and big (lowercase). Core’s NL.9 says ALL_CAPS only for macros, implying they wouldn’t use leading k or all-caps for enum values – probably just treat them as regular names (possibly PascalCase without the k or just lower_case). In any case, Google’s prefixed kName is unique to their style.	⚠️ Partial. AUTOSAR historically (MISRA C++) recommended enumerator names to be ALL_CAPS (when enums were effectively constants in C). However, with enum class, that practice is less necessary. AUTOSAR hasn’t mandated the k prefix. Some AUTOSAR code might use ALL_CAPS for unscoped enum values to distinguish them. In scoped enums, they might use PascalCase or lower_case. There isn’t a single rule; it’s typically project-defined. Google’s approach differs (they don’t use ALL_CAPS, but use k + CamelCase which is distinct).	Enum values – Google uses kEnumValue naming (Google C++ Style Guide), which differs from many other code standards. Core/AUTOSAR don’t prescribe k or all-caps for enum values – styles vary (older code uses ALL_CAPS, modern code often treats scoped enums like normal names). This is a naming convention conflict. (All agree enumerators should be constants – the difference is purely in notation: Google’s constant-style prefix vs. others’ conventions.)
Macro Names	✅ Aligned. Google and AUTOSAR both require macro names to be ALL_CAPS with underscores and a project-specific prefix (Google C++ Style Guide) (Google C++ Style Guide). Core Guidelines also say to use ALL_CAPS for macros (NL.9) to distinguish them. So everyone agrees on MYPROJECT_MY_MACRO. There’s no conflict here.	✅ Aligned. AUTOSAR (and MISRA C) require macro names to be ALL_CAPS. For example, include guards in AUTOSAR are typically FILE_NAME_H_ or have a project prefix. Any function-like macros (which AUTOSAR tries to avoid) would also be all-caps. Google’s example MYPROJECT_ROUND(x) (Google C++ Style Guide)fits this perfectly.	Macro naming – All standards concur: macros (when you absolutely need them) should be named in ALL_CAPS with underscores, often including a project or module prefix to avoid collisions (Google C++ Style Guide) (Google C++ Style Guide). This helps distinguish macros from variables/functions. (Since all discourage macros in general, this rule is mainly for the rare cases that macros are used.)

[FScholPer]

@AlexanderLanin should we follow up on this?