Performance-critical code
- Pricing, matching and risk engines
- Signal, image and video processing
- Simulation and numerical work
C++ Development
C++ development services
Your C++ code is fast and has run for years, but builds are fragile, third-party code is copied into the tree and nobody wants to touch the memory handling. Agnotic Technologies writes new C++17 and C++20 components, moves older code to current standards and puts a written memory safety plan behind it.
C++17, C++20 and C++23CMake and package managersSanitizers and fuzzingMemory safety plans
Trusted by global innovators
What do C++ development services cover?
C++ development services cover writing, modernizing and maintaining software in C++ where speed, memory control or a long-lived codebase matter. Agnotic Technologies builds new C++17 and C++20 components, moves older C++ to current standards with CMake and a package manager, and writes a memory safety plan your team can follow.
Most of our C++ work happens in codebases that already earn money, so every change has to keep the product shipping.
Qt interfaces have their own page, and firmware for microcontrollers is covered on our embedded software development page.
Where C++ fits
Where does C++ still earn its place?
C++ is the right tool when one of these is true. When none is, we will say so and suggest another language.
Long-lived products
- Desktop and engineering applications
- Instrument and lab software
- Codebases with years of tested behavior
Native libraries
- Shared cores used by mobile apps
- Extensions for Python, Java or .NET
- SDKs shipped to other developers
Close to hardware
- Device and driver user space code
- Embedded Linux applications
- Real-time control on capable processors
Upgrade path
Which C++ standard should your codebase move to?
We move one standard at a time. Each step pays off on its own and is checked before the next one starts.
| Step | What it gives you | What to check first |
|---|---|---|
| Pre-C++11 to C++11 or C++14 | Move semantics, std::unique_ptr and std::shared_ptr, auto, lambdas and a standard thread library | Raw new and delete ownership, and compiler versions on every target platform |
| C++14 to C++17 | std::optional, std::variant, std::string_view, structured bindings, if constexpr and std::filesystem | Removed features such as std::auto_ptr, and string_view lifetimes in new code |
| C++17 to C++20 | Concepts, ranges, std::span, coroutines, three-way comparison and modules | Compiler and build tool support for each feature, especially modules, and ABI with prebuilt libraries |
| C++20 to C++23 | std::expected, std::print, std::mdspan and deducing this | Standard library support in every toolchain you ship with, including older embedded compilers |
The compiler flag changes in its own commit, warnings are fixed before new features are used, and the test suite runs on every supported compiler.
Toolchain
What does a modern C++ build look like?
The build and checks we set up first, because every later change depends on them.
Build
- CMake with target-based configuration
- CMake presets for each platform and compiler
- One build command for developers and CI
- Reproducible release builds
Dependencies
- vcpkg or Conan manifests in the repository
- Pinned versions for every library
- No copied third-party folders
- License list generated from the manifest
Checks
- Compiler warnings treated as errors
- clang-tidy with modernize and bugprone checks
- Static analysis on every merge request
- Formatting enforced by clang-format
Tests
- Unit tests with GoogleTest or Catch2
- Sanitizer builds in CI
- Fuzz targets for parsers and protocols
- Benchmarks for hot paths
Memory safety
What goes into a memory safety plan?
A short written plan, agreed with your team, that says how memory errors are prevented, found and reduced over time.
- An inventory of code that handles untrusted input, such as parsers, network handlers and file loaders, ranked by exposure
- Ownership rules for new code: RAII and smart pointers, with no raw owning pointers
- Bounds-checked access through containers and std::span instead of pointer arithmetic
- AddressSanitizer, UndefinedBehaviorSanitizer and ThreadSanitizer builds that run in CI
- Fuzzing for every parser and protocol handler, with crashes filed as defects
- Hardened compiler and standard library options where your toolchain supports them
- A decision on whether any new component should be written in a memory safe language such as Rust, and how it calls the C++ code
- Progress measured against the plan, so you can share it with customers as a memory safe roadmap if you choose
Tooling
Which tool catches which kind of C++ bug?
No single tool finds everything. These are the ones we wire into CI, and what each is for.
| Code | Name | Typical use |
|---|---|---|
| AddressSanitizer | Memory errors | Out-of-bounds reads and writes, use-after-free and double free, found while tests run |
| UBSan | Undefined behavior | Out-of-range shifts, signed overflow, misaligned and null pointer use that compilers may otherwise optimize into wrong results |
| ThreadSanitizer | Data races | Two threads touching the same memory without synchronization, in a separate CI build |
| clang-tidy | Static checks | Modernize, bugprone and C++ Core Guidelines checks on every merge request |
| libFuzzer | Malformed input | Generated inputs against parsers and protocol handlers, run with sanitizers turned on |
Failure points
Why do C++ upgrades break working code?
The problems we plan for before changing a compiler or a standard.
Challenge
A new compiler exposes undefined behavior that happened to work before.
Agnotic approach
Sanitizer builds run on the old compiler first, so existing bugs are fixed before the upgrade is blamed for them.
Challenge
Prebuilt vendor libraries stop linking after the change.
Agnotic approach
ABI dependencies are listed during scoping, and the upgrade waits for compatible builds or wraps those libraries behind a stable interface.
Challenge
A rewrite of a working module loses behavior nobody wrote down.
Agnotic approach
Characterization tests capture current behavior before any refactor, and modules are changed in place, not rewritten.
Challenge
Performance drops and nobody notices until customers do.
Agnotic approach
Benchmarks for hot paths run in CI with agreed tolerances, so a slow merge request is caught before release.
Challenge
Each platform builds with different dependency versions.
Agnotic approach
One package manifest with pinned versions serves every platform and the CI build.
Challenge
Sanitizer findings pile up and get ignored.
Agnotic approach
Findings are triaged into the backlog and new ones block the merge request that introduced them.
What C++ work do we take on?
Engagements we run in C++, alone or alongside your engineers.
New components and libraries
Modern C++17 or C++20 modules with clear interfaces, tests and documentation.
Standard upgrades
Moving a codebase step by step to a current standard on every compiler you ship with.
Build and dependency cleanup
CMake, presets and a package manager replacing hand-written builds and copied libraries.
Performance work
Profiling, data layout and algorithm changes measured against benchmarks, not guesses.
Memory safety work
A written plan, sanitizers and fuzzing in CI, and fixes ranked by exposure.
Language bindings
C++ cores exposed to Python, Java, .NET, Swift or Kotlin through stable interfaces.
What sizes this build
What sizes a C++ project?
We do not publish prices or use a cost calculator. These are the inputs we size a C++ project from on the scoping call.
Codebase size and age
How much code there is, which standard it is written to and how much of it is still changing.
Platforms and compilers
Each operating system, processor and compiler version adds builds to keep green.
Build and dependency state
Whether the build is already CMake with a package manager, or hand-made scripts and copied libraries.
Test coverage
How much behavior is covered by tests today, which sets how safely the code can change.
Performance targets
Latency, throughput or memory limits the code must meet, and how they are measured.
Safety and security rules
Coding standards, customer security requirements or regulated device documentation.
Interfaces
Bindings to other languages and binary interfaces that must stay stable for other teams.
Who it is for
Who brings C++ work to us?
Teams whose product depends on C++ and cannot pause while it improves.
Fintech and trading teams
Engines where latency matters and every change needs benchmarks and careful review.
Imaging and signal processing
Medical, industrial and media software that processes large images, video or sensor data.
Engineering software vendors
Desktop and simulation products with decades of code that must move to a current standard.
Device and instrument makers
C++ applications on embedded Linux or desktop tools that drive instruments.
C++ development for startups
Founders whose core needs native speed, who want the build, tests and safety rules right from the first commit.
Engagement
How does a C++ engagement start?
Build first, then change code with tests around it.
1.
Codebase review
We read the code, build it on your platforms and list risks: undefined behavior, dependencies, coverage and ABI constraints.
Review2.
Build and checks
CMake, a package manager, warnings, sanitizers and CI go in before feature work starts.
Build3.
Fixed-scope first release
We deliver the agreed component or upgrade step, with tests and benchmarks proving it.
Deliver4.
Scale and support
Further upgrade steps, new components or ongoing maintenance alongside your team.
SupportStandards
Standards and guidance we follow in C++
The language standard, coding guidance and security guidance behind our C++ work.
ISO/IEC 14882:2024C++ Core GuidelinesSEI CERT C++CISA
Facts and sources
Facts behind C++ development
The C++ standard, coding guidance, tool documentation and security guidance this page relies on, each linked to its source.
The current ISO C++ standard is C++23, formally ISO/IEC 14882:2024. It is called C++23 because the technical work was completed in 2023.
Source: The Standard, Standard C++ Foundation (isocpp.org)The C++ Core Guidelines, edited by Bjarne Stroustrup and Herb Sutter, aim to help people use modern C++ effectively and focus on interfaces, resource management, memory management and concurrency.
Source: C++ Core Guidelines (isocpp.github.io)The SEI CERT C++ Coding Standard groups its rules into areas including declarations and initialization, containers, memory management, exceptions and error handling, and concurrency, and it relies on the SEI CERT C Coding Standard.
Source: SEI CERT C++ Coding Standard, Software Engineering Institute, Carnegie Mellon UniversityClang's AddressSanitizer detects out-of-bounds accesses to heap, stack and globals, use-after-free, use-after-return, use-after-scope and double free, with a typical slowdown of 2x.
Source: AddressSanitizer, Clang documentation (LLVM Project)CISA's guidance The Case for Memory Safe Roadmaps explains how software manufacturers can move to memory safe programming languages and gives steps for creating and publishing a memory safe roadmap for their customers.
Source: The Case for Memory Safe Roadmaps (CISA)
Frequently Asked Questions
We do not publish a price or use a cost calculator. Cost follows the size and age of the codebase, the platforms and compilers, the build and dependency state, test coverage, performance targets and any safety or security rules. You get a written proposal after the scoping call.
The newest standard that every compiler you ship with fully supports. For many teams that is C++17 or C++20 today. C++23 is the current ISO standard, but standard library support varies by toolchain, so we check yours first.
Rarely all of it. Rewriting working code throws away tested behavior. A memory safety plan usually hardens the existing C++ and considers a memory safe language for new components that handle untrusted input, called through a narrow interface.
It depends on the code size, the standard you start from, the number of compilers and how much test coverage exists. We review the code first and agree the first upgrade step as a fixed scope, so you see a working result before committing to more.
Often, yes. We profile on realistic workloads, find where time and memory actually go, and change data layout, algorithms or threading there. Every change is measured against a benchmark, so gains are shown rather than assumed.
Yes. We work in your repository, follow your review process and improve the build in place. If the build needs to move to CMake or a package manager, we do it in steps that keep everyone able to build.
Yes. We expose C++ cores to Python, Java, .NET, Swift and Kotlin through a small, stable interface, with tests on both sides so a change in the core does not break callers unnoticed.