Campbell Ritchie wrote:If you have a full 10‑length array, and remove the 3rd element, you will then try to copy the elements from element3→element2 until you get to element10→element9. And there you get the Exception. There is no need to copy into element9, because we already know what it should be: null. So you can do your copying up to element9→element8, then set element9 to null. The quickest way to do that is probably to combine the -- operator (or one of the -- operators ) with an assignment in the array. And you will have to make a few changes to i+1/i/i-1 in the copying loop.
Campbell Ritchie wrote:I thought we had discussed casting earlier in this thread. But that was about 97 years ago, so you may have forgotten. I think we decided you can either cast the whole array, once in the constructor, or each element as you retrieve it from the array
Campbell Ritchie wrote:I had never noticed that add(E) and add(int, E) had different return types. That seems very strange. I presume the List interface has the different return types, too. Just one of those things. I would have designed it with the same return type for both. You need a boolean return for add(E) because it is the same add method as used by Set (overridden from Collections), which sometimes does and sometimes doesn’t complete the addition. But add(int, E) can only operate on a List, so obviously it always adds the E successfully (or throws an Exception).
~ Mansukh
Good grief! Another triumph of Java generics.Mansukhdeep Thind wrote: . . . But still you ought to cast the element being removed using remove(int), or else there is a compile time error . . .
~ Mansukh
Yes, but I don’t think I said to use the -- operator inside the loop.Mansukhdeep Thind wrote: . . . But can it be be made more concise? . . .
~ Mansukh
Campbell Ritchie wrote:I would suggest
for (int i = index + 1; i < size; i++)
{
values[i - 1] = values[i];
}
That is about it Well, I think it is more elegant.
~ Mansukh
~ Mansukh
Campbell Ritchie wrote:What about set and get? They should be very easy.
~ Mansukh
Campbell Ritchie wrote:Yes. Neither set nor get should alter the size of the Collection.
~ Mansukh
~ Mansukh
~ Mansukh
Mansukhdeep Thind wrote:It is working properly.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Mansukhdeep Thind wrote:It is working properly.
Is it? My assumption is that you don't allow null entries then (or maybe it was already stated somewhere back in the dim and distant); I hope you've documented the fact.
Winston
~ Mansukh
Mansukhdeep Thind wrote:Here is the code with the null element check implemented...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
~ Mansukh
Mansukhdeep Thind wrote:
Mansukhdeep Thind wrote:How do you reckon I go about implementing the remove(T) method?
Jeff Verdegan wrote:
Mansukhdeep Thind wrote:
Why throw an exception if someone looks for null? Why not just return false? Not allowing us to add null shouldn't prevent us from asking if null is present.
Jeff Verdegan wrote:Also, if you wrote that method to use an iterator rather than accessing the backing array directly, you could promote the implementation to an abstract base class and re-use that same method implementation for LinkedList and other List implementations.
~ Mansukh
Jeff Verdegan wrote:Also, if you wrote that method to use an iterator rather than accessing the backing array directly, you could promote the implementation to an abstract base class and re-use that same method implementation for LinkedList and other List implementations.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Campbell Ritchie wrote:
I think it is the less severe of the two errors I can seeMansukhdeep Thind wrote:. . . What is the "sizeratio" for? . . .
Jeff Verdegan wrote:
Mansukhdeep Thind wrote:How do you reckon I go about implementing the remove(T) method?
As with any other method, start by figuring out the steps you'd follow to do it "manually" without any regard for Java or any other programming language.
~ Mansukh
Mansukhdeep Thind wrote:not sure I understand what you mean by this.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Mansukhdeep Thind wrote:
Jeff Verdegan wrote:
Why throw an exception if someone looks for null? Why not just return false? Not allowing us to add null shouldn't prevent us from asking if null is present.
Not false Jeff, -1 , since the return type is an int.
Here is the improved method:
I have made it final too as Winston so often advises.
Jeff Verdegan wrote:Also, if you wrote that method to use an iterator rather than accessing the backing array directly, you could promote the implementation to an abstract base class and re-use that same method implementation for LinkedList and other List implementations.
Not sure I understand what you mean by this.
David Blaine wrote:
Campbell Ritchie wrote:
I think it is the less severe of the two errors I can seeMansukhdeep Thind wrote:. . . What is the "sizeratio" for? . . .
Exactly. I don't know why the poster did not test the code before. Here is one link related to the buggy answer - What's the reason I can't create generic array types in Java?
~ Mansukh
Mansukhdeep Thind wrote:
Look good to you Jeff. Any flaws that you see?
Jeff Verdegan wrote:
Mansukhdeep Thind wrote:
Look good to you Jeff. Any flaws that you see?
Unless I missed something, you're always returning false, even if you found the object, and you're always decreasing the size of the list, even if you didn't find it. You're calling ensureNonNull() twice, and again, I think it's bad design to throw an exception just because they ask to remove an element that can't possibly be in there in the first place. It should be no different than asking to remove an element that just happens to not be there.
I didn't look closely at the code for fencepost errors, and I don't intend to.
It looks like you just slapped something together as fast as you could, without thinking carefully about it, and now are asking others to debug it for you. You should be testing these things. You should write unit tests that cover all the corner cases, plus a couple of middle cases. Ideally you should write these tests before you write the code they're testing.
~ Mansukh
Mansukhdeep Thind wrote:Why is it always that I am the one making foolish mistakes and you guys are the ones correcting it? Need to change this trend.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Mansukhdeep Thind wrote:Why is it always that I am the one making foolish mistakes and you guys are the ones correcting it? Need to change this trend.
Then StopCoding (←click).
Winston
~ Mansukh
Jeff Verdegan wrote:
Mansukhdeep Thind wrote:
Look good to you Jeff. Any flaws that you see?
Unless I missed something, you're always returning false, even if you found the object, and you're always decreasing the size of the list, even if you didn't find it. You're calling ensureNonNull() twice, and again, I think it's bad design to throw an exception just because they ask to remove an element that can't possibly be in there in the first place. It should be no different than asking to remove an element that just happens to not be there.
Jeff Verdegan wrote:I didn't look closely at the code for fencepost errors, and I don't intend to.
Jeff Verdegan wrote:It looks like you just slapped something together as fast as you could, without thinking carefully about it, and now are asking others to debug it for you. You should be testing these things. You should write unit tests that cover all the corner cases, plus a couple of middle cases. Ideally you should write these tests before you write the code they're testing.
~ Mansukh
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |