avoiding new

Code:

---

class myclass
{
  int a;
};

void f()
{
// What's the difference between both object creation.
// Which one is better/safer?
    myclass* obj1 = new myclass;
    myclass obj2;
}

---

This stuff should be covered by your C++ book, not answered in a forum.

Avoiding new is "better" in the sense that it's automatically deleted when you exit the function. This is also the drawback. Consider the following:

Code:

---

class myclass
{
public:
  myclass(int n) : a(n) {};
    ~myclass() { a = -1 };
  int a;
};

myclass *f(int x)
{
    myclass obj2(x);

    return &obj2;
}

int main()
{
    myclass *obj = f(12)
    std::cout << "obj->a = " << obj->a << std::endl;
}

---

Since you are returning the obj2 that is local to function f, it will then be destroyed, and the value of a is now -1 [assuming nothing has overwritten the location, since it's now freely available to other functions].

In this case, you _NEED_ to use new or the program will not work correctly.

--
Mats

Code:

---


// Can I not use static in that case?

myclass f()
{
    static myclass o;
    return o;
}

---

Quote:

---

Originally Posted by manav

Code:

---


// Can I not use static in that case?

myclass f()
{
    static myclass o;
    return o;
}

---

---

Sure, you can. Note however the above code is actually safe anyways, as it's creating a copy of the object o. So even without static, it would create a copy of o that is external to f. If you have myclass *f() and return &o then it would not create a copy.

But then you essentially have a global variable [but only accessible by calling f()], which may not be what you wanted.

--
Mats

Code:

---


// Then I think this is better?

myclass& f()
{
    static myclass o;
    return o;
}

---

Quote:

---

Originally Posted by manav

Code:

---


// Then I think this is better?

myclass& f()
{
    static myclass o;
    return o;
}

---

---

Better than what?

What I was trying to point out was that there are situations where you can't avoid using new. There are MANY cases where you can. In this case, you are still using ONE instance of myclass, so every call to f() will use the same myclass instance - it is the same as having one global variable, the only (slight) difference is that it's not visible, you have to call f() to get to it.

An example of where you [most likely] can't avoid using new is if you use linked lists or binary trees. This is just one of many examples where you may want to "create an object and let it live past the call of this function and not have just one single instance".

If "new" wasn't necessary in the C++ language, then it wouldn't be there. You can sometimes avoid using new, but it's almost impossible to write a LARGE program without using it at least sometimes.

--
Mats

Thanks!
I just got carried away with the idea: "I will avoid new in all my code."
Now I suspect, if this is possible? :(

Quote:

---

Originally Posted by manav

Thanks!
I just got carried away with the idea: "I will avoid new in all my code."
Now I suspect this is not possible :(

---

It very much depends on what your program does - but I'd say that if your program is sufficiently complex, it's unlikely to be "right" to do that.

Tying in with another recent thread, you also need to watch out for stack overflows. They tend to crash your program in a much nastier way [and much sooner] than running out of free-store [where "new" gets it's memory from]. If you create all your storage as local variables in functions, then you will use up more stack-space than you do if you use new to create your objects.

--
Mats

Don't be afraid of new. In C++, there are many ways to make resource acquisition and destruction automatic. Consider using smart pointers. They'll delete the memory automatically when it's no longer used, so you don't have to worry about it.
Also avoid static variables since they'll just turn up the same as global variables, mostly. And from what I know, that space isn't unlimited. Or it may be. But in any case, it usually defies implementation rules to use it time and time again. Static was designed so the value of a variable would be the same no matter how many times a function was called.

>> Which one is better/safer?
The local object is better/safer than the dynamically allocated one.

There will be times where you will need dynamic memory, and in those cases you can use new (preferably wrapped in a smart pointer of some kind).

However, when both will work equally well, prefer the local object.

>> This stuff should be covered by your C++ book, not answered in a forum.
I don't believe many C++ books cover this question very well, if they do at all.

Quote:

---

Originally Posted by manav

Thanks!
I just got carried away with the idea: "I will avoid new in all my code."
Now I suspect, if this is possible? :(

---

matsp is pointing out that dynamic memory allocation is unavoidable, even in simple cases.

However, avoiding new doesn't necessarily mean that you avoid dynamic memory. It could be taken to mean that you should avoid the key word in favor of using containers that manage memory for you. There are many implementations out there of virtually every useful container, so there is little need to write your own. Similarly there are various smart pointer types that can be used to ensure that a single dynamically allocated object will be destroyed when it is no longer needed so there is no need for you to manually delete the object. With these tools you will rarely see calls to new and especially delete in your code.

Simple: Don't use 'new' if you don't need to.

Thank you all for those comments!
I found many ways (in those comments) to avoid dealing with memory management (hence avoiding new also).

Quote:

---

Originally Posted by iMalc

Simple: Don't use 'new' if you don't need to.

---

As usual, iMalc summarizes the overall subject very well - I tend to ramble and explain too many things from time to time... ;)

I completely agree with the above statement, as well as Daved's comments.

--
Mats