Timeline for Progress bar wrapper class in C++
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 27, 2018 at 7:35 | comment | added | Toby Speight |
True (about constness of standard iterators) - there are both const and non-const versions, returning different kinds of iterator. I think we shouldn't need to deal with that, because a progress bar can wrap Container::const_iterator or Container::iterator equally well. Which pushes me towards the view begin() and end() don't need to be const (but I'm still somewhat "on the fence").
|
|
| Sep 26, 2018 at 21:01 | comment | added | Jesse van Rhijn |
I had it take a pointer before; same issue there. Probably the best way to get begin()/end() const is to rework the design like you suggested. On the other hand, I don't think they're always const for STL iterators either (example). I'll have to think about it a bit more. In any case. thanks for all the help, it's been beyond useful!
|
|
| Sep 26, 2018 at 20:13 | comment | added | Toby Speight |
You can initialize size_, too (rather than assigning after it has been default-initialized). You might be able to make begin() and end() const by taking a pointer instead of a reference, but that seems... unclean. It's slightly weird that advancing an iterator changes the state of its owner, so maybe we have to accept that they can't be const. Alternatively, perhaps we should be storing a pair of wrapped iterators, rather than keeping the originals around? That's a whole different approach I don't have time to investigate right now, but it might be worth exploring.
|
|
| Sep 26, 2018 at 19:38 | history | answered | Jesse van Rhijn | CC BY-SA 4.0 |