Okay guys. This saturday I am going to be competing in a competition as man 1 on a team of 3 programmers.
This will be my first time doing competitive programming. 7 problems, 5 hours, thunderdome style. We'll be using Java. I have looked over a ton of the previous years' problems and I am confident in my ability to figure most of them out, but for anyone who has competed in the The Most Nerdiest Game, any advice?
Be very familiar with geometry problems. Intersections, points inside polygons, etc.
Also, being on a team in these kinda sucks, in my experience. It is hard to balance feelings and contest performance. Are you good friends with the others?
Okay guys. This saturday I am going to be competing in a competition as man 1 on a team of 3 programmers.
This will be my first time doing competitive programming. 7 problems, 5 hours, thunderdome style. We'll be using Java. I have looked over a ton of the previous years' problems and I am confident in my ability to figure most of them out, but for anyone who has competed in the The Most Nerdiest Game, any advice?
Be very familiar with geometry problems. Intersections, points inside polygons, etc.
Also, being on a team in these kinda sucks, in my experience. It is hard to balance feelings and contest performance. Are you good friends with the others?
One of them yes, but he's pretty subservient to me when it comes to CS. He's actually really good, but he regards me as strictly better, so I guess that's good. The third guy I don't believe either of us know, so we should be able to stick a hierarchy onto it.
Split up the work. If one gets too difficult move on to another one. COMMUNICATION IS KEY! Nothing worse than having two people working on the same thing without each other's knowledge.
e: Are you allowed to bring a cheat sheet? If not you could probably email yourself a word document that has the things Infidel mentioned.
Split up the work. If one gets too difficult move on to another one. COMMUNICATION IS KEY! Nothing worse than having two people working on the same thing without each other's knowledge.
e: Are you allowed to bring a cheat sheet? If not you could probably email yourself a word document that has the things Infidel mentioned.
We're allowed to bring no electronics, and as much paper as we want.
So we're bringing about a ream or so of notes about commonly used tasks and stuff so we can reduce the amount of peripheral thinking we have to do, and work on the task at hand instead of "let's remember how to parse an input string from standard input the way they want it"
But yeah, make sure you have common geometry problems covered one way or another. Over half of them relied on them in the few contests I've done.
Based on the problem sets from previous years, my experiences in programming CORA (my XBL Indie Game that's on the backburner) has given me an incredible advantage when it comes to spatial reasoning in 2 dimensions. That's basically all I did for like 80-100+ hours of programming that thing.
An example that comes to mind was a problem you could visualize as a pegboard. Take an elastic and stretch it over the pegs in some fashion (so the input is some closed polygon with given coordinates). Count the non-border pegs contained within it.
An example that comes to mind was a problem you could visualize as a pegboard. Take an elastic and stretch it over the pegs in some fashion (so the input is some closed polygon with given coordinates). Count the non-border pegs contained within it.
A lot of stuff like that you'll run into.
One of the problems from two years ago was like that, except you had to start at the origin and count directions and distances clockwise around. The trick was how you know which direction was clockwise, but it wasn't too difficult to suss out.
Last year there was a problem requiring you to make an algorithm that would generate the links between pages of a map, based on a big map made of a grid of smaller maps, and you would output basically which grid element the given side of your grid element would link to.
Just a few minutes ago I remembered that Django already has a decent way for me to create those partial indexes within Django's framework all automated, intended to be used like this, and able to do stuff for specific database backends safely. I completely forgot that it had a mechanism for taking .sql files until this afternoon.
Yes, I get it now. I'll be keeping type safety in mind from now on and how that effects where I can do the cast. If I was thinking of type safety it would have been easier to figure out where to put the cast. I'll also remember the disadvantages of filling a vector of objects with different enumerations. This was a good lesson. I'm going to go through the program and comment it/clean it up now.
One thing: they aren't different enumerations. They're all the same enumeration - PaperCurrency - they just have different values. The key thing is, everything in the vector is the same type.
Proper type safety isn't about checking before you cast: it's making sure you don't have to.
Just a few minutes ago I remembered that Django already has a decent way for me to create those partial indexes within Django's framework all automated, intended to be used like this, and able to do stuff for specific database backends safely. I completely forgot that it had a mechanism for taking .sql files until this afternoon.
Well shit, there you go. That's just what you need! :P
0
baronfelWould you say I havea _plethora_?Registered Userregular
So this is an ugly C# question, but I'm curious - is there a way to programmatically perform a drag operation on a WPF view? I specifically want to trigger an event on the view that occurs when a drag operation completes....or maybe I'm looking at this the wrong way, I can just invoke the event! Yes, no, maybe?
Yeah. You don't want the drag, you want the event triggered. So, trigger the event.
0
baronfelWould you say I havea _plethora_?Registered Userregular
Yeah, the problem is it's a timing issue. I'm using SandDock and trying to emulate a Chrome-like behavior for the tabs, where if you float it out the tab is embedded in a new instance of the app.
So, SandDock can let me know when a view changes DockState to Float, but I can't directly call the "Send to a new window" method because it involves closing the view and cleaning up after itself, and SandDock won't let you modify the view when it's in the middle of a DockChange (which the float and all associated event handlers count as). So what I really need is that delayed way to call the send method that won't block in the DockStateChanged method handler.
In my entire time in college I never learned instanceof for Java. I just learned it at my new job, and it's the greatest thing ever.
Keep in mind that instanceof leads to decidedly unobject-oriented code. You should treat it (and casting) as the devil unless you can justify dealing with the devil for your particular problem.
@TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
Okay guys. This saturday I am going to be competing in a competition as man 1 on a team of 3 programmers.
This will be my first time doing competitive programming. 7 problems, 5 hours, thunderdome style. We'll be using Java. I have looked over a ton of the previous years' problems and I am confident in my ability to figure most of them out, but for anyone who has competed in the The Most Nerdiest Game, any advice?
Get a good nights sleep before hand. Measure twice, cut once (design the program before writing it out), if they allow books, bring one on common datastructures. Version control is your friend.
In my entire time in college I never learned instanceof for Java. I just learned it at my new job, and it's the greatest thing ever.
Keep in mind that instanceof leads to decidedly unobject-oriented code. You should treat it (and casting) as the devil unless you can justify dealing with the devil for your particular problem.
That makes sense. In my case I'm working with a WYSIWYG editor for work, so instanceof has helped me display a lot of different things correctly to the screen.
0
SarksusATTACK AND DETHRONE GODRegistered Userregular
Yes, I get it now. I'll be keeping type safety in mind from now on and how that effects where I can do the cast. If I was thinking of type safety it would have been easier to figure out where to put the cast. I'll also remember the disadvantages of filling a vector of objects with different enumerations. This was a good lesson. I'm going to go through the program and comment it/clean it up now.
One thing: they aren't different enumerations. They're all the same enumeration - PaperCurrency - they just have different values. The key thing is, everything in the vector is the same type.
Proper type safety isn't about checking before you cast: it's making sure you don't have to.
Sorry, I didn't mention the fact that there are three other enumerations (MiscCards, Photos, Credit Cards) that are being put into the wallet. That's what I meant. If it had only been one enumeration it would have been a lot simpler. I would have just made the vector of the type PaperCurrency.
Yes, I get it now. I'll be keeping type safety in mind from now on and how that effects where I can do the cast. If I was thinking of type safety it would have been easier to figure out where to put the cast. I'll also remember the disadvantages of filling a vector of objects with different enumerations. This was a good lesson. I'm going to go through the program and comment it/clean it up now.
One thing: they aren't different enumerations. They're all the same enumeration - PaperCurrency - they just have different values. The key thing is, everything in the vector is the same type.
Proper type safety isn't about checking before you cast: it's making sure you don't have to.
Sorry, I didn't mention the fact that there are three other enumerations (MiscCards, Photos, Credit Cards) that are being put into the wallet. That's what I meant. If it had only been one enumeration it would have been a lot simpler. I would have just made the vector of the type PaperCurrency.
That's an... interesting way of going about teaching OOP and polymorphism.
Okay guys. This saturday I am going to be competing in a competition as man 1 on a team of 3 programmers.
This will be my first time doing competitive programming. 7 problems, 5 hours, thunderdome style. We'll be using Java. I have looked over a ton of the previous years' problems and I am confident in my ability to figure most of them out, but for anyone who has competed in the The Most Nerdiest Game, any advice?
Get a good nights sleep before hand. Measure twice, cut once (design the program before writing it out), if they allow books, bring one on common datastructures. Version control is your friend.
So true.
Be very familiar with your language's implementation of common data structures - lists, hash maps, sets, etc.
In 5 hours, try not to reinvent the wheel too much!
Yes, I get it now. I'll be keeping type safety in mind from now on and how that effects where I can do the cast. If I was thinking of type safety it would have been easier to figure out where to put the cast. I'll also remember the disadvantages of filling a vector of objects with different enumerations. This was a good lesson. I'm going to go through the program and comment it/clean it up now.
One thing: they aren't different enumerations. They're all the same enumeration - PaperCurrency - they just have different values. The key thing is, everything in the vector is the same type.
Proper type safety isn't about checking before you cast: it's making sure you don't have to.
Sorry, I didn't mention the fact that there are three other enumerations (MiscCards, Photos, Credit Cards) that are being put into the wallet. That's what I meant. If it had only been one enumeration it would have been a lot simpler. I would have just made the vector of the type PaperCurrency.
That's an... interesting way of going about teaching OOP and polymorphism.
Yeaah. And the polymorphism section is the next one. We haven't done polymorphism and inheritance yet. I'm about to start reading the notes/text on that, actually.
Well "currency" would be your interface rather than any polymorphic concept.
Your base class would be "cards" or something. They can all perform a type of payment system (currency) and are worth something, they're values built into the polymorphic objects, they're not objects themselves.
If I were designing that I'd probably have all the objects inherit from a card type, and be store-able in a wallet type, and have some function that allows me to perform a transaction in terms of currency. PaperCurrency would just be a form of "card" in this case... though card would probably be a silly name for it in general.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
However! You shouldn't be using a vector of objects, you should be using a generic collection (and almost certainly an ArrayList over a Vector, but that's for minor reasons that aren't too important right now):
Vector<PaperCurrency> wallet = new Vector<PaperCurrency>();
Why aren't you using generic collections? That is probably a question for whoever is teaching you.
So what's wrong with vectors? I use a vector pretty much any time a collection requires adding or removing elements at runtime. My last assignment required a multi-user set, and because users could be created and deleted at runtime I used a vector to store them. Would something else have been better?
Polymorphism, much like anything in CS world, is so very confusing at first. But the moment you see it in action it just clicks.
Yeah, I think that's more of a shortcoming of the actual definition. While accurate, it just doesn't mean much until you see it. Most of the OO concepts sound really confusing but are really stupid simple.
However! You shouldn't be using a vector of objects, you should be using a generic collection (and almost certainly an ArrayList over a Vector, but that's for minor reasons that aren't too important right now):
Vector<PaperCurrency> wallet = new Vector<PaperCurrency>();
Why aren't you using generic collections? That is probably a question for whoever is teaching you.
So what's wrong with vectors? I use a vector pretty much any time a collection requires adding or removing elements at runtime. My last assignment required a multi-user set, and because users could be created and deleted at runtime I used a vector to store them. Would something else have been better?
ArrayLists do that too. In fact, ArrayLists and Vectors work almost exactly the same, except that ArrayLists aren't synchronised. This sounds like a deficiency, but actually isn't, because if you need concurrent access, you probably need to consider your synchronisation more carefully than just assuming you want it on the collection itself. So it encourages not thinking about concurrency when you should, and hurts performance when it's a non-issue.
Like I said, it's a minor reason that isn't important right now, and using a Vector over an ArrayList is very rarely going to be a problem.
But! If you're adding and deleting users at runtime, and you don't care about ordering, you should use a HashSet. If you do care about ordering, but not indexing, you should use a TreeSet. Firstly, it'll make removing elements from the middle of the collection much faster (well, in a HashSet there's no concept of "middle of the collection"), and secondly it'll make it clearer what the purpose of the collection is to other programmers.
0
SarksusATTACK AND DETHRONE GODRegistered Userregular
You don't need to know all that. Thing about programming, though, is if you ever want to know more about, well, pretty much anything, there's more to know. More important than what data structure to use (sometimes it's incredibly important, and sometimes it really makes as good as no difference) is don't ever get paralyzed by the thought you need to understand X to do Y. You don't necessarily need to understand Y to do Y. Hell, sometimes you can't understand Y until you've done Y.
It's just a bunch of tiny ideas piled on top of one another. Each one is pretty simple on its own, it's the interaction that is interesting.
CS - An orgy of ideas.
Run you pigeons, it's Robert Frost!
0
SarksusATTACK AND DETHRONE GODRegistered Userregular
That's kind of why I'm so interested in it, because computer science is an absurdly large and varied field that I could spend the rest of my life involving myself with.
In my entire time in college I never learned instanceof for Java. I just learned it at my new job, and it's the greatest thing ever.
Keep in mind that instanceof leads to decidedly unobject-oriented code. You should treat it (and casting) as the devil unless you can justify dealing with the devil for your particular problem.
This isn't always the case. The instanceof operator has its legitimate uses, particularly in defining the equals() method.
Polymorphism: Expressing an object as something else.
Basic example: Your Ford Taurus is a car.
Ford Taurus is your child class, car it the base class. The taurus is expressed as a car and can do car things, but it can do things only a taurus can do.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
In my entire time in college I never learned instanceof for Java. I just learned it at my new job, and it's the greatest thing ever.
Keep in mind that instanceof leads to decidedly unobject-oriented code. You should treat it (and casting) as the devil unless you can justify dealing with the devil for your particular problem.
This isn't always the case. The instanceof operator has its legitimate uses, particularly in defining the equals() method.
It's rare enough, with most of the common examples being standard cases like equals(), that I'd agree with Saeris there. Sometimes it's right, but challenge yourself to find a better solution first.
Polymorphism: Expressing an object as something else.
Basic example: Your Ford Taurus is a car.
Ford Taurus is your child class, car it the base class. The taurus is expressed as a car and can do car things, but it can do things only a taurus can do.
Polymorphism: Many shapes. Different things, behaving differently, that you can put in the same category, that have the same intents but different ways of achieving it. The value comes when you have many different types of cars, say a Ford Taurus and a DeLorean. Open the doors of a Ford Taurus, they open sideways: on a DeLorean, they open up. But you don't need to know what sort of car it is, you just open its doors.
However! You shouldn't be using a vector of objects, you should be using a generic collection (and almost certainly an ArrayList over a Vector, but that's for minor reasons that aren't too important right now):
Vector<PaperCurrency> wallet = new Vector<PaperCurrency>();
Why aren't you using generic collections? That is probably a question for whoever is teaching you.
So what's wrong with vectors? I use a vector pretty much any time a collection requires adding or removing elements at runtime. My last assignment required a multi-user set, and because users could be created and deleted at runtime I used a vector to store them. Would something else have been better?
ArrayLists do that too. In fact, ArrayLists and Vectors work almost exactly the same, except that ArrayLists aren't synchronised. This sounds like a deficiency, but actually isn't, because if you need concurrent access, you probably need to consider your synchronisation more carefully than just assuming you want it on the collection itself. So it encourages not thinking about concurrency when you should, and hurts performance when it's a non-issue.
Like I said, it's a minor reason that isn't important right now, and using a Vector over an ArrayList is very rarely going to be a problem.
But! If you're adding and deleting users at runtime, and you don't care about ordering, you should use a HashSet. If you do care about ordering, but not indexing, you should use a TreeSet. Firstly, it'll make removing elements from the middle of the collection much faster (well, in a HashSet there's no concept of "middle of the collection"), and secondly it'll make it clearer what the purpose of the collection is to other programmers.
So would I be safe replacing Vectors with ArrayLists any time, or is there an application where Vectors are better?
I haven't done any multithreaded programming yet. We've looked at it briefly in Operating Systems, and I was going to study Parallel Computing next but my uni's just discontinued it (see also: Multimedia Programming, Compiler Construction, and Advanced Web Technologies, which is about half of my final year gone), so I've never had to worry about which collections like concurrent access.
HashSet looks pretty perfect for a list of Users. I first used HashMap, with <username,User> pairs, then realised how stupid that was when username was filled with User.getName() anyway. Whenever I do something stupid, I run away to the familiar (Vector) without trying anything else different.
Under the hood they have different implementations, typically tuned for different access patterns.
So unless you have a lot of data and real problems to solve, you can "ignore" that. As in, don't worry about it too much while learning.
But you should be learning data structures such as linked lists and arrays and so on, and then you will know how and why they act like they do, and then you can understand how language libraries do what they do.
So would I be safe replacing Vectors with ArrayLists any time, or is there an application where Vectors are better?
They're basically the same thing. If you want the synchronised behaviour of Vectors, then use Vectors. It's not worth going back and changing it, to be honest. It was a really minor point. But it got us talking about data structures, so that's all good
HashSet looks pretty perfect for a list of Users. I first used HashMap, with <username,User> pairs, then realised how stupid that was when username was filled with User.getName() anyway. Whenever I do something stupid, I run away to the familiar (Vector) without trying anything else different.
What if you want to get a user, but you don't have the full User object, just their name? That's when you want hashmaps. Turns out, you'll probably want hashmaps all the time when making real programs.
So would I be safe replacing Vectors with ArrayLists any time, or is there an application where Vectors are better?
They're basically the same thing. If you want the synchronised behaviour of Vectors, then use Vectors. It's not worth going back and changing it, to be honest. It was a really minor point. But it got us talking about data structures, so that's all good
HashSet looks pretty perfect for a list of Users. I first used HashMap, with <username,User> pairs, then realised how stupid that was when username was filled with User.getName() anyway. Whenever I do something stupid, I run away to the familiar (Vector) without trying anything else different.
What if you want to get a user, but you don't have the full User object, just their name? That's when you want hashmaps. Turns out, you'll probably want hashmaps all the time when making real programs.
For that I made a getUser(String name) method that checked User.getName(). While I'm sure that this is slower than a HashMap's version, it seemed to me that filling a HashMap with <User.getName(), User>, and updating both the User and the HashMap entry any time someone changed their username (which was a requirement) seemed redundant, like a database where someone's name is stored in two places and you live in fear of the day they get out of synch. So I pulled the name out, panicked, and chucked them in a Vector.
In retrospect, it seems like a HashSet would have made the "No two users can have the same name" requirement much easier. Woops.
Posts
Be very familiar with geometry problems. Intersections, points inside polygons, etc.
Also, being on a team in these kinda sucks, in my experience. It is hard to balance feelings and contest performance. Are you good friends with the others?
One of them yes, but he's pretty subservient to me when it comes to CS. He's actually really good, but he regards me as strictly better, so I guess that's good. The third guy I don't believe either of us know, so we should be able to stick a hierarchy onto it.
e: Are you allowed to bring a cheat sheet? If not you could probably email yourself a word document that has the things Infidel mentioned.
We're allowed to bring no electronics, and as much paper as we want.
So we're bringing about a ream or so of notes about commonly used tasks and stuff so we can reduce the amount of peripheral thinking we have to do, and work on the task at hand instead of "let's remember how to parse an input string from standard input the way they want it"
We had to do ours with no aids whatsoever.
But yeah, make sure you have common geometry problems covered one way or another. Over half of them relied on them in the few contests I've done.
Based on the problem sets from previous years, my experiences in programming CORA (my XBL Indie Game that's on the backburner) has given me an incredible advantage when it comes to spatial reasoning in 2 dimensions. That's basically all I did for like 80-100+ hours of programming that thing.
A lot of stuff like that you'll run into.
One of the problems from two years ago was like that, except you had to start at the origin and count directions and distances clockwise around. The trick was how you know which direction was clockwise, but it wasn't too difficult to suss out.
Last year there was a problem requiring you to make an algorithm that would generate the links between pages of a map, based on a big map made of a grid of smaller maps, and you would output basically which grid element the given side of your grid element would link to.
https://docs.djangoproject.com/en/dev/howto/initial-data/#providing-initial-sql-data
Proper type safety isn't about checking before you cast: it's making sure you don't have to.
Well shit, there you go. That's just what you need! :P
Like if I want to simulate a button click on winforms I do the function btn_click(theButton, new EventArgs());
So, SandDock can let me know when a view changes DockState to Float, but I can't directly call the "Send to a new window" method because it involves closing the view and cleaning up after itself, and SandDock won't let you modify the view when it's in the middle of a DockChange (which the float and all associated event handlers count as). So what I really need is that delayed way to call the send method that won't block in the DockStateChanged method handler.
Le joy
Keep in mind that instanceof leads to decidedly unobject-oriented code. You should treat it (and casting) as the devil unless you can justify dealing with the devil for your particular problem.
Get a good nights sleep before hand. Measure twice, cut once (design the program before writing it out), if they allow books, bring one on common datastructures. Version control is your friend.
That makes sense. In my case I'm working with a WYSIWYG editor for work, so instanceof has helped me display a lot of different things correctly to the screen.
Sorry, I didn't mention the fact that there are three other enumerations (MiscCards, Photos, Credit Cards) that are being put into the wallet. That's what I meant. If it had only been one enumeration it would have been a lot simpler. I would have just made the vector of the type PaperCurrency.
So true.
Be very familiar with your language's implementation of common data structures - lists, hash maps, sets, etc.
In 5 hours, try not to reinvent the wheel too much!
Good luck, Rend dude.
Yeaah. And the polymorphism section is the next one. We haven't done polymorphism and inheritance yet. I'm about to start reading the notes/text on that, actually.
Your base class would be "cards" or something. They can all perform a type of payment system (currency) and are worth something, they're values built into the polymorphic objects, they're not objects themselves.
If I were designing that I'd probably have all the objects inherit from a card type, and be store-able in a wallet type, and have some function that allows me to perform a transaction in terms of currency. PaperCurrency would just be a form of "card" in this case... though card would probably be a silly name for it in general.
So what's wrong with vectors? I use a vector pretty much any time a collection requires adding or removing elements at runtime. My last assignment required a multi-user set, and because users could be created and deleted at runtime I used a vector to store them. Would something else have been better?
Like I said, it's a minor reason that isn't important right now, and using a Vector over an ArrayList is very rarely going to be a problem.
But! If you're adding and deleting users at runtime, and you don't care about ordering, you should use a HashSet. If you do care about ordering, but not indexing, you should use a TreeSet. Firstly, it'll make removing elements from the middle of the collection much faster (well, in a HashSet there's no concept of "middle of the collection"), and secondly it'll make it clearer what the purpose of the collection is to other programmers.
It's just a bunch of tiny ideas piled on top of one another. Each one is pretty simple on its own, it's the interaction that is interesting.
CS - An orgy of ideas.
This isn't always the case. The instanceof operator has its legitimate uses, particularly in defining the equals() method.
Basic example: Your Ford Taurus is a car.
Ford Taurus is your child class, car it the base class. The taurus is expressed as a car and can do car things, but it can do things only a taurus can do.
Polymorphism: Many shapes. Different things, behaving differently, that you can put in the same category, that have the same intents but different ways of achieving it. The value comes when you have many different types of cars, say a Ford Taurus and a DeLorean. Open the doors of a Ford Taurus, they open sideways: on a DeLorean, they open up. But you don't need to know what sort of car it is, you just open its doors.
So would I be safe replacing Vectors with ArrayLists any time, or is there an application where Vectors are better?
I haven't done any multithreaded programming yet. We've looked at it briefly in Operating Systems, and I was going to study Parallel Computing next but my uni's just discontinued it (see also: Multimedia Programming, Compiler Construction, and Advanced Web Technologies, which is about half of my final year gone), so I've never had to worry about which collections like concurrent access.
HashSet looks pretty perfect for a list of Users. I first used HashMap, with <username,User> pairs, then realised how stupid that was when username was filled with User.getName() anyway. Whenever I do something stupid, I run away to the familiar (Vector) without trying anything else different.
Under the hood they have different implementations, typically tuned for different access patterns.
So unless you have a lot of data and real problems to solve, you can "ignore" that. As in, don't worry about it too much while learning.
But you should be learning data structures such as linked lists and arrays and so on, and then you will know how and why they act like they do, and then you can understand how language libraries do what they do.
What if you want to get a user, but you don't have the full User object, just their name? That's when you want hashmaps. Turns out, you'll probably want hashmaps all the time when making real programs.
For that I made a getUser(String name) method that checked User.getName(). While I'm sure that this is slower than a HashMap's version, it seemed to me that filling a HashMap with <User.getName(), User>, and updating both the User and the HashMap entry any time someone changed their username (which was a requirement) seemed redundant, like a database where someone's name is stored in two places and you live in fear of the day they get out of synch. So I pulled the name out, panicked, and chucked them in a Vector.
In retrospect, it seems like a HashSet would have made the "No two users can have the same name" requirement much easier. Woops.