digitalmars.D - How to iterate over const(RedBlackTree)?
- Cooler (10/10) Jan 02 2014 Example:
- monarch_dodra (9/19) Jan 02 2014 Currently, this is not possible. Or if it was, it would have a
- Adam D. Ruppe (12/14) Jan 02 2014 It is possible in theory; RBT returns a separate Range type with
- monarch_dodra (5/21) Jan 02 2014 Right. Doable, but not trivially so :/
- John McFarlane (8/34) Oct 16 2014 I'm trying to get to grips with D, coming from a C++ background
- monarch_dodra (10/48) Oct 17 2014 Currently, D containers don't offer "ConstRange opSlice() const"
Example: const RedBlackTree!int rbt = redBlackTree(1, 2, 3); foreach(i; rbt[]) writeln(i); dmd 2.064 give me error "mutable method std.container.RedBlackTree!int.RedBlackTree.opSlice is not callable using a const object" Without "const" keyword the example compiled and works fine. How can I iterate over const?
Jan 02 2014
On Thursday, 2 January 2014 at 11:23:39 UTC, Cooler wrote:Example: const RedBlackTree!int rbt = redBlackTree(1, 2, 3); foreach(i; rbt[]) writeln(i); dmd 2.064 give me error "mutable method std.container.RedBlackTree!int.RedBlackTree.opSlice is not callable using a const object" Without "const" keyword the example compiled and works fine. How can I iterate over const?Currently, this is not possible. Or if it was, it would have a *very* high code cost inside RBT. The issue is that *if* opSlice was marked as const, then the returned range would also be const, and you can't iterate over that :/ A solution might be possible, but the current "status quo" is to not use const with ranges. It's one of the "issues" with D-style qualification: It's "apples all the way down".
Jan 02 2014
On Thursday, 2 January 2014 at 13:30:06 UTC, monarch_dodra wrote:Currently, this is not possible. Or if it was, it would have a *very* high code cost inside RBT.It is possible in theory; RBT returns a separate Range type with opSlice that is implemented in terms of pointers to node. (This is hidden by an alias RBNode!Elem* Node, which gets in the way, but if those were inout(RBNode)* or const()* it'd work). We can have mutable pointers to const data, which would work with the range. So opSlice returns a mutable range that points back to const data. But in this case, none of the functions in rbtree use const nor inout, and there's some caching (e.g. _left and _right) that I'm not sure can work with it at all anyway. In a const node, the left and right properties won't work..
Jan 02 2014
On Thursday, 2 January 2014 at 14:59:55 UTC, Adam D. Ruppe wrote:On Thursday, 2 January 2014 at 13:30:06 UTC, monarch_dodra wrote:Right. Doable, but not trivially so :/ Array might be able to pull it off more easily. That said, it would only solve the "const container => Range" issue, but the "const range" problem itself would remain :(Currently, this is not possible. Or if it was, it would have a *very* high code cost inside RBT.It is possible in theory; RBT returns a separate Range type with opSlice that is implemented in terms of pointers to node. (This is hidden by an alias RBNode!Elem* Node, which gets in the way, but if those were inout(RBNode)* or const()* it'd work). We can have mutable pointers to const data, which would work with the range. So opSlice returns a mutable range that points back to const data. But in this case, none of the functions in rbtree use const nor inout, and there's some caching (e.g. _left and _right) that I'm not sure can work with it at all anyway. In a const node, the left and right properties won't work..
Jan 02 2014
On Friday, 3 January 2014 at 07:22:32 UTC, monarch_dodra wrote:On Thursday, 2 January 2014 at 14:59:55 UTC, Adam D. Ruppe wrote:I'm trying to get to grips with D, coming from a C++ background and const correctness is tough thing to get comfortable with. I've got a member variable that's RedBlackTree and I'd like to examine its contents inside an invariants() block. Is this possible at all right now? Obviously, this would be trivial to achieve using std::set::const_iterator so is it the language or the library that poses the difficulty for me? Thanks.On Thursday, 2 January 2014 at 13:30:06 UTC, monarch_dodra wrote:Right. Doable, but not trivially so :/ Array might be able to pull it off more easily. That said, it would only solve the "const container => Range" issue, but the "const range" problem itself would remain :(Currently, this is not possible. Or if it was, it would have a *very* high code cost inside RBT.It is possible in theory; RBT returns a separate Range type with opSlice that is implemented in terms of pointers to node. (This is hidden by an alias RBNode!Elem* Node, which gets in the way, but if those were inout(RBNode)* or const()* it'd work). We can have mutable pointers to const data, which would work with the range. So opSlice returns a mutable range that points back to const data. But in this case, none of the functions in rbtree use const nor inout, and there's some caching (e.g. _left and _right) that I'm not sure can work with it at all anyway. In a const node, the left and right properties won't work..
Oct 16 2014
"monarch_dodra" <monarchdodra gmail.com> On Friday, 17 October 2014 at 01:09:00 UTC, John McFarlane wrote:On Friday, 3 January 2014 at 07:22:32 UTC, monarch_dodra wrote:Currently, D containers don't offer "ConstRange opSlice() const" (which would be the equivalent of const_iterator). This could be a good solution the the issue. But to answer your question: Both the language and library that are making your life difficult. For starters, the D language does not use const the way C++ does, so this usually confuses the zealous newcomers that want to be "const correct". The library is also getting in your way in that it does not provide support for "const(container/range)" nor "container of const".On Thursday, 2 January 2014 at 14:59:55 UTC, Adam D. Ruppe wrote:I'm trying to get to grips with D, coming from a C++ background and const correctness is tough thing to get comfortable with. I've got a member variable that's RedBlackTree and I'd like to examine its contents inside an invariants() block. Is this possible at all right now? Obviously, this would be trivial to achieve using std::set::const_iterator so is it the language or the library that poses the difficulty for me? Thanks.On Thursday, 2 January 2014 at 13:30:06 UTC, monarch_dodra wrote:Right. Doable, but not trivially so :/ Array might be able to pull it off more easily. That said, it would only solve the "const container => Range" issue, but the "const range" problem itself would remain :(Currently, this is not possible. Or if it was, it would have a *very* high code cost inside RBT.It is possible in theory; RBT returns a separate Range type with opSlice that is implemented in terms of pointers to node. (This is hidden by an alias RBNode!Elem* Node, which gets in the way, but if those were inout(RBNode)* or const()* it'd work). We can have mutable pointers to const data, which would work with the range. So opSlice returns a mutable range that points back to const data. But in this case, none of the functions in rbtree use const nor inout, and there's some caching (e.g. _left and _right) that I'm not sure can work with it at all anyway. In a const node, the left and right properties won't work..
Oct 17 2014