boostorg / boostorg/icl

(split_)interval_map always preserve the values of the intersecting ranges during erase

Open
#44 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
16
Forks
50
PR merge metrics
No merged PRs in 30d

Description

Consider a test program

```C++
#include

#include

struct foo {
int v;
};

inline bool operator==(const foo &lhs, const foo &rhs) noexcept {
return lhs.v == rhs.v;
}

inline std::ostream &operator<<(std::ostream &os, const foo &u) {
return os << u.v;
}

template struct dummy_ {
using first_argument_type = T;
};

int main() {
using interval_map =
boost::icl::split_interval_map>;

interval_map tst;

for (int i = 0; i < 10; i += 2) {
tst.insert(std::make_pair(boost::icl::right_open_interval(i, i + 2),
foo{10 * i}));
}

std::cout << "map: " << tst << std::endl;

const boost::icl::right_open_interval test_range(3, 7);

std::cout << "after remove: ";
tst -= test_range;
std::cout << tst << std::endl;
}
```

The output of this program is going to be

```
map: {([0,2)->0)([2,4)->20)([4,6)->40)([6,8)->60)([8,10)->80)}
after remove: {([0,2)->0)([2,3)->20)([7,8)->60)([8,10)->80)}
```

This behavior is very surprising, because I would have expected that an `inter_sect` (in our case `dummy_`) f-tor would be used for the intersecting ranges [2,4) and [6,8). In my own use case, the correct output after removal should be

`after remove: {([0,2)->0)([2,3)->`**0**`)([7,8)->`**0**`)([8,10)->80)}`

But I see no way to achieve this with the current implementation of `erase(interval)`.

Contributor guide

No contributing guide indexed for this repository

Research direction

Run the supplied C++ reproducer first, then inspect boost/icl/split_interval_map.hpp and the erase(interval) path, including how the inter_sect functor is handled. Done means removing [3,7) applies the expected value 0 to the remaining portions of [2,4) and [6,8), matching the reported output.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.