I added an erase() function! A war story
-
I have a few little simple data structures in C++ that don't rely on the STL. They're exception free and meant primarily for embedded and IoT. My simple_vector<> had a clear() function that removed all elements but no erase() function that would remove a range of elements. Related background: I ran into a performance issue in my UIX library in the dirty rectangles routine. Basically the issue had to do with dirty rectangles being put into the list that were already covered by another rectangle in the list, causing UIX to draw the same area(s) twice in some situations. Sometimes this wasn't a problem, as upon insert I collapse already contained rectangles without adding them, and merge intersecting rectangles into one larger rectangle. However, there are situations where this isn't enough. What if you invalidate two dirty areas, creating two rects, and then invalidate the whole screen? One rect will have been consumed by the merging process but the second one has nothing to combine with. Enter the erase() function. My vector never needed one prior, because it's not a general purpose container, but rather a specialized/streamlined subset of a general vector meant for scalar data types only, and it was only being used in a certain way. I keep back propagating features into dependent libraries when I need something in my main lib, like htcw_uix relies on htcw_data, so as above when htcw_uix needed that feature I went back and added it to htcw_data and I'm not sure I like that, as it speaks to incomplete design? maybe. or maybe this is just the natural progression of iterative improvements in my codebase and I'm being too finicky about how it comes about. In any case, I'm probably overthinking it. But you should see my dependency tree for my major projects. In fact, here:
codewitch-honey-crisis/htcw_gfx @ ^1.636
codewitch-honey-crisis/htcw_bits @ ^1.0.7
codewitch-honey-crisis/htcw_data @ ^1.0.9
codewitch-honey-crisis/htcw_io @ ^1.1.43
codewitch-honey-crisis/htcw_ml @ ^0.1.3Those are just for my graphics library, which is the lone dependency of my user interface library, htcw_uix. Anyway, those dependent libraries only really get changed if I find bugs or if htcw_gfx or htcw_uix require them to be. Like I said, I don't know if I like that. Part of me thinks I should go through and round out some of the features in these libraries. Part of me thinks that's feature creep. All of me thinks I'm overanalyzing it. :~
Check out my IoT graphics librar
-
I have a few little simple data structures in C++ that don't rely on the STL. They're exception free and meant primarily for embedded and IoT. My simple_vector<> had a clear() function that removed all elements but no erase() function that would remove a range of elements. Related background: I ran into a performance issue in my UIX library in the dirty rectangles routine. Basically the issue had to do with dirty rectangles being put into the list that were already covered by another rectangle in the list, causing UIX to draw the same area(s) twice in some situations. Sometimes this wasn't a problem, as upon insert I collapse already contained rectangles without adding them, and merge intersecting rectangles into one larger rectangle. However, there are situations where this isn't enough. What if you invalidate two dirty areas, creating two rects, and then invalidate the whole screen? One rect will have been consumed by the merging process but the second one has nothing to combine with. Enter the erase() function. My vector never needed one prior, because it's not a general purpose container, but rather a specialized/streamlined subset of a general vector meant for scalar data types only, and it was only being used in a certain way. I keep back propagating features into dependent libraries when I need something in my main lib, like htcw_uix relies on htcw_data, so as above when htcw_uix needed that feature I went back and added it to htcw_data and I'm not sure I like that, as it speaks to incomplete design? maybe. or maybe this is just the natural progression of iterative improvements in my codebase and I'm being too finicky about how it comes about. In any case, I'm probably overthinking it. But you should see my dependency tree for my major projects. In fact, here:
codewitch-honey-crisis/htcw_gfx @ ^1.636
codewitch-honey-crisis/htcw_bits @ ^1.0.7
codewitch-honey-crisis/htcw_data @ ^1.0.9
codewitch-honey-crisis/htcw_io @ ^1.1.43
codewitch-honey-crisis/htcw_ml @ ^0.1.3Those are just for my graphics library, which is the lone dependency of my user interface library, htcw_uix. Anyway, those dependent libraries only really get changed if I find bugs or if htcw_gfx or htcw_uix require them to be. Like I said, I don't know if I like that. Part of me thinks I should go through and round out some of the features in these libraries. Part of me thinks that's feature creep. All of me thinks I'm overanalyzing it. :~
Check out my IoT graphics librar
honey the codewitch wrote:
What if you invalidate two dirty areas, creating two rects, and then invalidate the whole screen? One rect will have been consumed by the merging process but the second one has nothing to combine with.
Wouldn't invalidating the whole screen would be a special case where you don't care about the list of invalidated rect's?
honey the codewitch wrote:
Part of me thinks I should go through and round out some of the features in these libraries. Part of me thinks that's feature creep.
KISS and YAGNI would seem to apply here.
Software Zen:
delete this; -
honey the codewitch wrote:
What if you invalidate two dirty areas, creating two rects, and then invalidate the whole screen? One rect will have been consumed by the merging process but the second one has nothing to combine with.
Wouldn't invalidating the whole screen would be a special case where you don't care about the list of invalidated rect's?
honey the codewitch wrote:
Part of me thinks I should go through and round out some of the features in these libraries. Part of me thinks that's feature creep.
KISS and YAGNI would seem to apply here.
Software Zen:
delete this;Gary Wheeler wrote:
Wouldn't invalidating the whole screen would be a special case where you don't care about the list of invalidated rect's?
Yes, but I was using that example as illustrative of the general problem, which remains.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix