Create a second BST class to work with the secondary key

[theorangepotato]

You can use the string member function find() to get non unique keys:

if((food->getName()).find(target) < 60)
     return true;
return false;

If it does not find the target, it will return its largest possible value. However, we don't need to know exactly what it is, since the USDA definition caps the name at 60 characters, so if the position is past 59, we know it doesn't exist.

[theorangepotato]

I talked with Ms. Garbacea, and she said that we don't actually have to search with the unique key BST (we'll just use the hash table for that), however we do have to have it. So I think that will mostly be used for the inorder traversal.

The secondary key BST will need to be searchable, but I don't think we need the inorder. Not that you need to remove functionality from anything, but just so you are aware.

[brandon-a]

Got it, thanks. Just to confirm, we are still going along with creating two BSTs. One for the unique key and one for the secondary key.

It's just that we only need those certain functions on each?

[theorangepotato]

Yes, exactly.

[brandon-a]

I'm pretty sure we are supposed to only have one class for the BST and create two objects. I'm going to try to consolidate it into one class now.

[theorangepotato]

But then the member functions will have to be, like, twice as long. And since we're not even really sorting them by secondary key, that BST is kinda pointless for us, but we have to do it for the project. I feel like we should make two, but that is your section of the code, so you can have final say.

[brandon-a]

While the member functions are almost twice as long, I really think that it's not good to make a second class just for the sake of sorting by name, if it can be done in the same class.

I'm pretty sure we're supposed to have two BST objects, one sorted by ID and the other sorted by Name. I made the changes just recently, I was going to overload them, but they have the same parameters so I just changed the names of the functions.

[theorangepotato]

Perhaps you should have a private book that is set in the constructor that determines which kind of BST it should be. That way everyone else doesn't have to keep track of the member function names.

[brandon-a]

That's a good idea.

[theorangepotato]

But either way, I think the BST should be set in its organization upon declaration. Otherwise, one could conceivably use the wrong member function and mess up a BST pretty badly. Adding a Food* by key to a BST sorted by name, searching by name in a BST sorted by key, etc. I don't think it should be the caller's job to remember how its sorted.

[theorangepotato]

I just checked, and this doesn't seem to work yet?

[brandon-a]

I made a simple mistake, it should work now. I have not yet implemented the find function you suggested as I am limited by time at the moment. I will have more time on Sunday to improve and smooth out the code.

[theorangepotato]

Awesome, it's all good.