JH-Toolkit v1.4.1
An engineering-oriented C++20 toolkit with duck-typed concepts, static design, async coroutines, and semantic containers — header-only, RTTI-free, and concurrency-friendly.
Loading...
Searching...
No Matches
closable_container.h File Reference

Compile-time deduction of container closability — determining whether and how a container C can be directly constructed ("closed") from a range R. More...

#include <cstdint>
#include <ranges>
#include <type_traits>
#include <vector>
#include "jh/conceptual/container_traits.h"

Go to the source code of this file.

Namespaces

namespace  jh::concepts
 Behavioral concept namespace of the JH Toolkit.

Concepts

concept  jh::concepts::closable_container_for
 Concept checking whether a container C can be directly constructed ("closed") from a range R.

Detailed Description

Compile-time deduction of container closability — determining whether and how a container C can be directly constructed ("closed") from a range R.

Author
JeongHan-Bae <mastropseudo@gmail.com>

This header defines the closable container model — the conceptual basis for jh::ranges::to and its companion jh::ranges::collect. It classifies all possible construction paths between a container and a range, forming the foundation for the closable_container_for concept.

Purpose

In a range pipeline, a container closable from a range means that it can be built directly via iterators or an intermediate vector bridge, without explicit element-wise insertion. This allows the to adaptor to perform efficient, single-step construction.

Design rationale

  • Declarative deduction: All possible constructor paths are examined at compile time via requires expressions.
  • Non-intrusive: No specialization or overload resolution is required on the user's part.
  • Deterministic: The most specific viable construction path is chosen in a strictly ordered priority chain.

Move semantics and design constraint

Directly moving (consuming) the source range is semantically invalid. This restriction aligns with the intent of std::ranges::to and with the design of jh::ranges::to:
a range adaptor must never invalidate its source by stealing its state. Instead, all construction paths are iterator-based and non-destructive, preserving the observable validity of the source range.

In the JH framework, collect and to form a two-phase adaptation model:

  1. collect<V>() — explicitly materializes any lazy or proxy-based range into a stable, value-semantic container V.
  2. to<C>() — constructs the final container C from that materialization.

Performance note

Although closable_container_for never performs a direct move of the source object, this design imposes no runtime penalty.
When the source range is a prvalue (e.g. produced by collect), modern C++ compilers guarantee through RVO and NRVO that the intermediate container is constructed in-place, and element-wise initialization automatically uses move semantics rather than copy.
Therefore, collect + to achieves the same runtime efficiency as a single monolithic move construction, while preserving precise and standard-compliant semantics.

Core entities

  • jh::concepts::detail::closable_status — enumerates all construction modes.
  • jh::concepts::detail::compute_closable_status<C, R> — evaluates and selects the appropriate mode at compile time.
  • jh::concepts::closable_container_for<C, R> — concept determining if a container is closable from a range.

Relationship with other modules

Note
The closable_container_for concept is purely structural: it verifies, at compile time, that a container can be safely and deterministically constructed from a range, without performing any move or mutation of the source itself.
See also
jh::ranges::collect
jh::ranges::to
Version
1.3.x
Date
2025