using new/delete when building classes

Is there a good and bad about this design?

I'd like to look deeper into a good design of a class, mainly that would assumably be instantiated multiple times and used on the heap where bitmaps and other data would be included for objects that might be a couple hundred or many hundreds of bytes at a time, or mb's.

Code:

---

class SomeObject
{

public:

    SomeObject()
    {
        a = 0;
        b = 0;
        x = 0;
        y = 0;
    };

    void SomeObject(int it)
    {
        InitObject(it);
    };

    ~SomeObject()
    {
        a = 0;
        delete b;
        delete  x;
        delete[]  y;
    };

    void InitObject(int it)
    {
        a = it;
        b = new int(it);
        x = new SomeThing(it);
        y = 0;
        ChangeTheItems(it);
    };

    void ChangeTheItems(int it)
    {
        if(y != NULL)
        delete[] y;

        y = new SomeItem[it];
    };

    SomeItem* UseItems(void)
    {
        return y;
    };

    //other functions here...

private:

    int a;
    int* b;
    SomeThing* x;
    SomeItem* y;

}

---

What happens when this class is instantiated with these examples:

Code:

---

[scope]
SomeObject one;
SomeObject two(3);
SomeObject* buckle = new SomeObject(2);
SomeObject* shoes = new SomeObject[100];

// blah lbah

delete buckle;
delete[] shoes;
[/scope]

---

Any offerings about this?

the first 2 create a new object on the stack. the 3rd on creates pointer (on stack) to a new object on the heap. the forth one creates a pointer to the first element in the array. the forth is much fast when than instantiating 100 objects individually.

ok yes, I understand that. And the first one is on the stack, but isn't part of it on the heap? ;)

Code:

---

void SomeObject(int it)
{
    InitObject(it);
};

---

Constructors/destructors do not have return types.

Quote:

---

Originally Posted by zcot

ok yes, I understand that. And the first one is on the stack, but isn't part of it on the heap?

---

The SomeObject object (its member variables) is created on the stack. The memory allocated for use by its SomeThing and SomeItem members however comes from the heap.

Quote:

---

Originally Posted by hk_mp5kpdw

Code:

---

void SomeObject(int it)
{
    InitObject(it);
};

---

Constructors/destructors do not have return types.

---

Yes, thanks for pointing out that oversight. Obviously my cutNpaste when whipping that up was a bit out of hand. ;)

So....

Quote:

---

Is there a good and bad about this design?

---

Is anybody looking at the function code in relation to memory management?

Is anybody looking at the design?

> Any offerings about this?
Yes, calling it "someobject" is too vague.

It might be OK for your footwear storage system, but it's no good for traffic management.

In other words, be more specific.

I was a bit vague on purpose, as far as the exactness of the class, and that's because I'm focusing NOT on the specific class but the design of classes, in relation to the design that I've posted. It's not intended to be a specific class, and I was thinking to make that obvious. And specifically because of all that, I don't think it was vague at all in mentioning:

"good design" and the relation of "memory management" in this class. I'm just wanting some feedback about that part from some people who have the knowledge and/or opinion about it.. -that's why I posted it up.

If I were to be VERY specific here then I might be posting like 30 files with upwards of 14 classes or something, where doubtfully many people would even give a thought to really digging into a complex structure like that. I wrote up this pseudo class to get the idea across, and it wouldn't appear to be any functional class that I could see for anything, but there is no fat there as far the ideas that I'm trying to ask about, and that's why I did it that way so the focus could be about memory usage.

Perhaps I should've been more specific, so let me try to clarify some things. I'm interested in some feedback about this:

1. heap instantiated classes that have local member variables as well as local member pointers to objects instantiated from the heap. Is this an unpreferrable situation in cases? Maybe this is a common occurance, but I don't know, so I ask about feedback.

2. In relation to the member function Init() as well as the destructor, is this form of memory management good, bad, ugly, incompetent, viable, or any of the above? Can you offer anything here?

You have to ignore the missing pieces such as other usable functions, and relevant and viable parameter usage for the constructor or initiation functions, and what SomeItem and SomeThing objects are and do.

Well good design pays only light attention to issues of performance and memory usage, at least in the initial stages. High level design is a very abstract activity.

Like for example, in designing a library application, you would want to make sure that you got all data items and relationships sorted out before even creating any source code.
For example, you would perhaps have something along the lines of
- a borrower can borrow up to 10 books at a time.

This makes NO statement about how books should be stored on a per-borrower basis. A vector or a list are equally plausable data structures.

Now as you work on the design and add say
- the system will be capable of determining whether a borrower has borrowed a particular book.

This may (or may not) sway the implementation choice in one way or another.

Nor should it matter one way or the other - well designed classes effectively hide the implementation detail from the outside world.

It's the detailed design which maps your abstract design (borrower can borrow up to 10 books) into either
std::vector<book> borrowed_books;
or
std::list<book> borrowed_books;

Until you've actually written the code and had chance to test it with real-world data, up-front predictions of how much memory it takes and how much CPU time it takes are usually wildly inaccurate.


Old saying
"It is easier to make a working program efficient than it is to make an efficient program work."

thanks...

oh geez yea.. tbh I don't even know what I was thinking asking that.