fincore_cpp

Native C++23 analytics for portfolios, factors, performance and risk — one typed API over a local DataFrame, with no Python dependency at run time.

Quickstart Installation API reference GitHub

git clone https://github.com/cloudQuant/fincore_cpp.git
cd fincore_cpp && git submodule update --init --recursive
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --parallel
ctest --test-dir build --output-on-failure

Find your path

If you want to…	Start here
Get something running	Quickstart — build a frame, compute a metric, render a report
Pick the right metric	Metrics and rolling windows — definitions, annualization and degenerate cases
Produce risk numbers	Portfolio, risk, optimization and simulation — estimators, backtests, statuses
Study a factor panel	Factor research — IC, quantiles, tears and exports
Look up a symbol	API reference — every public symbol, generated from the headers
Understand a design choice	Data and numerical conventions — timestamps, NaN, ownership, digests

What is inside

Area	Highlights
Core data	dataframe, UTC nanosecond timestamps, calendar and frequency helpers
Metrics	Returns, ratios, drawdowns, rolling windows, stability statistics
Risk	Historical, EVT and GARCH VaR/ES, backtests, walk-forward, Bayesian cone
Portfolio	Positions, transactions, round trips, turnover, capacity, cash flows
Factor research	Analysis pipeline, IC and quantile tables, tears, point-in-time joins
Attribution	Brinson, factor and style regression, exposures, prediction
Optimization	Mean-variance, frontier, risk parity with box and sector constraints
Reporting	One document rendered to HTML, XLSX, PDF, Plotly, Bokeh, axes, ImPlot
Runtime	Operation catalog, session caching, extensions, deterministic digests
Simulation	GBM, bootstrap, Latin hypercube, antithetic variates

How this documentation is organised

• Start here — installation, quickstart, data and numerical conventions.

• Guides — task-oriented explanations of each area, with the failure rules that matter in practice.

• Reference — one page per module, generated from the public headers; the text you read there is the text in the source.

• Project — migration notes, performance method, troubleshooting, publication state and contribution rules.

Start here

• Installation
  • Requirements
  • Build from a checkout
  • Build options
  • Install and consume
  • Verify the install
  • Platform notes
  • Documentation build
• Quickstart
  • Build a return series and read a few numbers
  • Prepare a factor panel
  • Render a report
  • Handle failures where they happen
  • Next steps
• Tutorial: a monthly performance report from prices
  • Set up
  • Step 1 — Turn prices into returns
  • Step 2 — Headline statistics
  • Step 3 — A rolling view
  • Step 4 — A monthly table
  • Step 5 — Compare with a benchmark
  • Step 6 — Build and render the report
  • What you built
  • Where to go next
• Data and numerical conventions
  • Frames and time
  • Returns, units and annualization
  • Missing values and alignment
  • Ownership and lifetime
  • Determinism and digests
  • Errors
  • Reports and files
  • Frequencies and labels
• Architecture and design choices
  • Layers
  • Ownership
  • Determinism
  • Errors and degenerate results
  • Concurrency
  • Extension points
  • What is deliberately not here
  • How the documentation mirrors this

Guides

• Metrics and rolling windows
  • Inputs and units
  • Annualization
  • Return and ratio family
  • Drawdown family
  • Distribution and stability statistics
  • Rolling windows and tables
  • Worked example
  • Choosing a metric
• Portfolio, risk, optimization and simulation
  • Portfolio inputs own their data
  • Positions, transactions and capacity
  • Risk estimates
  • Backtesting what you estimated
  • Walk-forward validation
  • Optimization
  • Simulation
  • Failure model summary
• Factor research: from rows to tables
  • The input panel
  • Analysis configuration
  • What the model contains
  • Tears and artifacts
  • Point-in-time joins
  • Exports and comparison
  • A minimal study
• Reports, runtime and extensions
  • One document, many backends
  • Artifact bundles
  • Escaping and non-finite values
  • Runtime catalog
  • Sessions and caching
  • Extensions
  • A minimal report
• Cookbook
  • Rolling metrics for one series
  • The deepest drawdowns as a table
  • VaR plus a coverage verdict
  • GARCH VaR over a multi-day horizon
  • Quantile means from a factor panel
  • A point-in-time panel from revisions
  • A reproducible simulation
  • Add a table to a report and export it
• Examples and demos
  • Render a factor report
  • Render one document through every backend
  • An interactive ImPlot dashboard
  • Benchmarks
  • Where the code lives

Reference

• API reference
  • Modules
  • How to read a reference page
  • Conventions used by every module
  • Coverage
• Migrating from Python fincore
  • Mapping table
  • Porting checklist
  • Known differences that bite
  • What parity means here
• Performance method and limits
  • How the harness measures
  • What the numbers mean
  • Reproducing a measurement
  • Limits and honest gaps
• Troubleshooting
  • Configure or build fails
  • Runtime errors
  • Numbers that surprise you
  • Documentation build fails
  • Publication problems
  • Reporting a problem
• Contributing to code and documentation
  • Before you start
  • Code changes
  • Comment standard
  • Documentation changes
  • Commits and pull requests
  • Review and evidence
• Publication and platform status
  • GitHub Pages — live
  • Read the Docs — live, one project
  • Rule
• Versions and release notes
  • What version you are reading
  • Current status
  • Change log for this cycle
  • How the next release will be cut
• Glossary
• Maintainer notes
  • Comment rounds
  • API pages
  • Translation
  • Generated artifacts

Scope and status

The library consumes its own DataFrame type and returns owning typed results. The stable public surface is documented separately from internal fincore::detail helpers, and optional visualization adapters are built only when their CMake options and GUI dependencies are enabled.

Every public symbol is documented and tracked in the API ledger; both language builds run strict Sphinx checks on every change, and the C++ test suite runs on each push. Published state, including which platforms are live, is recorded in publication notes rather than asserted here.