From 1ed086221d4dafa224b9998d38c180f78834b22c Mon Sep 17 00:00:00 2001 From: namark <namark@disroot.org> Date: Fri, 23 Apr 2021 04:26:10 +0400 Subject: [PATCH] if I ever get to it... --- source/simple/geom/pointer.hpp | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 source/simple/geom/pointer.hpp diff --git a/source/simple/geom/pointer.hpp b/source/simple/geom/pointer.hpp new file mode 100644 index 0000000..cf923ac --- /dev/null +++ b/source/simple/geom/pointer.hpp @@ -0,0 +1,28 @@ +// pointer into 2D span is (ptr, offset) and dimesntion_step common to all pointers of given range +// ptr is a pointer to exact memory location +// offset is the offset from the beginning of the current row +// dimesntion_step is the step to get from the end of row to begin of next row (pitch - width) +// +// begin != end returns a vector<bool,2> (should it be conjunction or disjunction??), indicating in which directions the end has been reached +// (begin.offset != end.offset, begin.ptr != end.ptr) +// (false, false) - we are safely inside the range +// (true, false) - we reached the end of the row +// (true, true) - we reached the end of the range +// (false, true) - not possible, invariant broken +// more complicated with more dimensions, when end is reached not all dimentins maybe true, only the first offset and the ptr +// ooorrrr, might be much simpler if say y oggset represents the number of pixel in current plane instead of y offset, so it'll go till width*height, and also increment with each step, hmmm... then z would be width*height*depth... it could escalate, however it's the same problem as with size_t or ptrdiff_t, the image still needs to fit in memory so these should not overflow... but definitely a potential limitation in more generic context, where image might not be in memory actually... with this we can get mote consistent and meanigful !=, and ++, however strictly speaking we will be doing more operations (simd though... simd can't do 3 integers and a pointer genious -_- ... but but I can dreaaam) aaand other comparison operators would also wooork, so cool +// +// end - begin returns a vector<ptrdiff_t, 2> +// (end.ptr - begin.ptr, end.offset - begin.offset) +// what is the meaning of this? +// da heck, why did i order of ptr and offset, now I have to think which order is better -_- +// +// ++ increments both ptr and offset +// how to jump to next row? maybe with a reset function? or an advance function? +// even increment not so simple in more dimensions so maye just use a separate step and +=, instead of increment +// +// basic missing concept is a vector with different type of coordinates with reduced set of operations and interoperability with normal numeric vectors +// might be worth it's own template, since the difference with generic vector is vast, though there must be a lowest common denominator +// TODO: implement, generalize to N dimensions +// compare to Boost.GIL which stores a pointer and pitch, various advantages and disatvantages, reimplement all the examples there!!! +// mixing does not make sense, order maybe does, but ptr is always out of order -- GitLab