ares-openbsd/nall/vector.hpp

158 行
5.1 KiB
C++
Raw パーマリンク 通常表示 履歴

#pragma once
#include <new>
#include <nall/array-span.hpp>
#include <nall/array-view.hpp>
#include <nall/bit.hpp>
#include <nall/function.hpp>
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 12:59:29 +09:00
#include <nall/iterator.hpp>
#include <nall/maybe.hpp>
#include <nall/memory.hpp>
#include <nall/merge-sort.hpp>
#include <nall/range.hpp>
#include <nall/traits.hpp>
#include <nall/view.hpp>
namespace nall {
template<typename T>
struct vector_base {
using type = vector_base;
//core.hpp
vector_base() = default;
vector_base(const initializer_list<T>& values);
vector_base(const type& source);
vector_base(type&& source);
~vector_base();
explicit operator bool() const;
operator array_span<T>();
operator array_view<T>() const;
template<typename Cast = T> auto capacity() const -> u64;
template<typename Cast = T> auto size() const -> u64;
template<typename Cast = T> auto data() -> Cast*;
template<typename Cast = T> auto data() const -> const Cast*;
//assign.hpp
auto operator=(const type& source) -> type&;
auto operator=(type&& source) -> type&;
//compare.hpp
auto operator==(const type& source) const -> bool;
auto operator!=(const type& source) const -> bool;
//memory.hpp
auto reset() -> void;
auto acquire(T* data, u64 size, u64 capacity = 0) -> void;
auto release() -> T*;
auto reserveLeft(u64 capacity) -> bool;
auto reserveRight(u64 capacity) -> bool;
auto reserve(u64 capacity) -> bool { return reserveRight(capacity); }
auto reallocateLeft(u64 size) -> bool;
auto reallocateRight(u64 size) -> bool;
auto reallocate(u64 size) -> bool { return reallocateRight(size); }
auto resizeLeft(u64 size, const T& value = T()) -> bool;
auto resizeRight(u64 size, const T& value = T()) -> bool;
auto resize(u64 size, const T& value = T()) -> bool { return resizeRight(size, value); }
//access.hpp
auto operator[](u64 offset) -> T&;
auto operator[](u64 offset) const -> const T&;
auto operator()(u64 offset) -> T&;
auto operator()(u64 offset, const T& value) const -> const T&;
auto left() -> T&;
auto first() -> T& { return left(); }
auto left() const -> const T&;
auto first() const -> const T& { return left(); }
auto right() -> T&;
auto last() -> T& { return right(); }
auto right() const -> const T&;
auto last() const -> const T& { return right(); }
//modify.hpp
auto prepend(const T& value) -> void;
auto prepend(T&& value) -> void;
auto prepend(const type& values) -> void;
auto prepend(type&& values) -> void;
auto append(const T& value) -> void;
auto append(T&& value) -> void;
auto append(const type& values) -> void;
auto append(type&& values) -> void;
auto insert(u64 offset, const T& value) -> void;
auto removeLeft(u64 length = 1) -> void;
auto removeFirst(u64 length = 1) -> void { return removeLeft(length); }
auto removeRight(u64 length = 1) -> void;
auto removeLast(u64 length = 1) -> void { return removeRight(length); }
auto remove(u64 offset, u64 length = 1) -> void;
auto removeByIndex(u64 offset) -> bool;
auto removeByValue(const T& value) -> bool;
auto takeLeft() -> T;
2022-09-13 16:47:47 +09:00
auto takeFirst() -> T { return std::move(takeLeft()); }
auto takeRight() -> T;
2022-09-13 16:47:47 +09:00
auto takeLast() -> T { return std::move(takeRight()); }
auto take(u64 offset) -> T;
//iterator.hpp
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 12:59:29 +09:00
auto begin() -> iterator<T> { return {data(), 0}; }
auto end() -> iterator<T> { return {data(), size()}; }
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 12:59:29 +09:00
auto begin() const -> iterator_const<T> { return {data(), 0}; }
auto end() const -> iterator_const<T> { return {data(), size()}; }
auto rbegin() -> reverse_iterator<T> { return {data(), size() - 1}; }
auto rend() -> reverse_iterator<T> { return {data(), (u64)-1}; }
Update to v106r47 release. byuu says: This is probably the largest code-change diff I've done in years. I spent four days working 10-16 hours a day reworking layouts in hiro completely. The result is we now have TableLayout, which will allow for better horizontal+vertical combined alignment. Windows, GTK2, and now GTK3 are fully supported. Windows is getting the initial window geometry wrong by a bit. GTK2 and GTK3 work perfectly. I basically abandoned trying to detect resize signals, and instead keep a list of all hiro windows that are allocated, and every time the main loop runs, it will query all of them to see if they've been resized. I'm disgusted that I have to do this, but after fighting with GTK for years, I'm about sick of it. GTK was doing this crazy thing where it would trigger another size-allocate inside of a previous size-allocate, and so my layouts would be halfway through resizing all the widgets, and then the size-allocate would kick off another one. That would end up leaving the rest of the first layout loop with bad widget sizes. And if I detected a second re-entry and blocked it, then the entire window would end up with the older geometry. I started trying to build a message queue system to allow the second layout resize to occur after the first one completed, but this was just too much madness, so I went with the simpler solution. Qt4 has some geometry problems, and doesn't show tab frame layouts properly yet. Qt5 causes an ICE error and tanks my entire Xorg display server, so ... something is seriously wrong there, and it's not hiro's fault. Creating a dummy Qt5 application without even using hiro, just int main() { TestObject object; } with object performing a dynamic\_cast to a derived type segfaults. Memory is getting corrupted where GCC allocates the vtables for classes, just by linking in Qt. Could be somehow related to the -fPIC requirement that only Qt5 has ... could just be that FreeBSD 10.1 has a buggy implementation of Qt5. I don't know. It's beyond my ability to debug, so this one's going to stay broken. The Cocoa port is busted. I'll fix it up to compile again, but that's about all I'm going to do. Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both resize windows very quickly now. higan crashes when you load a game, so that's not good. bsnes works though. bsnes also has the start of a localization engine now. Still a long way to go. The makefiles received a rather substantial restructuring. Including the ruby and hiro makefiles will add the necessary compilation rules for you, which also means that moc will run for the qt4 and qt5 targets, and windres will run for the Windows targets.
2018-07-14 12:59:29 +09:00
auto rbegin() const -> reverse_iterator_const<T> { return {data(), size() - 1}; }
auto rend() const -> reverse_iterator_const<T> { return {data(), (u64)-1}; }
//utility.hpp
auto fill(const T& value = {}) -> void;
auto sort(const function<bool (const T& lhs, const T& rhs)>& comparator = [](auto& lhs, auto& rhs) { return lhs < rhs; }) -> void;
auto reverse() -> void;
auto find(const function<bool (const T& lhs)>& comparator) -> maybe<u64>;
auto find(const T& value) const -> maybe<u64>;
auto findSorted(const T& value) const -> maybe<u64>;
auto contains(const T& value) const -> bool;
auto foreach(const function<void (const T&)>& callback) -> void;
auto foreach(const function<void (u64, const T&)>& callback) -> void;
protected:
T* _pool = nullptr; //pointer to first initialized element in pool
u64 _size = 0; //number of initialized elements in pool
u64 _left = 0; //number of allocated elements free on the left of pool
u64 _right = 0; //number of allocated elements free on the right of pool
};
}
#define vector vector_base
#include <nall/vector/core.hpp>
#include <nall/vector/assign.hpp>
#include <nall/vector/compare.hpp>
#include <nall/vector/memory.hpp>
#include <nall/vector/access.hpp>
#include <nall/vector/modify.hpp>
#include <nall/vector/iterator.hpp>
#include <nall/vector/utility.hpp>
#undef vector
namespace nall {
template<typename T> struct vector : vector_base<T> {
using vector_base<T>::vector_base;
};
}
#include <nall/vector/specialization/u8.hpp>