Added Generic, ordered map (rbt) #24339
Conversation
lib/std/map.zig
Outdated
| parent: ?*Node, | ||
|
|
||
| fn init(allocator: Allocator, key: K, value: V) !*Node { | ||
| const node = try allocator.create(Node); |
There was a problem hiding this comment.
This style of allocation would be a perfect fit for the MemoryPool allocator.
lib/std/map.zig
Outdated
| }; | ||
|
|
||
| /// Generic Map implementation (Red Black Tree similar to std::map) | ||
| pub fn Map(comptime K: type, comptime V: type) type { |
There was a problem hiding this comment.
Map is vague. It is going to be the first thing users find when searching for something mappish in the standard library but they definitely want to find the hashmaps first instead. I would suggest RBTree or maybe OrderedMap, to reflect more on the use case of this datastructure.
lib/std/map.zig
Outdated
| try float_map.insert("e", 2.71828); | ||
|
|
||
| try testing.expectApproxEqRel(@as(f64, 3.14159), float_map.get("pi").?, 0.00001); | ||
| try testing.expectApproxEqRel(@as(f64, 2.71828), float_map.get("e").?, 0.00001); |
There was a problem hiding this comment.
Are these approximate equals necessary? I think they should be used when doing computation on floats, but in this case i would expect to get the byte-for-byte same output as my input.
lib/std/map.zig
Outdated
| return Iterator{ .current = self.minimum(self.root) }; | ||
| } | ||
|
|
||
| fn compare(self: *const Self, a: K, b: K) i32 { |
There was a problem hiding this comment.
This compare function should probably be provided as an optional argument to the map, to allow custom comparisons. Similar to how the hash maps do it.
|
Prior art:
|
^