Classes, Subclasses & Dynamic Memory

This is a discussion on Classes, Subclasses & Dynamic Memory within the C++ Programming forums, part of the General Programming Boards category; Well, maybe the title to this post is a little intimidating, but I don't think the question will be all ...

  1. #1
    Registered User
    Join Date
    Jan 2006
    Posts
    9

    Classes, Subclasses & Dynamic Memory

    Well, maybe the title to this post is a little intimidating, but I don't think the question will be all that difficult to someone who has thought this through before.

    In english: I have a class that holds two arrays (_alts and _profile), the length to be determined at runtime. It can be created empty and populated later, or created with the data. Here is some of the code relating to the class:

    Code:
    class Profile
    {
    public:
        int _numalts;
        double* _alts;
        double* _profile;
    public:
        Profile( );
        Profile( int numalts, double* alts, double* profile );
        ~Profile( );
    };
    So, no problems so far. Calling the constructor with the number of alts allocates that much memory.

    However, I have another class that contains three instances of this class. Sometimes when the code runs, it will populate all three of the instances with data, sometimes 2 or 1... you get the picture.

    So, right now my parent class that contains this one looks like this:
    Code:
    class MultiProfile
    {
    private:
        bool _profile1_isloaded;
        bool _profile2_isloaded;
        bool _profile3_isloaded;
        Profile* _profile1;
        Profile* _profile2;
        Profile* _profile3;
    
    public:
        MultiProfile( );
        ~MultiProfile( );
        bool CreateProfile( int profilenumber, int numalts, double* alts, double* profile );
    };
    At this point, I'm creating 3 pointers to the Profile class and then calling the contructor for the profile in CreateProfile. This way, if I don't call CreateProfile for one of them, it isn't a problem.

    This makes sense to me, but I was wondering if there was a different/better way of doing this. Should my profiles be pointers or can they be actual instances of the class and not pointers. If they aren't pointers, I have to give them the constructor right away, when I instantiate the class, don't I?

    If you need more info, ask and I'll post it. I can provide my implementation code, but I figured you wouldn't need it to give some insight into my question.

    Thanks a lot for your help. I realize the question is more along the lines of C++ philosophy then pragmatism (the code I have already works), but inquiring minds need to know as they say.

  2. #2
    Registered User
    Join Date
    Nov 2005
    Posts
    52
    From a C++ philosophy standpoint, why are you using 1) Dynamically allocated arrays vs. std::vector, and 2) Dual (presumably related, since you don't offer a count for both arrays) arrays rather than a std::pair, or a class that wraps them together for insertion into the aforementioned std::vector?

  3. #3
    Registered User Kurisu's Avatar
    Join Date
    Feb 2006
    Posts
    62

    Exclamation

    In regards to vectors vs. dynamically allocated arrays I think arrays can be more efficient + less memory consumed than vectors, which may contain stuff you don't want to use anyways.. Plus you can memset 50 entries in an array to zero much quicker than going through each vector entry one by one plus other stuff. Though don't quote me on this stuff . (If you want simplicity vectors would be a great choice and any extra overhead I can't imagine would hurt your program. Not like your building a game or something intensive..)
    ---------------------------------------------
    In regards to the initial post:

    If your profiles are not pointers then yes a default constructor will be called when you create a multiprofile class, which would waste memory if you only decided to use 1 or 2 of the profiles like you mentioned..

    If the max # of profiles is 3 then sure I believe your code is perfectly fine, but if there can be many profiles or perhaps you may want many down the road.. In order to make you class more ambigious and thus reusable for many different applications you might want to use a linked list structure to store profiles instead of later typing:
    Code:
    Profile* _profile1;
    Profile* _profile2;
    Profile* _profile3;
    Profile* _profile4;
    Profile* _profile5;
    Profile* _profile6;
    Obviously this could get messy while:
    Code:
    struct profileEntry
    {
    Profile *profile; // This could be a pointer or just a regular variable if you want.
    profileEntry *nextEntry;
    // add more stuff if yah want like:
    // bool isLoaded;
    // int profileID;
    // string profileName; etc;
    }
    
    class MultiProfile
    {
    private:
         profileEntry *profiles;
    
    public:
        MultiProfile( );
        ~MultiProfile( );
        bool CreateProfile( int profilenumber, int numalts, double* alts, double* profile );
        bool isLoaded(int profileNum);
    };
    
    bool MultiProfile::isLoaded(int profileNum)
    {
       profileEntry *iterator = profiles;
    
       for(int i=0; i < profileNum; i++)
       {
          if(iterator == NULL) // Profile doesn't exist.
            return false;
          
          iterator = iterator->nextEntry; // Move to next entry in our profile list.
       }
      
       return true;  // Profile exists.
    }
    I'm not sure if your familiar with linked lists, but this way would make your code more reusable for various scenarios. There is no profile limit just like the vector scenario, but is customized to your personal needs. You can store various information to accompany each profile in the profileEntry nodes if you want. And last it greatly reduces your variable list and clean-up problems in your destructor as you can iterate through each entry in the list rather than individually cleaning up profile_1; profile_2; etc.

    ex:
    Code:
    int arrayList[50];
    is better than
    Code:
    int arrayItem1;
    int arrayItem2;
    int arrayItem3;
    int arrayItem4;
    ...
    int arrayItem50;
    Just my opinions, but otherwise your code is fine as long as you are careful with passing your pointers double* alts, double* profile so you don't get memory leaks or more likely fatal program crashes in your profile deconstructor, which really chapped my ass until I figured what the problem was.

    Good luck.
    Last edited by Kurisu; 02-06-2006 at 12:04 AM.

  4. #4
    semi-colon generator ChaosEngine's Avatar
    Join Date
    Sep 2005
    Location
    Chch, NZ
    Posts
    597
    Quote Originally Posted by Kurisu
    In regards to vectors vs. dynamically allocated arrays I think arrays can be more efficient + less memory consumed than vectors, which may contain stuff you don't want to use anyways..
    questionable in the extreme, but I'll let it slide for the moment

    Quote Originally Posted by Kurisu
    Plus you can memset 50 entries in an array to zero much quicker than going through each vector entry one by one plus other stuff.
    hmmmm... so
    Code:
    std::vector<int> vec;
    vec.assign(50, 0);
    is much slower then
    Code:
    int *arr = new arr[50];
    memset(arr, 0, 50);
    a bottle neck in only the most trivial of programs
    "I saw a sign that said 'Drink Canada Dry', so I started"
    -- Brendan Behan

    Free Compiler: Visual C++ 2005 Express
    If you program in C++, you need Boost. You should also know how to use the Standard Library (STL). Want to make games? After reading this, I don't like WxWidgets anymore. Want to add some scripting to your App?

  5. #5
    Registered User Kurisu's Avatar
    Join Date
    Feb 2006
    Posts
    62
    Hehe thats why I said don't quote me as I am just guessing I didn't mean quicker in terms of the programmer having to write more code, but rather the CPU since I believe arrays are stored sequentially in memory while vectors are a class with variables and member functions aren't they? I just figured for an array the computer would simply zero all memory for the size of an array: ie. max index * sizeof(double). I'm not sure how a vector is technically populated by the computer maybe it is similar..?./? requires iterating through a link list and setting each value? vector entries stored sequentially in memory or all over the place? quicker.. or slower.. i dunno.

    But yes you are correct for 90.0% of applications I would imagine using vectors are more than sufficient.
    Last edited by Kurisu; 02-06-2006 at 04:54 PM.

  6. #6
    semi-colon generator ChaosEngine's Avatar
    Join Date
    Sep 2005
    Location
    Chch, NZ
    Posts
    597
    Quote Originally Posted by Kurisu
    Hehe thats why I said don't quote me as I am just guessing I didn't mean quicker in terms of the programmer having to write more code, but rather the CPU since I believe arrays are stored sequentially in memory while vectors are a class with variables and member functions aren't they?
    depends on the implementation, but in general, vectors are simply a wrapper around a dynamic array.
    "I saw a sign that said 'Drink Canada Dry', so I started"
    -- Brendan Behan

    Free Compiler: Visual C++ 2005 Express
    If you program in C++, you need Boost. You should also know how to use the Standard Library (STL). Want to make games? After reading this, I don't like WxWidgets anymore. Want to add some scripting to your App?

  7. #7
    Registered User
    Join Date
    Jan 2005
    Posts
    7,338
    The data in a vector must be stored sequentially in memory (if the implementation conforms to the standard). Zeroing out all of the elements may be as simple as a call to memset, although because a vector can hold objects as well as POD types, memset won't always work, so it would be up to the implementation as to whether they could use memset in cases where it would be better. But again, these issues usually pale in comparison to the safety and flexibility provided by the vector.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Dynamic memory allocation...
    By dicorr in forum C Programming
    Replies: 1
    Last Post: 06-24-2006, 03:59 AM
  2. Inheritance and Dynamic Memory Program Problem
    By goron350 in forum C++ Programming
    Replies: 1
    Last Post: 07-02-2005, 02:38 PM
  3. Another Dynamic Memory Question
    By SirCrono6 in forum C++ Programming
    Replies: 6
    Last Post: 03-02-2005, 11:10 AM
  4. delete dynamic memory
    By VanJay011379 in forum C++ Programming
    Replies: 1
    Last Post: 07-18-2002, 12:44 PM
  5. Is it necessary to write a specific memory manager ?
    By Morglum in forum Game Programming
    Replies: 18
    Last Post: 07-01-2002, 01:41 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21