I am on the war path for runtime memory usage and it's getting hot in here.
5
0
12
Isn't this what the extract/(re)insert idiom I supposed to address? If you are manipulating the key, pull the node out of the map, fix it, the re-insert that node.
2
0
1
Can I extract the node and then refuse to re-insert it?
1
0
0
Yes, but you are responsible for destroying it. I cannot remember if the extracted wrapper will do that for you. Your problem is that the iterator in the for loop is probably looking at this node too - I missed the loop traversal considerations in my hasty reply.
2
0
2
I can rewrite the loop: at that point it'd just be a separate problem of getting all the keys, using that key list to extract, and then destroying the nodes. I'm trying to avoid needing an extra std::vector<key> or something to make this "completely legal".
1
0
0
The node handle does have a destructor, and it does destroy if it can't find the key: en.cppreference.com/w/cpp/co… I think what I can do is have a statically-sized array of keys: key key_list[MAX_KEYS]{}; Then iterate up to MAX_KEYS, copy them in, then extract/destroy, then repeat.
1
0
1
This feels like doing extra iterations though.... saving runtime size of the map is the goal, so maybe it's okay to take a little stack space, maybe make it configurable for the end-user.
1
0
0
Why not While (! map. empty ()){ auto node = map.extract(map.begin()); }
1
0
0
... Oh, that probably does the trick then! I thought extract() only took a key, but if it takes an iterator that makes it all legal then, doesn't it?!
2
0
1
Ahh it looks so nice!
1
0
0
Nice Now i understand the use case for the node interface, thanks !

3:15 AM · Jan 15, 2021

0
0
0