0

I'm working on a personal project which requires at some point to manage a list of drinks. I planned to manage them by their name and not an ID. hat I first thought is an unordered_set because I do not specifically need them to be sorted alphabetically. I also need to export/import such a list. I have a class: 

class DrinkList : public std::unordered_set<Drink>{

public:

void import();
void export();

};

Is it a good idea or should I create a class containing an unordered_set with functions to interact with it ?

If I should keep it the way it is, what should I do as constructor/deconstructor? It is a bit blurry to me :/

Thank you for your help!

DrCampy
  • 1
  • 1
  • *"And, unto you, this day, I tell you, Thou shall not inherit from an STL Container"* ...Prefer Composition over inheritance – WhiZTiM Sep 07 '16 at 13:13
  • 1
    also see here: http://stackoverflow.com/questions/2034916/is-it-okay-to-inherit-implementation-from-stl-containers-rather-than-delegate – Hayt Sep 07 '16 at 13:14
  • This could only make sense to me if you intended your `DrinksList` to be everything an `std::unordered_set` is. I suspect that is not really the case. I suspect `std::unordered_set` is more of an *implementation detail* and those are best hidden from outsiders. At the very least I would consider `private` inheritance, but most likely *composition* is the way to go (make `std::unordered_set` a *member*). Also **don't** do this if you intend to use `DrinksList` *polymorphically* because badstuff. – Galik Sep 07 '16 at 13:24
  • Thanks guys. I do not intend to use polymorphism with that class. I indeed do not need the user of that class (that is me but let's imagine) to know that it is an unordered set. I will use composition. I did not know that it was evil to inherit from STL containers but now, I know ;) – DrCampy Sep 07 '16 at 13:28

0 Answers0