GitHub Copilot C++ Examples You Can Review and Reuse

Good GitHub Copilot C++ examples define one small behavior, state who owns the data and require evidence before accepting the result. Use the prompts below for a parser, an ownership review, regression tests and a refactor rather than asking for an entire subsystem at once.

Each example needs your compiler, language standard and project conventions. A snippet that compiles elsewhere can still be unsuitable for your codebase. fenbs keeps reviewed prompts and lessons from failed suggestions available to connected assistants, so a later session can reuse the checks that mattered on your project.

What should you specify before generating C++ code?

Start with the supported C++ standard, compiler, platform and build command. Name the existing test framework, dependency limits and error-handling style. For example, a project that disables exceptions needs a different failure contract from one that throws them. Ask the assistant to flag an unknown rule rather than selecting a new convention.

• Scope: the exact function or files that may change.
• Behavior: valid inputs, invalid inputs and expected results.
• Ownership: who keeps the data alive and whether a result copies or refers to it.
• Evidence: the build, focused tests and relevant analysis tools to run.
• Boundaries: public interfaces, dependencies and unrelated files that must stay unchanged.

GitHub recommends specific requirements, examples and careful validation in its Copilot best practices↗ (opens in a new tab). Ask for a plan first when the assistant has not yet inspected the relevant code. An impressive patch is harder to evaluate than a short explanation of the proposed behavior.

For software context outside these examples, read the Copilot app guide and model guide; use the separate Python prompts or Microsoft workplace prompts for those tasks.

How can you request a parser with clear failure behavior?

Choose a task with a small observable result. Say you need to read a whole-number retry count from a configuration value. Decide what whitespace, a leading sign, an empty string and an out-of-range value mean. Those choices form the behavior your tests should check.

Environment: C++17, [compiler/version], standard library only.
Propose a function returning std::optional<int> from std::string_view.
Accept one or more ASCII digits representing a value from 0 through 100. Reject whitespace, signs, trailing characters, empty input, and out-of-range values. Leading zeroes are allowed. Do not throw or allocate intentionally.
Explain how parsing consumes the entire input and handles conversion failure.
Provide tests for 0, 100, 101, leading zeroes, empty input, whitespace, signs, trailing text, and a digit sequence too large for int. Do not modify other configuration behavior.

This is an example requirement, not a universal configuration rule. Replace the range and accepted spelling with your product behavior. If existing callers accept surrounding spaces, silently rejecting them would be a behavior change even if the new implementation looks cleaner.

Check the failure cases yourself and build with the actual project toolchain. A test for a large value should verify rejection, not depend on an accidentally wrapped result. Keep the initial patch small enough that you can explain every path from input to result.

Ask for a short usage example beside the proposed function. It should show how a caller handles both an accepted value and a rejected value without assuming success. That small example can expose a mismatch between a sensible helper and an unsafe calling pattern before the helper is copied throughout the project.

How do you ask Copilot to review ownership and lifetime?

Ownership describes who is responsible for a resource; lifetime describes how long it remains usable. A pointer or view can refer to data without keeping that data alive. Ask for a trace through the callers, because inspecting one function in isolation may hide the point where the underlying object disappears.

The C++ Core Guidelines on resource management↗ (opens in a new tab) recommend tying cleanup to objects that manage resources. That principle is often called RAII, automatic cleanup when an owning object leaves its lifetime. Apply it with the project conventions rather than mechanically replacing every pointer.

Review [function/class] and these callers: [files]. Do not edit yet.
For every pointer, reference, iterator, and string_view that crosses a function boundary, identify the owning object and the required lifetime.
Look for returned references to local objects, views into temporary strings, invalidation after container changes, and cleanup paths on failure.
For each suspected issue, give a concrete triggering sequence and the relevant code location. Separate confirmed problems from questions that require caller information. Propose the smallest correction after the analysis.

Request a concrete sequence rather than a generic warning. “A view might dangle” is less useful than identifying the temporary string, the returned view and the later read. Verify that sequence against the source. If a caller is missing, keep the conclusion conditional instead of describing an unproven defect as confirmed.

Save a recurring lifetime trap as a lesson alongside the approved review prompt in fenbs Skills and prompts. The next assistant can read why that check exists before repeating the same suggestion.

How can regression tests demonstrate that a fix works?

A regression test reproduces a specific bug so a later change can catch its return. Give Copilot the failing input and intended behavior, then ask for the test separately from the fix. That makes it easier to see whether the test would have exposed the original problem.

Bug: [minimal reproduction and actual behavior].
Required behavior: [expected result and its source].
Use [existing test framework] and conventions from [test file].
First propose a regression test without changing production code. Explain why it should fail on the original code.
Then propose the smallest fix and adjacent boundary cases worth checking.
Report actual commands and results. Distinguish build failures, assertion failures, and unavailable tooling. Do not claim memory safety because a test passed.

Review ordinary behavior and memory behavior separately. A correct return value does not show that every access was valid. When your supported toolchain provides it, a runtime checker can add useful evidence: Clang documents AddressSanitizer↗ (opens in a new tab) for detecting problems such as out-of-bounds access and use after a resource has been freed.

Run the project-supported checks rather than copying unfamiliar compiler flags into a release build. Record which configuration and input exercised the fix. A clean result covers the paths that ran; it should not become a claim that every possible execution is safe.

Keep the reproduction with the test rather than only in the conversation. Explain the behavior it protects and why the triggering input matters. A later developer should be able to recognize a real regression without reconstructing the original debugging session or trusting the assistant's summary.

How can you request a refactor without redesigning the component?

Specify which complexity you want removed. Perhaps a long function repeats a conversion, or a resource wrapper is hard to follow. Ask for one improvement with observable behavior preserved. “Modernize this C++” gives the assistant too much room to change interfaces and ownership at the same time.

Refactor [function] to remove [specific duplication or complexity].
Preserve the public interface, error behavior, ordering, ownership, and resource cleanup. Keep the supported C++ standard and current dependencies.
Do not introduce concurrency, new caching, or an ownership redesign.
List behavior that needs test coverage, then propose a small patch. Explain any new copies, allocations, moves, or lifetime assumptions. If the requested cleanup requires behavior changes, stop and describe the choice for review.

Ask why a change helps this code, not merely which language feature it demonstrates. Compare the diff with the stated goal, compile it and run relevant checks. If a performance improvement is part of the claim, require measurements with a representative workload rather than accepting an intuition about fewer lines.

Keep successful examples with their limitations. A prompt designed for a synchronous parser may be a poor starting point for shared data across threads. Our AI prompts collection provides other focused patterns when the task needs a different kind of review.

How to do this with fenbs

1. Create a free account and add the C++ project and the task you want to improve.
2. Save one bounded prompt in Skills and prompts, including the required inputs and checks.
3. Record continuing project instructions people have agreed in Decisions and rules, such as the supported language standard or dependency policy.
4. Ask a supported connected assistant to read the project context and relevant prompt before working. Keep source code and test execution in the development environment.
5. Save progress with actual verification results and unresolved questions. Record a lesson when a failed suggestion should change the next review.

fenbs does not compile C++ or prove memory safety. It is useful when prompts, rules and unfinished work need to survive a change of session or assistant. If you only need one isolated snippet, a local example and ordinary code review may be enough.