|
|
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?
|
|
|
|
|
A code snippet wouldn't help because it's sporadic. Sometimes works, sometimes doesn't, for the same code.
|
|
|
|
|
I've gone through 4 of these [^] over the last few years and after about a year the keys start sticking and get worse quickly. Looking for an inexpensive mechanical keyboard!
Something like an abacus but with more keys.
They call me different but the truth is they're all the same!
JaxCoder.com
|
|
|
|
|
My current keyboard was made by DEC. The previous one was made by IBM (circa 1997).
|
|
|
|
|
Yeah I'm thinking that would be the most inexpensive way to go. Feabay has IBM PS/2 for $25 wired and I can get an PS/2 to USB adapter for another $6!
They call me different but the truth is they're all the same!
JaxCoder.com
|
|
|
|
|
just lay off the PB&J's when you're coding, no keyboard can withstand those
this internet has become nothing but fake news.
... time to fix it, time to get back to the fax!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
