Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.c++.moderated    |    Moderated discussion of C++ superhackery    |    33,346 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 32,467 of 33,346    |
|    Pete Becker to All    |
|    Re: Classes that manage containers    |
|    09 Jul 12 16:03:34    |
   
   From: pete@versatilecoding.com   
      
   On 2012-07-09 15:31:15 +0000, fmatthew5876 said:   
      
   > Lets say we have something like this:   
   > class A {   
   > public:   
   > //Stuff..   
   > private:   
   > SomeContainer _bcontainer;   
   > }   
   > We want A to contain the storage for a collection of B's and we want to   
   > allow the user to add/remove and do other operations to B through A.   
   > One option is to add class methods to A to manipulate B such as:   
   > void A::bcontainer_insert(int i, const T& t) { _bcontainer.insert(i, t); }   
   > This is simple and it also allows us to restrict the interface (for   
   > example only provide stack-like push/pop methods even though the   
   > underlying container is an array) to B but it can get unwieldy. In   
   > most cases the names of the methods all have to contain a prefix   
   > or suffix saying they deal with the b container. It gets even more   
   > messy if our A class manages multiple containers of different objects.   
   > Another choice is to just have a method that returns a   
   > reference to the B container.   
   > Container& A::get_b() { return _bcontainer; }   
   > Now all of the b container methods are scoped within the b   
   > container class which seems cleaner. If we want to restrict the   
   > interface we can do it easily using containment.   
   > class BContainer {   
   > public:   
   > //Restricted inline interface   
   > private:   
   > Container _base;   
   > };   
   > class A {   
   > public:   
   > BContainer& get_b() { return _bcontainer; }   
   > //Stuff..   
   > private:   
   > BContainer _bcontainer;   
   > }   
   > It is probably a good idea at this point to make sure   
   > copy constructors are disabled on BContainer so   
   > users can't accidentally do this:   
   > A a;   
   > BContainer bc = a.get_b();   
   > bc.insert(int i, something);   
   > What idiom do you all prefer to use in these situations?   
      
   The idiom I prefer is knowing what a class is supposed to do before writing   
   its interface. There's nothing in this post that says anything about the   
   reason that A exists, unless it's just a blob that holds a bunch of   
   containers, in which case it is    
   probably a design mistake, and definitely highly uninteresting.   
      
   --   
   Pete   
      
      
    [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
    [ comp.lang.c++.moderated. First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca