Printable View
In the main I call a function as:
I know that I should always call delete when using new. But, in this scenario the x object would be destroyed automatically when the function gets out of scope. So, what if I do not call delete in the function? Does it hurt other than being a bad practice?Code:void test()
{
double* x = new double[10];
//----fill the array and print out stuff
delete[] x;
}
The pointer value goes out of scope -- the memory is still allocated and you've lost all chance of deallocating it, since the pointer to that block has disappeared.Quote:
Originally Posted by Learned
You have a memory leak.
Yes it does hurt. You are allocating memory, never dealloacting it, and you're using up your memory this way. Call that function in a loop without calling delete. Make the loop go from 1 to a million or 10 million. Watch your program crash.Quote:
So, what if I do not call delete in the function? Does it hurt other than being a bad practice?
Regards,
Paul McKenzie
The reason things are a bad practice is because they will eventually hurt.Quote:
Originally Posted by Learned
Get in the practice of always cleaning up allocated memory. In fact, get in the practice of always freeing up resources (deleting memory, closing handles, etc.).
The way to automate disposal is to make a Buffer object as Bjarne S. does in The C++ Programming Language.Quote:
Originally Posted by Learned
Rather than post copyrighted material from the book, here's one I threw together just because I had code with lots of temporary buffers for parsing strings. By using Buffs I could just "return false" from my function and all the temporary buffers would be cleaned up automatically:
If you really want to spiff it up for a reusable class then you could add some Move Semantics etc.. but it's fine as is for quick and dirty temporary buffers.Code:template<class T>struct Buff {
size_t size;
T* t;
Buff() : size(0),t(0) {}
Buff(size_t n) : size(0),t(0)
{
t = new T[n];
if(t)
size = n;
}
bool operator!()
{
return !t;
}
T& operator[](size_t i)
{
if(i >= 0 && i < size)
return t[i];
throw "index out of range";
}
const T& operator[](size_t i) const
{
if(i >= 0 && i < size)
return t[i];
throw "index out of range";
}
~Buff()
{
size = 0;
if(t)
delete [] t;
t = 0;
}
};
Why bother going to all that trouble? Just do
Code:void test()
{
std::vector<double> x(10);
}
Hopefully only as a demo program, as std::vector<T> does everything the code you posted does, and more.Quote:
Originally Posted by MilesAhead
Regards,
Paul McKenzie
If you don't require the facilities of vector and the array is a fixed size at compile time then it's just
If your compiler supports TR1 then you can use thisCode:void test()
{
double x[10];
//----fill the array and print out stuff
}
Code:void test()
{
std::tr1::array<double, 10> x;
//----fill the array and print out stuff
}
So, what holds the memory. Since function is out of scope, should the member not behave as another deleted file. What is mean is, when I delete a file on my computer, only the link is broken but it stays on the disk until the memory location it is occupying is overwritten by some other stuff.Quote:
Originally Posted by Paul McKenzie
The memory is still owned by your program and won't get freed till your program terminates.Quote:
Originally Posted by Learned
It's not really analogous to deleting a file. You requested memory with new. The OS gave it to you and you stored the address in a pointer. The pointer went out of scope. Nothing happened to the memory that was allocated. The pointer variable, which for all intents and purposes is unrelated to the allocated memory, went out of scope, so you no longer have a way to get the memory. It's all still there and owned by your program.
Perhaps an analogy. You are out walking a dog, holding its leash. Suddenly, the leash gets destroyed. The dog is just fine, but now you have no control over it, and it runs off never to be seen again. You need to keep that leash secure until the dog has been put away properly.
Ooohhh, this is fun. How about you meet a girl at a bar and she gives you her phone number. You throw away the number. She's still out there, but the only way you had to get in touch with her is gone.Quote:
Originally Posted by Lindley
Wait. I want to play too.Quote:
Originally Posted by GCDEF
Say you allocate memory, and you're given a handle to it (e.g. a pointer). Next, you throw away the handle. The memory is still there, but you can't access it.
:D
I don't want it to do more. I want it to do less. Basically I just want automatic disposal of my temp buffers. <vector> was around when Bjarne S. wrote The C++ Programming Language 3rd ed. and used something similar. Send him a telegram how stupid he is.Quote:
Originally Posted by Paul McKenzie
Also the standard containers don't play well with move semantics. If you do a full blown autoarray_ptr(as opposed to auto_ptr) you would add that functionality in. In my case I didn't need it. Seems like every time I post on this board I get chirping about Use The xyz Container. Like, no kidding. But the language allows you to create your own template classes for when you want to do your own thinking instead of just painting on a canvas with the numbers filled in.
No need to, as even he has written that using standard containers should be done above coding your own container classes.Quote:
Originally Posted by MilesAhead
It isn't only CodeGuru that would have stated just to use std::vector or std::array -- any C++ programming board would have stated the same thing, so this isn't about just CodeGuru or its members.Quote:
Seems like every time I post on this board I get chirping about Use The xyz Container. Like, no kidding. But the language allows you to create your own template classes for when you want to do your own thinking instead of just painting on a canvas with the numbers filled in.
Many that post here work in professional environments / teams where you just can't "do your own thing" when standard components exist, else your code gets rejected when code review time comes around. The std::vector/std::array is known by most, if not all competent C++ programmers, so there is no need to study a home-made class that may have anomalies or bugs (which your class does have if used in ways you didn't anticipate, i.e. copying and assigning).
Sure it's easy to fix, but the OP could have taken your code without this being noted, and used it in ways similar to this and not know that they now have introduced a bug in their code. On a programming team, this either has to be fixed by someone and/or documented as to what you can/can't do. So the no-fault way of not having to do this (documenting, looking for bugs, etc.) is to use the standard library. I remember having to fix a home-made linked list class that leaked memory like a sieve -- that memory leak almost cost the company a high-profile/paying customer. After that, no programmer was to use "home-made" containers, unless they have a compelling reason to do so.Code:int main()
{
Buff<char> b1(10);
Buff<char> b2 = b1;
}
Secondly, it's not the usage of templates that is the issue -- it's the usage of templates to create classes that basically already exist. I create template classes all the time, the difference is that I'm not creating simplified or seemingly versions of vector, linked list, map, array, etc. classes.
Edit: Your class also does bounds-checking for operator[]. The standard implementation of vector::operator[] does no bounds checking in optimized builds (albeit for debug VC++ configurations, the check is there). So your class could have a performance hit that doesn't exist for vector. So in this sense, your class is doing more than what vector would do (the vector::at() function is where you would always get the bounds check).
Regards,
Paul McKenzie
I think the intent was to suggest using the STL as a best practices sort of recommendation.Quote:
Originally Posted by MilesAhead
It's too bad you felt as if you were getting lectured at.
The folks here doing the answering sometimes have a difficult time to distinguish posters that intentionally do not want to use STL from those that have never heard of it.