 |
|
 |
Am I free to use it in my code ? Can I change the namespace ?
Its never too late.
|
|
|
|
 |
|
 |
shouldn't enumIdx be of type int ? Other than that, it's exactly what I needed to keep logs of commands and responses for a XNA drawn console
|
|
|
|
 |
|
 |
I know this article is ancient, but...
"I've specifically have not derived the CircularList" -- You have specifically have?
|
|
|
|
 |
|
 |
aspdotnetdev wrote: "I've specifically have not derived the CircularList" -- You have specifically h
I have not. It's correct as I wrote it.
Marc
Will work for food.
Interacx
I'm not overthinking the problem, I just felt like I needed a small, unimportant, uninteresting rant! - Martin Hart Turner
|
|
|
|
 |
|
 |
Really? Compare the two sentences below. The top is yours, and the bottom is what I think the corrected version should be.
"I've specifically have not derived the CircularList from List because I don't want to inherit the capabilities of .NET's generic List<T> class."
"I've specifically not derived the CircularList from List because I don't want to inherit the capabilities of .NET's generic List<T> class."
Anyway, it's a simple typo, so I'm sure most will not even notice it.
|
|
|
|
 |
|
 |
Hi Marc,
neat article, as always, thank you. I have a few minor questions:
Seeing the Clear() and SetAll() methods implementations I understand that the collection is meant for value types only (am I correct?), but how do you enforce it?
Wouldn't it be worth to loose the constraint, and change the two methods?
I see that the Clear() method cleans all the array content, but is it really needed? wouldn't just be enough writing:
public void Clear()
{
idx = -1;
loaded = false;
}
(please also note that I wrote idx = -1; why did you use zero?)
thank you in advance, I learnt a lot from your past articles.
Federico
|
|
|
|
 |
|
 |
Federico Sasso wrote: Seeing the Clear() and SetAll() methods implementations I understand that the collection is meant for value types only
I wouldn't have thought so. You can use any object type. What makes you think it is for value types only?
Federico Sasso wrote: Wouldn't it be worth to loose the constraint, and change the two methods?
What constraint? Am I missing something, because I don't see a constraint for value types only.
Federico Sasso wrote: wouldn't just be enough writing...
No, because that won't release the references to the objects in the array, and therefore won't release the objects to the garbage collector.
|
|
|
|
 |
|
 |
Hi Colin - Thanks for the excellent answer!
Marc
Thyme In The CountryInteracxPeople are just notoriously impossible. --DavidCrow There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith
|
|
|
|
 |
|
 |
Hi Colin, thank you for your reply
Colin Angus Mackay wrote: I wouldn't have thought so. You can use any object type. What makes you think it is for value types only?
MSDN clearly states that Array.Initialize() must not be used on reference-type arrays. I still didn't try its behaviour on them.
Colin Angus Mackay wrote: No, because that won't release the references to the objects in the array, and therefore won't release the objects to the garbage collector.
good point if we are talking about reference types
-- modified at 17:09 Wednesday 7th March, 2007
|
|
|
|
 |
|
 |
Federico Sasso wrote: I still didn't try its behaviour on them.
I've just tried it. It is a null operation on reference types.
class MyObject
{
int a = 0;
public override string ToString()
{
return string.Format("{{ a = {0} }}", this.a);
}
}
class Program
{
static void Main(string[] args)
{
MyObject[] a = new MyObject[10];
a[5] = new MyObject();
a[5].a = 10;
a.Initialize();
for (int i = 0; i < a.Length; i++)
{
Console.WriteLine("{0} = {1}", i, a[i]);
}
Console.ReadLine();
}
}
The result is that element 5 still has the reference type MyObject as inserted before the Initialise is called.
|
|
|
|
 |
|
 |
I tried it too but you've been quicker on posting
Being it a nop on reference types, it looks like the code has a little memory retention bug. Besides, the fix is quite simple.
Thank you
Federico
|
|
|
|
 |
|
 |
This is a very useful article. I was about to write a circular list, now I don't have to roll my own .
Thanks,
BillW
|
|
|
|
 |
|
 |
You should quickly define what a CircularList is because people might not know it with that name.
|
|
|
|
 |
|
|
 |
|
 |
James Curran wrote: I wrote this just last week....
Interesting also, because I spent a long time thinking about your comments in that other circular list article. It finally dawned on me that I needed more than an iterator, which is really only useable for read-only operations.
Thanks for the blog link though.
Marc
Thyme In The CountryInteracxPeople are just notoriously impossible. --DavidCrow There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith
|
|
|
|
 |
|
 |
Hi Marc,
I've just read and enjoyed your articles on Moving Average and Circular List.
I do have an issue with the enumerator provided by your circular list:
IMO GetEnumerator() should create and return a new object (not "this")
since it must be able to keep track of an enumeration state, even when more
than one enumeration of the collection is going on, as in:
int total = 0;
foreach (int a in collection) {
foreach (int b in collection) {
total += a*b;
}
}
AFAIK the ArrayList in ssCLI agrees with me:
public virtual IEnumerator GetEnumerator() {
return new ArrayListEnumeratorSimple(this);
}
Regards,
|
|
|
|
 |
|
 |
You're right, and the yield keyword would solve the problem cleanly.
IEnumerator GetEnumerator()
{
for (int i = 0; i<items.length; ++i)
{
yield return items[i];
}
}
|
|
|
|
 |
|
 |
Luc Pattyn wrote: should create and return a new object
Thanks for the feedback and your comment. You are of course correct! I'll update the code shortly.
Marc
Thyme In The CountryInteracxPeople are just notoriously impossible. --DavidCrow There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith
|
|
|
|
 |