ryuu3160/cpon

1. What this repository is

CPON is a C++20 / MSVC-oriented library for a custom object notation format, with both text (.cpon) and binary (.cponb) representations. The repo is organized as a library source tree plus a NuGet packaging layer.

2. Core runtime library

The main implementation lives under CPON/src/. This is the architectural center of the project and contains the reusable C++ code that consumer applications compile or package against.

3. Primary subsystems in the core

The source files split into three obvious responsibilities:

- cpon.hpp / cpon.cpp: top-level API and format handling entry points

- cpon_object.hpp / cpon_object.cpp: object/data model for CPON entities

- cpon_binary_helper.hpp / cpon_binary_helper.cpp: binary format support and translation logic

4. Data model boundary

cpon_object.* is the boundary between parsing/serialization logic and the in-memory representation. It likely models CPON objects, fields, arrays, nested objects, and metadata such as counts/types shown in the README examples.

5. Text format flow

The text CPON flow is: source .cpon content → parser/reader in cpon.* → structured object model in cpon_object.* → optional modification → serialization back to text. The sample files output.cpon and output_modified.cpon suggest round-trip read/edit/write behavior.

6. Binary format flow

Binary support is separated into cpon_binary_helper.*, which indicates a distinct encode/decode path for .cponb. The presence of output.cponb and the README “binary file support” note make binary a first-class serialization target rather than an afterthought.

7. Consumer-facing API surface

cpon.hpp is the likely public header, while the other headers expose supporting types. A consumer would primarily interact through this API rather than directly with the internal file layout.

8. Example / verification harness

CPON/Test/main.cpp is a small executable-style test harness used to exercise the library. It is not a separate subsystem; it validates parsing, conversion, and output generation against the sample artifacts.

9. Build and IDE boundary

CPON/CPON.vcxproj, its filters file, the solution file CPON.slnx, and CPON/cpp.hint show this repo is designed for Visual Studio / MSBuild workflows. The project boundary is conventional C++ source-based compilation, not a framework-managed runtime.

10. NuGet distribution path

The CPON.NuGet/ subtree is a packaging mirror of the core library. It contains:

- a .nuspec

- native build targets under build/native/CPON.targets

- contentFiles/cpp/... copies of the headers and sources

This means the library is distributed to downstream C++ projects through NuGet, with build integration handled by package targets.

11. Important architectural duplication

The same core code appears in both CPON/src/ and CPON.NuGet/contentFiles/cpp/any/any/. That duplication indicates two delivery modes:

- direct repository build for development

- packaged source delivery for consumption by other projects

12. External constraints that shape the architecture

The README explicitly targets Windows 10+, MSVC, and C++20. Those constraints matter because the project is optimized for Visual Studio-native C++ builds and package integration, rather than cross-platform runtime portability.

13. How to draw the architecture

A clean diagram would show:

- Consumer application / test program

- CPON public API (cpon.hpp)

- **Object model (cpon_object.*)**

- **Binary helper (cpon_binary_helper.*)**

- Text and binary CPON files as input/output boundaries

- NuGet packaging layer as a distribution path parallel to the source tree