Add VS Code project config and fix CMakeLists.txt for Windows/MSVC

[collinskiptookebenei-code]

Why

The existing CMakeLists.txt used GCC-only compiler flags (-O3, -march=native, -Wall, etc.) that fail silently or error out under MSVC. It also compiled every .cpp file (each containing its own main()) into a shared trading_core library and as separate executables, causing duplicate main linker errors. There was also no VS Code configuration to provide IntelliSense, build tasks, or debugger support.

What changed

CMakeLists.txt - fixed for MSVC/Windows:

• Replaced GCC flags with if(MSVC) / else() branches using proper MSVC options (/O2, /Od, /Zi, /W4)
• Added NOMINMAX, WIN32_LEAN_AND_MEAN, _CRT_SECURE_NO_WARNINGS definitions for Windows compatibility
• Removed the trading_core static library (it caused duplicate main() linker errors); each demo is now a standalone executable
• Made Boost optional - market_data_receiver_demo is skipped gracefully if Boost is not found
• Added ws2_32/mswsock link deps for Boost.Asio on Windows

CMakePresets.json (new):

• Three presets: MSVC Debug, MSVC Release, and MinGW Debug (fallback if MSVC unavailable)
• VS Code CMake Tools picks these up automatically on project open

.vscode/ (new):

• c_cpp_properties.json - MSVC x64 IntelliSense, C++17, driven by CMake Tools
• settings.json - sets CMake build dir, generator, and C++ standard
• tasks.json - build tasks wired to CMake presets (default build on Ctrl+Shift+B)
• launch.json - debug configurations for all four demo executables (F5)
• extensions.json - recommends ms-vscode.cpptools and ms-vscode.cmake-tools

Trade-offs / notes

• The market_data_receiver_demo target requires Boost 1.75+. Without it, the target is skipped and a CMake warning is printed - nothing else breaks.
• Tested CMake configuration logic; full compile requires Visual Studio Build Tools 2022 + CMake to be installed (instructions in session chat).

[qodo-code-review]

PR Summary by Qodo

Make CMake build MSVC-friendly and add VS Code + CMake Presets

🐞 Bug fix ⚙️ Configuration changes ✨ Enhancement 🕐 20-40 Minutes

AI Description

• Fix MSVC-incompatible compiler/link flags and Windows defines in CMake
• Stop building a shared core library to avoid duplicate main() linker errors
• Add CMake Presets and VS Code tasks/launch configs for build + debug workflows

Diagram

graph TD
  Dev["Developer"] --> VS["VS Code (.vscode)"] --> Presets["CMakePresets.json"] --> CMake["CMake configure/generate"] --> Lists["CMakeLists.txt"] --> Demos["Demo executables"]
  Lists --> BoostQ{"Boost found?"} -->|"yes"| Mkt["market_data_receiver_demo"]
  BoostQ -->|"no"| Skip["Skip market demo"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Create a real core library + thin demo mains

• ➕ Avoids code duplication between demos and tests
• ➕ Makes it easier to evolve demos into reusable library APIs
• ➕ Cleaner install/export story if this becomes a consumable package
• ➖ Requires refactoring sources to separate library code from main() entry points
• ➖ More targets and structure than needed for simple demos

2. Keep library but exclude main() sources from it

• ➕ Minimal change vs previous layout
• ➕ Preserves a single place for common compilation settings
• ➖ Easy to regress (accidentally re-add a main() file to the library)
• ➖ Still doesn’t address per-target dependency clarity as well as explicit executables

3. Use target-specific options via generator expressions

• ➕ More idiomatic CMake for multi-config generators (Visual Studio)
• ➕ Avoids reliance on global CMAKE_BUILD_TYPE logic
• ➖ More complex CMake to read and maintain for a small project
• ➖ Doesn’t change the need to fix the target graph (main duplication)

Recommendation: The PR’s approach (standalone demo executables + MSVC-specific flags/defines + optional Boost target) is the most pragmatic fix for the current code layout where each .cpp contains a main(). If the project transitions from demos to a reusable library, consider splitting shared logic into a core library and keeping demo entry points thin to reduce duplication (especially for tests).

Files changed (7) +345 / -74

Bug fix (1) +111 / -74

CMakeLists.txtFix CMake for MSVC: flags, target graph, optional Boost + GTest +111/-74

Fix CMake for MSVC: flags, target graph, optional Boost + GTest

• Reworks compiler/link flags to be MSVC-compatible while preserving GCC/Clang settings, and adds Windows compatibility defines. Removes the shared core library to avoid duplicate main() linker failures, builds each demo as a standalone executable, and gates the Boost.Asio demo on Boost availability (with MSVC-specific socket linkage). Also makes tests conditional on GTest and test file presence, and updates install + configuration summary output.

CMakeLists.txt

Other (6) +234 / -0

c_cpp_properties.jsonAdd MSVC IntelliSense configuration (C++17, CMake Tools provider) +26/-0

Add MSVC IntelliSense configuration (C++17, CMake Tools provider)

• Introduces a VS Code C/C++ configuration targeting MSVC x64 with C++17 and Windows-specific defines. Uses CMake Tools as the configuration provider to align IntelliSense with the active CMake preset/build.

.vscode/c_cpp_properties.json

extensions.jsonRecommend VS Code extensions for CMake + C++ workflows +8/-0

Recommend VS Code extensions for CMake + C++ workflows

• Adds workspace extension recommendations to standardize CMake and C++ tooling. Helps contributors auto-install the expected VS Code plugins.

.vscode/extensions.json

launch.jsonAdd debugger launch profiles for all demo executables (MSVC) +53/-0

Add debugger launch profiles for all demo executables (MSVC)

• Adds cppvsdbg launch configurations for each demo executable under the MSVC Debug build output directory. Integrates with the build task so F5 runs after building.

.vscode/launch.json

settings.jsonConfigure VS Code CMake defaults and C++ standard +29/-0

Configure VS Code CMake defaults and C++ standard

• Sets the default build directory, generator, and configure-on-open behavior for CMake Tools. Pins C++17 defaults and basic file associations/format-on-save for consistency.

.vscode/settings.json

tasks.jsonAdd CMake configure/build/clean tasks wired to presets +56/-0

Add CMake configure/build/clean tasks wired to presets

• Creates tasks to configure MSVC Debug, build Debug/Release, and clean the build directory. Makes Debug build the default Ctrl+Shift+B action and integrates with launch configurations.

.vscode/tasks.json

CMakePresets.jsonAdd CMake presets for MSVC Debug/Release and MinGW fallback +62/-0

Add CMake presets for MSVC Debug/Release and MinGW fallback

• Introduces standardized configure/build presets for Visual Studio 2022 (x64) and a MinGW Makefiles debug alternative. Enables smoother integration with VS Code CMake Tools and consistent build directory layout.

CMakePresets.json

[gemini-code-assist]

Code Review

This pull request introduces VS Code configuration files, CMake presets, and updates the CMakeLists.txt to support MSVC and Windows-based development. Feedback on these changes highlights several critical issues: compiling demo source files directly into test executables will cause duplicate main symbol linker errors, and relying on CMAKE_BUILD_TYPE for compiler flags is problematic with multi-configuration generators like Visual Studio. Additionally, the reviewer suggests using modern target-specific include directories, improving task portability by avoiding PowerShell-specific commands and shell chaining, applying Windows preprocessor definitions to MinGW builds, and removing hardcoded Windows SDK versions from VS Code settings.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Test targets duplicate main ✓ Resolved 🐞 Bug ≡ Correctness

Description

The new GTest executables compile the demo .cpp files that define int main(), while also linking
GTest::gtest_main, which will cause duplicate-main linker errors when tests are enabled.

Code

CMakeLists.txt[R95-103]

+if(GTest_FOUND AND EXISTS "${CMAKE_SOURCE_DIR}/tests")
    enable_testing()

-    add_executable(fix_parser_test tests/unit/test_fix_parser.cpp)
-    target_link_libraries(fix_parser_test trading_core GTest::gtest GTest::gtest_main)
-    add_test(NAME FIXParserTest COMMAND fix_parser_test)
-
-    add_executable(order_manager_test tests/unit/test_order_manager.cpp)
-    target_link_libraries(order_manager_test trading_core GTest::gtest GTest::gtest_main)
-    add_test(NAME OrderManagerTest COMMAND order_manager_test)
-
-    add_executable(position_tracker_test tests/unit/test_position_tracker.cpp)
-    target_link_libraries(position_tracker_test trading_core GTest::gtest GTest::gtest_main)
-    add_test(NAME PositionTrackerTest COMMAND position_tracker_test)
+    if(EXISTS "${CMAKE_SOURCE_DIR}/tests/unit/test_fix_parser.cpp")
+        add_executable(fix_parser_test tests/unit/test_fix_parser.cpp
+                                       src/core/fix_parser.cpp)
+        target_link_libraries(fix_parser_test PRIVATE GTest::gtest GTest::gtest_main Threads::Threads)
+        add_test(NAME FIXParserTest COMMAND fix_parser_test)
+    endif()

Evidence

CMake adds src/core/fix_parser.cpp into the test executable and links GTest::gtest_main;
src/core/fix_parser.cpp contains its own int main(), so the test binary will end up with two
main() definitions.

CMakeLists.txt[95-103]
src/core/fix_parser.cpp[488-495]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The test targets (e.g., `fix_parser_test`) compile `src/core/*.cpp` files that contain demo `main()` functions, and also link `GTest::gtest_main` (which provides its own `main()`), causing multiple-definition/duplicate `main` link failures.

### Issue Context
Each `src/core/*.cpp` is currently a standalone demo translation unit with `int main()`. Tests should link only implementation code, not demo entry points.

### Fix Focus Areas
- CMakeLists.txt[95-117]
- src/core/fix_parser.cpp[488-505]
- src/core/order_manager.cpp[515-525]
- src/core/position_tracker.cpp[472-482]

### Proposed fix options
**Option A (recommended): split implementation from demos**
1. Move reusable code into new files without `main()` (e.g., `src/core/fix_parser_lib.cpp/.hpp`).
2. Keep demo entry points as small `*_demo_main.cpp` files that include/link the library code.
3. Link demos and tests against the shared library/object library.

**Option B: compile-time guard**
- Wrap each demo `main()` in `#ifndef QUANTEDGE_UNIT_TEST`.
- For `*_test` targets, add `target_compile_definitions(<test> PRIVATE QUANTEDGE_UNIT_TEST)`.
- Keep linking `GTest::gtest_main` (or drop it and provide your own test `main()`, but do not do both).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Invalid presets version type ✓ Resolved 🐞 Bug ≡ Correctness

Description

CMakePresets.json sets version as a string ("4") instead of a JSON number, which can make the
presets file invalid and prevent CMake/VS Code CMake Tools from loading any presets.

Code

CMakePresets.json[2]

+  "version": "4",

Evidence

The presets file currently declares the schema version as a string, which violates the expected JSON
type and can cause consumers to reject the file.

CMakePresets.json[1-4]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`CMakePresets.json` uses a string for the `version` field (`"4"`). CMake presets schema expects a JSON number, and tools may reject the file, breaking preset-driven configure/build.

### Issue Context
This PR relies on presets for VS Code tasks and CMake Tools integration; if presets don’t load, the workflow breaks.

### Fix Focus Areas
- CMakePresets.json[1-4]

### Proposed fix
- Change:
 - `"version": "4"`
 - to `"version": 4` (number, not quoted).
- (Optional) Ensure the repo documents a CMake minimum version that supports presets schema v4, if you intend to keep `version: 4`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. MSVC flags mis-scoped ✓ Resolved 🐞 Bug ☼ Reliability

Description

MSVC compile/link flags are selected using CMAKE_BUILD_TYPE and applied globally via
add_compile_options/add_link_options, which does not properly scope flags per Visual Studio
configuration and can result in Debug/Release builds using the wrong options depending on how the
build directory/config is used.

Code

CMakeLists.txt[R15-24]

+if(MSVC)
+    # Disable min/max macros that conflict with std::min/std::max
+    add_compile_definitions(NOMINMAX WIN32_LEAN_AND_MEAN _CRT_SECURE_NO_WARNINGS)
+
+    if(CMAKE_BUILD_TYPE STREQUAL "Release" OR NOT CMAKE_BUILD_TYPE)
+        add_compile_options(/O2 /Ob2 /GL /DNDEBUG)
+        add_link_options(/LTCG)
+    else()
+        add_compile_options(/Od /Zi /W4 /WX-)
+    endif()

Evidence

The presets select a Visual Studio generator while the CMakeLists chooses MSVC flags from
CMAKE_BUILD_TYPE and applies them globally, which is not configuration-scoped in a multi-config
generator world.

CMakeLists.txt[15-31]
CMakePresets.json[5-31]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The project uses the Visual Studio generator (multi-config), but the CMake logic chooses flags at *configure time* using `CMAKE_BUILD_TYPE` and applies them globally. With multi-config generators, configuration is typically selected at *build time* (e.g., `--config Debug/Release`), so global options won’t automatically vary per configuration.

### Issue Context
Presets set the generator to `Visual Studio 17 2022`. CMakeLists currently uses `if(CMAKE_BUILD_TYPE STREQUAL "Release" OR NOT CMAKE_BUILD_TYPE)` to pick one global flag set.

### Fix Focus Areas
- CMakeLists.txt[15-31]
- CMakePresets.json[5-31]

### Proposed fix
- Replace `CMAKE_BUILD_TYPE`-based branching for flags with configuration-scoped generator expressions, e.g.:
 - `add_compile_options($<$<CONFIG:Release>:/O2 /Ob2 /GL> $<$<CONFIG:Debug>:/Od /Zi>)`
 - `add_compile_definitions($<$<CONFIG:Release>:NDEBUG>)`
 - `add_link_options($<$<CONFIG:Release>:/LTCG>)`
- Prefer `target_compile_options()` / `target_link_options()` on the specific demo targets instead of global options to avoid unintended propagation.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. Launch config missing target ✓ Resolved 🐞 Bug ☼ Reliability

Description

VS Code launch.json always defines a debug configuration for market_data_receiver_demo.exe, but
CMake skips creating that target when Boost is not found, so launching that configuration will fail
in the supported no-Boost setup.

Code

.vscode/launch.json[R40-45]

+    {
+      "name": "Debug: market_data_receiver_demo",
+      "type": "cppvsdbg",
+      "request": "launch",
+      "program": "${workspaceFolder}/build_vs/debug/Debug/market_data_receiver_demo.exe",
+      "args": [],

Evidence

CMakeLists only creates market_data_receiver_demo when Boost is found, but VS Code always tries to
run the corresponding .exe from the build directory.

.vscode/launch.json[39-51]
CMakeLists.txt[75-90]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`market_data_receiver_demo` is conditionally built only when Boost is found, but the repo’s VS Code `launch.json` always points at `build_vs/debug/Debug/market_data_receiver_demo.exe`. When Boost is missing (a configuration the CMakeLists explicitly supports), this executable won’t exist and F5 will fail.

### Issue Context
CMakeLists prints a warning and skips the target when `Boost_FOUND` is false.

### Fix Focus Areas
- .vscode/launch.json[39-51]
- CMakeLists.txt[75-90]

### Proposed fix options
- Remove the `market_data_receiver_demo` launch configuration, or rename it to indicate it requires Boost.
- Alternatively, switch to CMake Tools-driven launch variables/commands so the debug config resolves only to existing targets (and won’t hardcode a path that may not be produced).
- If you keep it, add a clear comment in `launch.json` (and/or README) that Boost is required for that launch configuration.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---