jbcoe / value_types

value types for composite class design - with allocators

Value types for composite class design

This repository contains two class templates: indirect and polymorphic. Both templates are designed to be used for member data in composite types.

• An instance of indirect<T> owns an object of class T.

• An instance of polymorphic<T> owns an object of class T or a class derived from T.

Both classes behave as value types and allow special member functions for a class that contains them as members to be generated correctly. Our experience suggests that use of these class templates can significantly decrease the burden of writing and maintaining error-prone boilerplate code.

Standardization

We'd like to see indirect and polymorphic included in a future version of the C++ standard. Prior work on standardizing similar types, indirect_value and polymorphic_value can be found at

• A polymorphic value-type for C++

• indirect_value: A Free-Store-Allocated Value Type For C++

Design of these two types is so deeply coupled that future work will proceed in an updated paper.

Use

The indirect and polymorphic class templates are header-only. To use them, include the headers indirect.h and polymorphic.h in your project.

#include "indirect.h"

class Composite {
  xyz::indirect<A> a_; // a_ owns an object of type A
  xyz::indirect<B> b_; // b_ owns an object of type B
public:
  Composite(const A& a, const B& b) :
    a_(a),
    b_(b) {}

  // ...
};

#include "polymorphic.h"

class CompositeWithPolymorphicMembers {
  xyz::polymorphic<X> x_; // x_ owns an object of type X or derived from X
  xyz::polymorphic<Y> y_; // y_ owns an object of type Y or derived from Y
public:
  template <typename Tx, typename Ty>
  Composite(const Tx& x, const Ty& y) :
    a_(std::in_place_type<Tx>, x),
    b_(std::in_place_type<Ty>, y) {}

    // ...
};

Compiler explorer

You can try out indirect and polymorphic in Compiler explorer by adding the includes:

#include <https://raw.githubusercontent.com/jbcoe/value_types/main/indirect.h>
#include <https://raw.githubusercontent.com/jbcoe/value_types/main/polymorphic.h>

Compatibility

We have C++14 implementations of indirect and polymorphic available as indirect_cxx14.h and polymorphic_cxx14.h.

C++14 implementations can be tried out in compiler explorer by using the includes:

#include <https://raw.githubusercontent.com/jbcoe/value_types/main/indirect_cxx14.h>
#include <https://raw.githubusercontent.com/jbcoe/value_types/main/polymorphic_cxx14.h>

or by including headers indirect_cxx14.h and polymorphic_cxx14.h into your project.

We duplicate some code between the C++20 and C++14 implementations so that single-file includes work.

License

This code is licensed under the MIT License. See LICENSE for details.

Talks and presentations

We spoke about an earlier draft at C++ on Sea in 2022.

There are some significant design changes since this talk was given (after feedback and discussion at a C++ London meetup). We've pared down the number of constructors and made the null state unobservable.

Developer Guide

For building and working with the project, please see the developer guide.

GitHub codespaces

Press . or visit [https://github.dev/jbcoe/value_types] to open the project in an instant, cloud-based, development environment. We have defined a devcontainer that will automatically install the dependencies required to build and test the project.

References

• [TK's allocator user guide] (https://rawgit.com/google/cxx-std-draft/allocator-paper/allocator_user_guide.html)

• [A polymorphic value-type for C++] (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0201r5.html)

• [indirect_value: A Free-Store-Allocated Value Type For C++] (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1950r2.html)

• [GitHub codepsaces] (https://docs.github.com/en/codespaces/getting-started/deep-dive)

• [ISO C++ Standard - Draft] (https://eel.is/c++draft/)

value_types's Issues

Fix odd compile errors in SBO implementation of Polymorphic when constructing classes using pmr allocators

To reproduce the error:

1. Remove the preprocessor check in polymorphic_test.cc:
   #ifndef XYZ_POLYMORPHIC_USES_EXPERIMENTAL_SMALL_BUFFER_OPTIMIZATION

just before

TEST(PolymorphicTest, InteractionWithPMRAllocators)

2. Build polymorphic_sbo_test

There are errors in finding a valid constructor - for some reason allocator traits are trying to pass the allocator to the constructed object. We don't see this with other allocators or with the regular (non-SBO) polymorphic implementation.

Add comparisons with non-indirect objects for indirect

Find out which version of CMake we really need and correct cmake_minimum_required

R-value qualified operator* for indirect

Also including a rational for why this is not supported on Polymorphic (i.e. because you don't know the underlying type to move).

Add missing requires clauses

My minimal implementations don’t make any of the checks that they perhaps should. We’d get better compiler errors with the addition of concept checks. We need to be sure that incomplete types are still supported (like in indirect_value) though as that’s a useful use case (Pimpl).

Ideally we could check that the newly added requirements are doing the right thing in tests.

Remove use of deprecated typedef from `std::allocator`

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2868r1.pdf

Ensure Pointer type is allocator::pointer

This is be clear in the draft and implemented in the ref implementation so this is useable with offset pointer. For instance, this is needed to use with boost::interprocess allocators

Add formal wording for hash to indirect

Fixed by #77

Add benchmarks

Use https://github.com/google/benchmark to compare indirect and polymorphic with traditional component-based designs.

Write before/after code examples

We need examples of code that we can write with indirect/polymorphic and what that code would look like without them.

Update reference implementation to refer to xyz_lib value_types

Potential issue with optional<indirect> specialization

#include <optional>
#include <cassert>

#include <https://raw.githubusercontent.com/jbcoe/value_types/main/indirect.h>

template<class T, class U>
T exchange(std::optional<T>& opt, U&& value)
{
    assert(opt);
    T ret{std::move(*opt)};
    *opt = std::forward<U>(value);  // avoid unnecessary branch
    return ret;
}

int main()
{
    // This code will work for any T in place of int...
    std::optional<int> oi{3};
    auto ri = exchange(oi, 2);

    // ... except indirect<T> if we have a specialization for optional<indirect> 
    std::optional<xyz::indirect<int>> oii{3};
    auto rii = exchange(oii, xyz::indirect<int>(2));
}

https://godbolt.org/z/xb3M3jcse

Get SBO polymorphic to consider alignment requirements

Objects constructed in the small buffer may need to be correctly aligned.

Any change needs driving with a suitable test (maybe using ubsan).

Guidance on alignment can be taken from https://lesleylai.info/en/std-align/

Review and update noexcept status

The standard makes some functions conditionally noexcept, we should do the same.

Add discussion of noexcept

At the discussion in the LWEG group in Kona, Hawaii 2023 it was suggested that this type should follow the Lako rule. However these value types have been build to model std::unique_ptr and allocator aware types such as std::vector

Add tests with more complicated, real allocators

Variadic constructor of `indirect` is too greedy

In PR #128 we removed the parameter std::in_place_t from the variadic constructor of indirect:

template <class... Ts>
- explicit constexpr indirect(std::in_place_t, Ts&&... ts);
+ explicit constexpr indirect(Ts&&... ts);

The following snippet shows a simplified version of indirect and a (potentially contrived) scenario, where the variadic constructor might be too greedy:

#include <concepts>

template<class T>
struct indirect {
    indirect() = default;

    template<class ...Ts>
    explicit indirect(Ts&&... ts)
        requires std::constructible_from<T, Ts...> {}
};

struct Evil {
    Evil(indirect<Evil>&) {}
};

int main() {
    indirect<Evil> i1;
    indirect<Evil> i2(i1);
}

https://compiler-explorer.com/z/KWvzcnjY9

In the line indirect<Evil> i2(i1); we don't call the copy constructor of indirect (as I would expect as a user of indirect), but we call the variadic constructor as it is a better match. Note that it is only a better match as i1 is non-const. For a const indirect<Evil> the copy-constructor would still be called.
The first question is whether you all agree with me that indirect<Evil> i2(i1); should indeed call the copy-constructor or if you think that it is intentional design that it calls the variadic constructor. And if you agree, I think a fix would be to constraint the variadic constructor further. Something like:

template <class... Ts>
explicit constexpr indirect(Ts&&... ts)
- requires std::constructible_from<T, Ts&&...>;
+ requires (std::constructible_from<T, Ts...> &&
+     ( sizeof...(Ts) != 1 || !(std::same_as<std::remove_reference_t<Ts>, indirect> || ...) )
+ );

In prose: If the pack Ts consists of only one type U, make sure that U is not indirect&.

Get code coverage reports to ignore uncovered lines in tests.

We get code coverage drops because test files are not being covered. Possibly compiler cunning inlines things, possibly something else. At any rate it's annoying noise and should be silenced.

Quis custodiet ipsos custodes?

Add discussion of `operator[]` and `operator()`

Write README.md

Forward all comparison operator

There was discussion in LWEG suggesting this should be based on regular types, however, this is not inline with the intended design rational which just passes through underlying type operation. Add a discussion point expanding on this.

Constexpr-fy implementation and wording in the paper

Add change log

Present to C++ standards committee at Kona 2023 standards meeting

Scheduled to be presented in Kona In November https://github.com/orgs/cplusplus/projects/19/views/1?pane=issue&itemId=41839877

We need slides for a presentation preparing. We can base them on https://github.com/jbcoe/polymorphic_value/blob/main/talks/2022_07_05_CppOnSea.md

Incorporate all edits from private reviews

Discuss `emplace` method

Formatting of non-const-formattable types

Hi, this might be a contrived issue.
DRAFT.md#xy13-formatter-support-indirectfmt mentions the specialization of std::formatter<indirect<T, Alloc>, charT> when the underlying T supports specialisation of std::formatter<T, charT>. The format-function has the following signature (note that it takes the indirect by const&):

template<class FormatContext>
  typename FormatContext::iterator format(
    indirect<T, Alloc> const& value, FormatContext& ctx) const;

But there are some types T, where you can std::format a T&, but not a const T&. An example for such a type is std::ranges::filter_view<V, P>. In the following (contrived) example you can see how I can format a filter_view, but not an indirect<filter_view>:

#include <https://raw.githubusercontent.com/jbcoe/value_types/main/indirect.h>
#include <https://raw.githubusercontent.com/jbcoe/value_types/main/polymorphic.h>
#include <vector>
#include <ranges>
#include <print>

struct AllIn {
    bool operator()(int i) const { return true; }
};

int main() {
    std::vector v{1, 2, 3};
    auto filter = std::views::filter(v, AllIn{});
    std::println("filter = {}", filter);

    using FilterView = decltype(filter);
    xyz::indirect<FilterView> indirect(std::in_place, std::views::all(v), AllIn{});
    std::println("*indirect = {}", *indirect);
    std::println("indirect = {}", indirect); // error
}

So far I think this is a very contrived example and issue. But I at least wanted to make aware of it. In the future it might be worth it to extend formatting of indirect<T, A> to also work with non-const-formattable types.

Add feature test macros to draft

Update draft paper

Return type of comparison operators should not be bool (should be auto)

These must be auto to support pass-through of any return type.

Add missing design notes about optional

Fixed by #55

Add benchmarks to github workflow with a README badge

See

• https://werat.dev/blog/running-benchmarks-for-pull-requests-via-github-actions/

• https://github.com/benchmark-action/github-action-benchmark

• https://github.com/marketplace/actions/continuous-benchmark#

Add tests for object size

Ensure accessors have r-value qualified overload as `std::optional` does

Optional dereference: https://en.cppreference.com/w/cpp/utility/optional/operator*

Discuss comparisons returning `auto`

Get code coverage up to 100% for headers

Make `swap` ADL-proof

In the implementation of indirect and polymporphic swap gets called 8 times. Sometimes the member functions indirect::swap and polymorphic::swap (e.g. swap(tmp);) get called. And sometimes std::swap (https://eel.is/c++draft/utility.swap#lib:swap) on two pointers (e.g. swap(p_, other.p_) with using std::swap in the line above) gets called. The point is that swap gets called unqualified, i.e. it is subject to ADL. But we already know which overloads of swap we want to call and don't need/want different overloads to be picked by ADL. While there is no advantage in calling swap unqualified, there might be a disadvantage in doing so: I came up with an example, even though it is very contrived:

template<class T>
struct Holder { T value; };

class Incomplete;

template<class T>
struct X {};

using Indirect = xyz::indirect<X<Holder<Incomplete>>>;

void TestSwap(Indirect& a, Indirect& b)
{
    a.swap(b);
}

The snippet does not compile, as a.swap(b) makes an unqualified call to swap here. The arguments (p_ and other.p_) are of type X<Holder<Incomplete>>*. To perform ADL, the compiler has to instantiate several types, including Holder<Incomplete>. If you want to protect against this issue, I suggest to fully qualify all calls to swap.

If you want to have a more in depth discussion of the topic, I can recommend ADL can interfere even with uglified names and What is the std::swap two-step?.

Update polymorphic tests to work with SBO

Currently allocating tests fail as there is no need to allocate for small objects. We need different objects to force allocation.

Question about who no small object optimization?

This is just a question, sorry that I do not know where else to ask this.

I was skimming over the polymorphic_value papers and noticed that in the original paper small object allocation is encouraged, while in the new paper it is expressly called out as not supported. I would just like to better understand the reason for the change? Was this due to something learned from the implementation, or perhaps a reconsideration of the tradeoffs involved?

The new paper does not provide much explanation, other than saying that a small object implementation would need to be a different type (true, but does not explain why that type was not chosen for the implementation).

Raise code coverage by using type with throwing copy constructor

Use allocator traits for allocator propagation

Add support for comparison operators to indirect

I think we can port this from indiect_value but we now have no null state to consider which should make things easier.

Create C++11 implementations of indirect and polymorphic

@Ukilele would this be of interest to you?

Archive polymorphic_value and indirect_value

Archive the old repositories and redirect people (users) here.

Blocked by #18

Decipher compiler anomaly for polymorphic copy constructor

See https://godbolt.org/z/75v65MeWY

Behaviour is unexpected, we'd envisaged generated code to be the same (vtable lookup and a method call) - why do we need more indirection?

Privately circulate draft paper

Requires #22 to be completed

Publish draft paper

Requires feedback from #33 to be incorporated.

Go to isocpp.org to submit the paper with a new number

Add std::fmt support for indirect to draft and reference implementation

Add discussion of how indirect models or does not model variant (hash, comparisons etc)

Add discussion on similar type used to model value types (`std::unique_ptr`, `std::optional`, and allocator aware types such a `std::vector`)

We need to provide rational for the way in which value types have been models, particularly around handling of noexcept-ness which does not follow the Lakos rule.