aboutsummaryrefslogtreecommitdiff
path: root/common/span.h
AgeCommit message (Collapse)Author
2017-03-30COMMON: Reduce maximum Span size to 4GiBColin Snover
Until C++11 (which introduces the z and t length modifiers), there is no consistent way to print size_t and ptrdiff_t types using printf formatting across 32-bit, LLP64, and LP64 architectures without using a cumbersome macro to select the appropriate length modifier for the target architecture. Since ScummVM engines currently need to support 32-bit targets, there is no reason at the moment to support any larger memory sizes in Span anyway. Span error output is also updated in this commit to reflect that index values are unsigned.
2017-03-28COMMON: Compilation fix for Visual Studio 2015Paul Gilbert
The SpanImpl template was generating a bunch of C2248 errors that protected fields of the SpanBase template could not be accessed
2017-02-08COMMON: Fix calling Span::getStringAt with non-zero indexColin Snover
2017-01-15COMMON: Fix Variable Used Uninitialized Compiler Warning.D G Turner
2017-01-08COMMON: Fix GCC 4 shadow warnings in SpanColin Snover
2017-01-08COMMON: Simplify Span codeColin Snover
Implicitly generated constructors can be used instead of explicit constructors, which reduces the amount of necessary boilerplate. Long lists of identical typedefs to the superclass are now defined using a macro. data() const now returns a pointer to data that matches the value_type of the data, instead of forcing the data to be const. This better matches the intent of the Span class, which provides a view into data, rather than being a container that holds data.
2017-01-08COMMON: Restrict use of data access helpersColin Snover
The data access helpers as written are effectively little-endian when reading from spans with value_types larger than the size of the requested data (e.g. more than 1 byte for getting a char, more than 2 bytes for getting a uint16, etc.). For now, restrict use of these methods at compile time until someone actually needs to read memory that way.
2017-01-08COMMON: Improve test coverage for Span and fix bugs from testingColin Snover
2017-01-08COMMON: Add Span to common libraryColin Snover
Span is roughly modelled on the GSL span<T> type, and is intended to replace direct access to raw pointers -- especially pointers that are passed to functions along with a separate size parameter. It provides low-cost bounds-checked reads and writes, as well as convenience functions for reading common values (integers of varying endianness, strings, etc.). While similar to MemoryReadStream in purpose, Span is superior in cases where memory is writable, where memory is accessed randomly rather than sequentially, or where any invalid access should be treated as an unrecoverable error. It should also be more efficient than a MemoryReadStream because it is implemented using CRTP, so there is no runtime overhead from dynamic dispatch. NamedSpan is an extension of Span which provides enhanced debugging information when out-of-bounds memory accesses occur. It allows programmers to name the memory span at construction time, and it also tracks the offsets of subspans so that the absolute byte offset of the original memory can be provided in the error message if an out-of-bounds access occurs. SpanOwner is similar to ScopedPtr but has awareness of the design of Span objects, so allows the memory pointed to by the Span object inside the SpanOwner to be freed when the SpanOwner is freed without requiring holding a separate pointer to the start of memory. It also provides some copy semantics, so unlike a ScopedPtr, SpanOwners can be held by objects in movable containers like Common::Array -- but note that because there are no move semantics in C++98, this means that a new, complete memory copy of the pointed-to data will be created, rather than just a new Span pointing to the same block of memory, when a container holding a SpanOwner expands.