C++

The registry row this page is generated from

Read at render time from the same family row the register reads, so nothing in this block can disagree with it.

Extensions

.cpp, .cc, .cxx, .c++, .hpp, .hxx, .ipp, .inl, .cu, .h

Registry names

cpp

Recorded symbols

classes · methods · namespaces · enums

Relationship types this analyzer constructs

11 of 14 constructed, read from this analyzer's source and re-derived by the languages gate. Each row below is one of the engine's types, in the engine's own order.

11 constructed, 3 not constructed. All 3 absent types are recorded as ruled absent: the written reason and the corpus measurement behind each are in this family's completeness record. The register explains what each label means.

What this analyzer does not resolve

• There is no implements edge and that is a fact about C++: the format has no separate interface construct, so class X : public I records extends whatever I turns out to be, and whether I is a class or an abstract base is not stored separately.
• Overrides resolve inside one translation unit. A base declared in a header this file does not include is invisible here, so a cross-header override is not an edge at all.
• Preprocessor text is not code: a name appearing only inside a #define replacement list is a read of the macro, never a call inside a function. A trailing annotation macro on a function head — virtual int f(...) GUARD_(m) {} — is refused whole, symbol and stolen body together.

Every line above was written against C++’s own analyzer module and is named against a construct in it, so it can be checked against the source. Nothing here is inherited from a template, or from another language’s page.

Where you meet it in a repository

Recognised by extension — .cpp, .cc, .cxx, .c++, .hpp, .hxx, .ipp, .inl, .cu, .h. Everything below is about where those files actually sit in a working repository.

• A C++ project declares in headers and defines in .cpp files, so a symbol's prototype and its body are usually in different files and are recorded separately.
• Google Test and similar frameworks write function bodies under a macro heading; without a scope for that body every call inside a test would have no owner.
• Templates write the same class once and use it at many concrete types, so the index holds the generic form with its arguments stripped.

Questions this index answers

Phrased as retrievals, because that is what an index can honestly do: it holds the symbols and the edges between them, and hands them back with the evidence attached.

1. Which class does this method override?
2. Where is this macro defined, and which files read it?
3. Which namespace declares this function?
4. What does this test case actually call?

What the analyzer sees in code like this

#define JSON_ASSERT(x) assert(x)     // bb records: macro JSON_ASSERT

class GTEST_API_ Widget {            // bb records: class Widget
 public:
  virtual void value(int n) const = 0;   // bb records: method value
  int count_{0};                         // bb records: property count_
};

TEST(Box_Int, KeepsLocals) {        // bb records: a scope for the macro body
  auto* b = new Box<int>;           // bb records: Box instantiated here
}

Symbols are stored with the file they came from and the bytes they span, so a hit points at a line rather than at a guess. The annotations in the sample are commentary for the reader, not strings the index would store.

Languages that turn up in the same repository

Application & systems — the count beside each name is how many relationship types that family’s analyzer constructs.

• TypeScript14 types
• JavaScript12 types
• Python11 types
• Rust14 types
• Go12 types
• Java10 types
• C9 types
• C#11 types
• Swift11 types
• Kotlin11 types
• Dart13 types
• Zig8 types
• Objective-C11 types
• Visual Basic11 types
• VBA9 types