📣 Call for testers & feedback — help us battle-test the PBR C++ Memory Pool (v1.1.2)

[danielPoloWork]

TL;DR

PBR C++ Memory Pool is a small, didactic, production-quality reference implementation of a fixed-block-size, O(1) memory pool with zero external fragmentation — a header-backed static library exposing a four-function C ABI and an idiomatic C++17 wrapper, built to an enterprise quality bar (warnings-as-errors, clang-tidy, ASan/UBSan/TSan, Valgrind, Doxygen) and documented decision-by-decision in 40 ADRs.

We have just shipped v1.1.2 (stable, API frozen at v1.0.0) and we are now actively looking for testers and feedback. If you write performance-sensitive C/C++, integrate third-party libraries via CMake/vcpkg/Conan, or care about allocator design and reproducible engineering, we would love you to kick the tires and tell us what breaks, what confuses you, and what is missing.

🌍 Language: this issue is in English because it is the project's normative documentation language (ADR-0032), but you are welcome to reply in any language — we are happy to read your feedback in yours. (The README is also available in 简体中文 and 日本語.)

---

Why this issue exists

The library has reached a level of maturity — full roadmap delivered (Milestones 0–8), a frozen public API, 40 ADRs, 11 catalogued design patterns, an in-repo bug ledger, and a green CI matrix across three OSes — where the most valuable thing we can get is real-world usage by people who are not the author. Automated tests and a single maintainer's dogfooding only go so far. We want to know how the pool behaves:

• on operating systems, compilers, and toolchains we do not exercise daily;
• integrated into real build systems (CMake find_package, add_subdirectory/FetchContent, vcpkg overlay port, Conan 2.x recipe);
• in the hands of someone reading the docs for the first time, with no prior context.

Your friction is our roadmap.

---

Who we are looking for

You do not need to be an allocator expert. We specifically want a mix of:

• 🧪 First-time users — you have never seen this library before. Your "I got stuck here" moments are gold.
• ⚙️ Systems / performance developers — you work with custom allocators, arenas, or object pools and can judge whether the design and the benchmark hold up.
• 📦 Packaging / build-system users — you consume libraries via CMake, vcpkg, or Conan and can tell us whether integration is painless in a real consumer project.
• 🪟🍎🐧 Cross-platform testers — Linux (GCC/Clang), Windows (MSVC), macOS (Apple Clang, arm64). CI is green on all three; we want it verified by hand on real machines.
• 📝 Docs & onboarding reviewers — you read the README / spec / ADRs / Doxygen API site and tell us where the explanation falls down.

---

What we would love you to test

Pick one or more — you do not have to do all of them.

1. Integrating the library into a consumer project (cross-platform)

There is no installer — the pool is a normal C/C++ dependency. Try whichever path fits your stack:

# Install to a prefix, then find_package (Phase 1 — ADR-0028)
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DPBR_MEMORY_POOL_BUILD_TESTS=OFF
cmake --build build && cmake --install build --prefix /your/prefix
# consumer CMakeLists.txt:  find_package(pbr_memory_pool CONFIG REQUIRED)  →  target pbr::memory_pool

# Or vendor it — same imported target either way
add_subdirectory(path/to/pbr-cpp-memory-pool)   # or FetchContent

# vcpkg overlay port (ADR-0030)
vcpkg install pbr-memory-pool --overlay-ports=ports

# Conan 2.x recipe (ADR-0031)
conan create conan/        # then depend on pbr-memory-pool/1.0.0

What to report: Did it build and link on your OS/compiler? Did find_package / the overlay port / the Conan recipe resolve cleanly? Is the imported-target name (pbr::memory_pool) what you'd expect? Registry publication (microsoft/vcpkg, ConanCenter) is still deferred, so the overlay/local paths are the ones we most need verified in the wild.

2. The four-function C API and the C++17 surface

Exercise the surface you'd actually use — the C core, the RAII Pool, the type-safe TypedPool<T>, the STL PoolAllocator<T>, or the InstrumentedPool decorator.

memory_pool_t* pool = memory_pool_create(64, 1024);  /* 1024 blocks of 64 bytes */
void* block = memory_pool_alloc(pool);               /* O(1); NULL when exhausted */
memory_pool_free(pool, block);                       /* O(1); back to the free list */
memory_pool_destroy(pool);

What to report: Does the C ABI drop into a C project cleanly? Do the C++ verbs (allocate/try_allocate, Pool::make, PoolBuilder, TypedPool::construct) read naturally? Does PoolAllocator<T> behave as expected backing std::list/std::map? Anything missing an enterprise consumer would need?

3. Optional features — thread safety & dynamic growth

Turn on the compile-time thread-safety toggle (Milestone 4) and/or opt into dynamic growth (Pool::make_dynamic, geometric contiguous chunks — ADR-0022).

What to report: Under real concurrent load, does the thread-safe config hold up (ideally under TSan)? Does dynamic growth behave sanely for your allocation pattern? Any surprises around pointer validity across growth?

4. Sanitizers, Valgrind & the benchmark

Run the CMake presets (asan, ubsan, debug, release) and the Valgrind and benchmark targets on your hardware.

cmake --preset asan && cmake --build --preset asan && ctest --preset asan --output-on-failure

What to report: Do ASan/UBSan stay green on your platform (POSIX only — sanitizer presets don't ship for MSVC)? Does Valgrind report 0 errors / definitely lost: 0 bytes? How does the pool compare to malloc/free over 1,000,000 iterations on your CPU? Please state OS, compiler+version, and flags so we can reproduce.

5. Docs & onboarding

Read the README, the spec, the Doxygen API site, and a couple of ADRs cold, and try to get to a working integration without asking us anything.

What to report: Where did you get stuck? What did you have to guess? What did you expect to find and didn't?

---

How to give feedback

The lowest-friction path is best. In rough order of preference:

1. 💬 Comment on this issue — even a one-liner ("built + linked on Fedora 40 / Clang 18, benchmark ~4× malloc, no problems") is genuinely useful.
2. 🐞 Open a separate issue for a concrete bug or feature request and link it here. Verified defects are tracked in our in-repo bug ledger with a documented triage protocol — reproducers are gold.
3. 🔒 Security-sensitive report? Please follow SECURITY.md instead of filing it publicly.
4. 🔁 If you want to contribute a change: we operate an inbound-trust model — we never silently merge external commits; a wanted change is adopted with co-authorship or re-implemented in-house, and you are always credited. So please do propose things.

Suggested feedback template (copy/paste into a comment)

**Tester profile:** (first-time / systems dev / packaging user / docs reviewer)
**OS & compiler:** (e.g. Ubuntu 24.04 / GCC 13, Windows 11 / MSVC 19.4, macOS 14 / Apple Clang 15)
**How I consumed it:** (find_package / add_subdirectory / FetchContent / vcpkg overlay / Conan)
**What I tried:** (integration / C API / C++ wrapper / PoolAllocator / thread-safe / dynamic growth / sanitizers / Valgrind / benchmark / docs)

**What worked:**
-

**What broke or confused me:**
-

**What I expected vs. what happened:**
-

**Benchmark (if run):** (pool vs malloc, iterations, CPU, flags)
**Severity for me:** (blocker / annoying / cosmetic / just a note)
**Would I use this again?** (yes / no / maybe — why)

---

Scope & expectations

• This is a call for evaluation, not a support contract — but we read everything and respond.
• No feedback is too small. "The README's third paragraph lost me" is as valuable as a stack trace.
• Negative feedback is especially welcome. We would rather hear it here than never hear it.
• Please be specific where you can: OS, compiler + version, integration method, flags, and the exact command help us reproduce.

---

Getting started in 30 seconds

• 📦 Latest release: https://github.com/danielPoloWork/pbr-cpp-memory-pool/releases/latest
• 📖 Docs: README · spec · API reference (Doxygen) · ADRs
• 🧭 What is this? A fixed-block-size, O(1), zero-external-fragmentation memory pool for C and C++17 — a focused, enterprise-grade building block from the Purpose-Built References (PBR) series.

Thank you for spending your time on this — every report, however short, directly shapes where this library goes next. 🙏

---

📌 This is a standing call — the issue is pinned and kept open on purpose. Feedback is welcome at any time, on any release.