Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Issue 9362 - Add a method to remove one item to std.container.SList #5784

Merged
merged 1 commit into from Oct 24, 2017

Conversation

Darredevil
Copy link
Contributor

https://issues.dlang.org/show_bug.cgi?id=9362

If everyone agrees with this I will go ahead and do the same for Dlist.

@dlang-bot
Copy link
Contributor

dlang-bot commented Oct 16, 2017

Thanks for your pull request, @Darredevil! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.

Some tips to help speed things up:

  • smaller, focused PRs are easier to review than big ones

  • try not to mix up refactoring or style changes with bug fixes or feature enhancements

  • provide helpful commit messages explaining the rationale behind each change

Bear in mind that large or tricky changes may require multiple rounds of review and revision.

Please see CONTRIBUTING.md for more information.

Bugzilla references

Auto-close Bugzilla Description
9362 Add a method to remove one item to std.container.SList

@Darredevil Darredevil force-pushed the issue-9362-slist-remove branch 2 times, most recently from 39dc2bb to 5973ce7 Compare October 16, 2017 13:39
Copy link
Member

@wilzbach wilzbach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of nits. I agree that this can be useful, but we plan to replace std.container soonish (hopefully by the end of the year with a new std.experimental.container library). Of course, deprecating std.container (and moving forward) will take a much longer time...

@@ -123,6 +123,19 @@ struct SList(T)
return n;
}

private static Node * findNodeByValue(Node * n, T value)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: style: Node*

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was trying to maintain the general style of the Slist implementation. I will update it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in https://wiki.dlang.org/Contributing_to_Phobos:

Be critical when looking at Phobos code (some parts of Phobos are a bit older and have some relics...)

And also in Contributing_to_Phobos#Code_style:

Stick to the style guide

@@ -123,6 +123,19 @@ struct SList(T)
return n;
}

private static Node * findNodeByValue(Node * n, T value)
{
assert(n);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs an error message, e.g. "The node can't be null"

(I know that there are other methods in this module don't do this either, but that's no reason to continue using the old style)


/**
Removes an element from the list in linear time.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Parameter block is missing.

*/
void linearRemoveElement(T value)
{
enforce(_first);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is removing 0 invalid?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also I think it would be better to return a boolean value - true iff the element existed and was successfully removed (false otherwise).

a.linearRemoveElement(4);
assert(equal(a[], [3]));
a.linearRemoveElement(3);
assert(a.empty());
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would need a test for the behavior when one value occurs multiple times.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added test for this.

while (ahead && ahead._payload != value)
{
n = ahead;
enforce(n);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you test n / ahead here? The loop body is only executed if ahead is evaluated to true (i.e. not null).

@@ -589,6 +602,39 @@ Complexity: $(BIGOH n)

/// ditto
alias stableLinearRemove = linearRemove;

/**
Removes an element from the list in linear time.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Define behavior when the value occurs multiple times (e.g. the list is iterated from front to back and the first match is removed).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example:

Removes the first an element from the list that equals `value` in $(BIGOH n) time.

@edi33416
Copy link
Contributor

LGTM


Complexity: $(BIGOH n)
*/
void linearRemoveElement(T value)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be better to return a boolean value - true iff the element existed and was successfully removed (false otherwise).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In which case, findNodeByValue should probably return null (without asserting) if _root is also null.

@Darredevil Darredevil force-pushed the issue-9362-slist-remove branch 2 times, most recently from b719d20 to 644716d Compare October 16, 2017 16:30
@Darredevil
Copy link
Contributor Author

@ZombineDev @wilzbach this PR should be ready for merge. Jenkins seems to be unhappy with something unrelated with this PR.

@Darredevil Darredevil force-pushed the issue-9362-slist-remove branch 2 times, most recently from 667cd59 to ff1b70f Compare October 17, 2017 13:16
Copy link
Member

@PetarKirov PetarKirov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. All of the findNode* functions could be refactored on top of range primitives if the SList(T).Range was implemented via Node**, but that's a topic for another day.

@wilzbach wilzbach added the @andralex Approval from Andrei is required label Oct 17, 2017
@wilzbach
Copy link
Member

Being a public symbol this still needs an approval from @andralex

@@ -123,6 +123,18 @@ struct SList(T)
return n;
}

private static Node* findNodeByValue(Node* n, T value)
{
assert(n, "Error: un-initialized List");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should return null for empty list

{
import std.algorithm.comparison : equal;

auto a = SList!int(-1, 1, 2, 1, 3, 4);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should test against an empty list

@andralex andralex removed the @andralex Approval from Andrei is required label Oct 17, 2017
@Darredevil
Copy link
Contributor Author

@andralex @ZombineDev should be ready for merge

{
auto n1 = findNodeByValue(_root, value);

// if node exists
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete

@andralex
Copy link
Member

@wilzbach this fails the style checker, which segfaults. I'll pull this, could you please investigate the matter?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants