|
'cept it's a list. Collection doesn't guarantee order. List does, and provides indexed access, which my queue does.
I'll consider QueueList, thanks
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
When Microsoft extend something they usually (well quite often) add the suffix Ex. So how about QueueEx ? Does it not show up in Reference Source[^]?
|
|
|
|
|
They do that more in Win32 and COM than .NET
Usually with .NET they just stick new objects under a new namespace and try to name them differently.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
How is about _001<t>
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Bob.
Bob<T> myBob = new Bob<T>();
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
|
Oooh, I like that one. I'll definitely consider it. So far it looks like it might be a winner.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
That was my first thought as well.
You beat me to it!
|
|
|
|
|
honey the codewitch wrote: I wish Microsoft would have simply exposed the internal method they have in the reference source
Add an extension method and use reflection to call it.
Oh wait, you said efficient indexing.
|
|
|
|
|
Yeah, I was gonna say.
Not only that, it's kind of terrible to rely on a non-public method in someone else's code.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
From the top of my head.
public static T GetAtIndex(this Queue<T> queue, int index)
{
T obj = default(T);
int count = queue.Count;
for (int i = 0; i < count; i += 1)
{
T temp = queue.Dequeue();
if (i == index)
{
obj = temp;
}
queue.Enqueue(temp);
}
return obj;
} I'm pretty sure that's how Microsoft intended it
It's lightning fast if you have only a few items and you don't do it too often
Or you could do whatever you're doing an name it IndexedQueue , like Greg also suggested.
|
|
|
|
|
That reorders the queue. I can't have my indexing have side effects. If I didn't have to worry about that your solution would be a decent one.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
I misread your code. I thought you were just enumerating until you found the item.
Anyway, I'm not sure that would be faster. See based on what I know from the reference source, there's no reallocations taking place with your technique. It's just setting array elements and incrementing some integers.
Reflection can be kinda nasty. I'd have to profile. It definitely depends on the number of items in the queue as well, but for what I'm currently using it for, it shouldn't be more than a half dozen to a couple dozen items.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
I did not wrap the queue. I implemented my own queue over an array, wrapping like Microsoft's class does.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Yeah, that really seems the best, and most labor and time intensive method, for something so easy that could've been there at no extra effort
|
|
|
|
|
LOL, blame microsoft. I really shouldn't have had to reinvent the wheel here.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
"... but that doesn't really jibe with microsoft's naming conventions either."
That is of zero concern for me. I couldn't care less what their conventions are. Mostly because I detest what they have done with the Win32 SDK names of structures and members. I'll use what ever convention(s) I feel like using. Here's one example : they continue to use this long pointer prefixing "LP..." on things. We haven't had to deal with long pointers since the 32-bit SDK came into being. The whole large-model programming thing was horrendous and I resent being reminded of it. For this reason, I never, ever use a LP prefix for anything. For the items I access that have to use it I always make a typedef to avoid it.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Well they're of concern to me, which is why I brought them up. And as far as Win32 goes, it's not .NET where naming is concerned. Entirely different ballgame.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Yes, I know those are different things, but my point is/was microsoft has changed directions with naming conventions so many times that I can't care less about conforming to their standards.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I can totally understand that. I'm a little more forgiving I guess. Or I just see different naming patterns to be appropriate in different contexts - I switch up myself. In fact, in C++ I have a few different naming and coding styles and conventions I use depending on the particular "realm" I'm coding in. Different languages, different conventions, too.
But that's me. To each their own.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
ImpQueue<t>
Could be for ImprovedQueue...but also since imps are little demons...
But, also IdxQueue<t> could work too.
|
|
|
|
|
Some time ago I reported that, when debugging C++ in VS2017, you can't always see what a unique_ptr is managing[^]. The same thing sometimes happens with other containers, such as <list> or <set> . That is, you can inspect the container's private members, but not the items that it actually holds.
I'm starting to think there's something wrong with my system, given that this problem report has attracted no interest. But if you've experienced it, please upvote the item so that they will fix it instead of triaging it.
|
|
|
|
|
I use VS2017 but have never experienced this problem. Do you have a code snippet that always demonstrates the issue?
|
|
|
|