Prior to this, an xrange always started at the begin term and
incremented by 1 per step until it reached the end term. There was no
support for a step size other than 1. Add support for custom step size.
It is the caller's responsibility to pick a step size that will
eventually lead to (iter != end) evaluating to false.
gcc before gcc-7 failed to build valptridx:
```
common/include/valptridx.h: In instantiation of 'valptridx<managed_type>::ptridx<policy>::ptridx(const valptridx<managed_type>::ptridx<rpolicy>&) [with rpolicy =
valptridx<dcx::segment>::vm; typename std::enable_if<(policy:: allow_nullptr || (! rpolicy:: allow_nullptr)), int>::type <anonymous> = 0; policy = valptridx<dcx::segment>::vc; managed_type = dcx::segment]':
similar/main/endlevel.cpp:586:105: required from here
common/include/valptridx.h:686:14: error: 'using vptr_type = class valptridx<dcx::segment>::ptr<valptridx<dcx::segment>::vm>' is protected within this context
vptr_type(static_cast<const typename ptridx<rpolicy>::vptr_type &>(rhs)),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
common/include/valptridx.h:666:31: note: declared protected here
using vptr_type = ptr<policy>;
```
This cannot be fixed in the obvious way because the error message is
wrong:
```
664 using containing_type = valptridx<managed_type>;
665 public:
666 using vptr_type = ptr<policy>;
667 using vidx_type = idx<policy>;
668 using typename vidx_type::array_managed_type;
```
The type declarations _already are_ *public*, not *protected* as the
message states. Relaxing the protection on the containing class
resolves the error. This looks bad from an encapsulation perspective,
but does not make the code incorrect.
For correctness, valptridx::ptridx instances must not be sliced down to
their component ::ptr or ::idx base classes. Previously, this was done
with a dummy template parameter to ensure that a bare ::idx had a
different type than the idx base of a ::ptridx. This extra distinction
complicates analysis of the code, and is not needed when the code is
already correct. Add the ability to build without slice checking.
clang-9 reports:
```
similar/main/mglobal.cpp:210:44: error: 'report_error_uses_exception' is a protected member of 'valptridx_specialized_type_parameters<unsigned char, 90, valptridx_untyped_utilities::report_error_style::exception, valptridx_untyped_utilities::report_error_style::exception>'
template <typename T, bool = valptridx<T>::report_error_uses_exception::value>
^
similar/main/mglobal.cpp:229:16: note: in instantiation of default argument for 'instantiation_guard<dcx::active_door>' required here
template class instantiation_guard<dcx::active_door>::type::index_range_exception;
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
common/include/fwd-valptridx.h:42:2: note: constrained by protected inheritance here
protected valptridx_specialized_types<managed_type>::type
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
common/include/cpp-valptridx.h:175:8: note: member is declared here
using report_error_uses_exception = std::integral_constant<bool,
```
Add a `using` statement to switch `report_error_uses_exception` to
`public` access. Nothing else uses it, and there is no design purpose
served by keeping it `protected`.
For each link given as http://, verify that the site is accessible over
https:// and, if so, switch to it. These domains were converted:
* llvm.org
* clang.llvm.org
* en.cppreference.com
* www.dxx-rebirth.com
* www.libsdl.org
* www.scons.org
Remove the `basic_` prefix from valptridx<T>::basic_ptr, ::basic_idx,
and ::basic_ptridx. Since the public names are typedef aliases of these
classes, these class names appear frequently in debug information and
error messages. The `basic_` prefix is unnecessary. Remove it.
git grep -lz '\<basic_\(ptr\|ptridx\|idx\)\>' -- common/include/ | xargs -0 sed -i -e 's/\<basic_\(ptr\|ptridx\|idx\)\>/\1/g'
Previously, valptridx used PREFIX for allow-invalid+mutable, c#PREFIX
for allow-invalid+const, v#PREFIX for require-valid+mutable, vc#PREFIX
for require-valid+const. Convert the types, factories, and all usage
sites to specify a qualifier for all four combinations:
im#PREFIX -> allow-invalid+mutable
ic#PREFIX -> allow-invalid+const
vm#PREFIX -> require-valid+mutable
vc#PREFIX -> require-valid+const
Changes to common/include/valptridx.h and common/include/fwd-valptridx.h
are manual. All other changes are generated by:
git grep -lz -e '\(obj\|seg\|clwall\|wall\|actdoor\|trg\)\(ptridx\|ptr\|idx\)\(_t\)\?\>' | xargs -0 sed -i -e 's/\<\(v\?\)\(\(obj\|seg\|clwall\|wall\|actdoor\|trg\)\(ptridx\|ptr\|idx\)\(_t\)\?\)\>/\1m\2/g'
for the 'm' prefix and:
git grep -lz -e '\(obj\|seg\|clwall\|wall\|actdoor\|trg\)\(ptridx\|ptr\|idx\)\(_t\)\?\>' | xargs -0 sed -i -e 's/\<\([cm]\(obj\|seg\|clwall\|wall\|actdoor\|trg\)\(ptridx\|ptr\|idx\)\(_t\)\?\)\>/i&/g'
for the 'i' prefix.
By design, valptridx will throw an exception on invalid input. This is
better than silently permitting invalid input to corrupt program state.
Past releases blindly trusted that multiplayer peers would not send
invalid input. Conversion to the valptridx design eliminated the
undefined behavior when peers send invalid input, but still allowed
multiplayer peers to remotely crash the game by sending invalid inputs.
Add a mechanism to trap invalid inputs and gracefully ignore those
messages. This may cause game consistency issues, but will not allow
data corruption.
The declaration of valptridx_specialized_types needed to be found by
Argument Dependent Lookup, but this was inconvenient for some types.
Split the declaration of valptridx_specialized_types out from the
definition of valptridx global subtype.
The segiter code used objptridx because end is signalled by object_none,
and vobjptridx does not allow object_none. However, the compiler
produces better code if segment_object_range_t returns vobjptridx and
future cleanups are easier if iterating objects_in yields vobjptridx
objects. Add a special-case override of the normal checking rules, move
the required checks into segiter, and then let segiter break the rules
normally enforced by valptridx. Add a comment explaining that this
permits unsafe coding and should be done only with a clear understanding
of the responsibilities it brings.
