[WIP] fmsolvr: backported changes; structured FMSolvr as a polyrepo project #24

Merged

i.kabadshow merged 7 commits from m.zych/fmsolvr:WIP/minimize-reference into WIP/minimize-reference

2023-07-21 12:37:14 +02:00

m.zych commented

2023-07-07 13:47:40 +02:00

Member

No description provided.

m.zych added 7 commits

2023-07-07 13:47:41 +02:00

[WIP] fmsolvr: backported 'simple vector default construct inplace' 1df2835cd0

commit c4e370ef27
Author: David Haensel <d.haensel@fz-juelich.de>
Date:   Thu Sep 22 12:41:46 2016 +0200

[WIP] fmsolvr: parameterized octree with the node_type 2e4d25661c

The octree is a generic container,
which stores elements of any type as its nodes.

The fact that FMSolvr instantiates only octrees parameterized by:
 - counter_tuple_wrapper<tuple>
 - ObjectWrapper<ObjectType, ObjectAccessStrategy>
 - MultipoleCoefficients[Upper, UpperLower]<Real>
which apparently were considered containers, is completely irrelevant,
because the octree should be oblivious to how FMSolvr is using it.

Moreover, the octree should define its size_type
based on properties of its implementation, to ensure that
storing maximum supported number of elements is handled correctly.

Concretely, the octree theoretically supports storing as many elements,
as there are bytes in the virtual address space,
therefore the std::size_t type was chosen as octree's size_type.

Lastly, the octree should *not* assume that
the node_type contains nested size_type,
since the octree should support fundamental data types: int, float, etc.

[WIP] fmsolvr: removed unused template parameter from OctreeStorageDense 8fd7165180

[WIP] fmsolvr: replaced tabs with spaces in rotation_matrix_vector.hpp 937f483fed

[WIP] fmsolvr: replaced direct usages of allocators with accesses through std::allocator_traits<> 5cc8a0d4cc

[C++ reference] - std::allocator

 ~ https://en.cppreference.com/w/cpp/memory/allocator


[P0619R4] - Reviewing Deprecated Facilities of C++17 for C++20

  D.9 The default allocator [depr.default.allocator]

      Strong recommendation: Undeprecate std::allocator<T>::size_type
                             and std::allocator<T>::difference_type, and
                             remove the remaining deprecated parts
                             from the C++20 standard.

      Toronto Review:        Accept strong recommendation,
                             strike from C++20.

~ https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0619r4.html


[P0174R2] - Deprecating Vestigial Library Parts in C++17

    Deprecate the redundant members of std::allocator

    Many members of std::allocator redundantly duplicate behavior
    that is otherwise produced by std::allocator_traits<allocator<T>>,
    and could safely be removed to simplify this class. (...)

    While we cannot remove these members
    without breaking backwards compatibility
    with code that explicitly used this allocator type,
    we should not be recommending their continued use.

    If a type wants to support generic allocators, it should
    access the allocator's functionality through allocator_traits
    rather than directly accessing the allocator's members - otherwise
    it will not properly support allocators that
    rely on the traits to synthesize the default behaviors.

    Similarly,
    if a user does not intend to support generic allocators,
    then it is much simpler to directly invoke new, delete,
    and assume the other properties of std::allocator
    such as pointer-types directly.

~ https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0174r2.html


[N2946] - Allocators post Removal of C++ Concepts

  The allocator_traits struct

    The keystone of this proposal is the definition of
    an allocator_traits template containing
    types and static member functions for using allocators,
    effectively replacing the Allocator concept
    that was lost in Frankfurt.

    A container, C<T,Alloc> accesses all allocator functionality
    through allocator_traits<Alloc> rather than
    through the allocator itself.

    For example, to allocate n objects, a container would call:

        auto p = allocator_traits<Alloc>::allocate(myalloc, n);

    instead of

        auto p = myalloc.allocate(n);

~ https://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2009/n2946.pdf

[WIP] fmsolvr: refactored the Continuous Integration script 8aa9dcd949

[WIP] fmsolvr: structured FMSolvr as a polyrepo project 89ebe3789a