|
Quote: Why should the compiler generate errors, when I don't explicitly use functions defined in those libraries ?
Because libShared does.
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
I know that if you allocate an object on the heap using 'new', it needs to be deleted.
But what if it's a function that returns a pointer to an object?
For example...
SomeClass *someClass = aFunction();
I'm assuming that inside of aFunction(), there is a 'new Someclass()' in there somewhere.
However... When I delete someClass on app exit, the app crashes. If I comment out the
delete, it exits ok. But won't there be a memory leak if someClass isn't deleted?
|
|
|
|
|
it's impossible to say.
is aFunction returning a pointer to a global, or to an object that is it managing somehow ?
|
|
|
|
|
Don't assume that a pointer you get has been created with new. Read the code, or documentation, to find out what your responsibilities are.
It might have been created with new, in which case you need to call delete when you are done with it. It might have been created with malloc (or one of its relatives), in which case you need to call free when you are done with it. It might point to a global or static piece of data, in which case you don't release it.
Never assume when it comes to memory management.
In this case, it seems likely you do not need to release the pointer, but the only way to be sure is to read up on how it is created and what your responsibilities are.
|
|
|
|
|
DanielSheets wrote: However... When I delete someClass on app exit, the app crashes.
At any point do you reassign or increment someClass such that it points to a different location? For example:
SomeClass *someClass = new SomeClass();
someClass++;
delete someClass;
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Try deleting the pointer immediately after you receive it. Maybe it's deletetd inbetween and not set to null (bad practice), in which case a second delete would lead to a crash.
Also check if the function is in a different dll, especially one loaded manually at runtime (i.e. not automatically at program start). In that case the dll could already be unloaded when you try to delete the pointer. Or the dll could be built in a different version of the compiler. If that is the case you may need to delete the pointer inside the dll.
On a more general note: Deleting a pointer on app exit doesn't make much sense, except if you need it for the whole lifetime of your application. Typically you should delete it as soon as you don't need it anymore.
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Freak30 wrote: Also check if the function is in a different dll, especially one loaded manually at runtime (i.e. not automatically at program start). In that case the dll could already be unloaded when you try to delete the pointer. Or the dll could be built in a different version of the compiler. If that is the case you may need to delete the pointer inside the dll.
Actually, if the pointer points to memory allocated in a different DLL, that memory can only be safely deallocated through that DLL! That would be bad design, but maybe the DLL provides some Release function for that purpose.
Freak30 wrote: On a more general note: Deleting a pointer on app exit doesn't make much sense,
I don't quite agree. Calling delete does more than just free memory. E. g. a the destructor of a file class might be implemented to flush the buffers and close the file properly. Not calling it would cause data loss! Other examples could be objects that stream data to the display or sound card: not closing them down properly may result in nasty artifacts. or think of a web connection to your bank account - do you want to leave it open?
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote:
Freak30 wrote: On a more general note: Deleting a pointer on
app exit doesn't make much sense,
I don't quite agree. Calling
delete does more than just free memory. E. g. a the destructor of a file class
might be implemented to flush the buffers and close the file properly. Not
calling it would cause data loss! Other examples could be objects that stream
data to the display or sound card: not closing them down properly may result in
nasty artifacts. or think of a web connection to your bank account - do you want
to leave it open?
You conveniently left the conditional part of my sentence out of the quote. If you e.g. have a text editor application that only allows opening one file at the time and the only way to close the file is by closing the application, of course you need to delete the file object on application exit. But if you had an editor that can keep open multiple files at once and one of the files is closed, would you keep the object for this file active and delete it on application exit? I would delete it as soon as the file is closed.
So my intention wasn't to say that you should never delete a pointer on appliaction exit. I wanted to say that it isn't a good idea to keep every pointer and delete all ofthem on application exit.
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
My point was different from yours - I was focusing on the misguided perception some people (not you) might have that the whole point of delete is freeing memory. Specifically programmers coming from C and used to malloc/free might not consider it worthwhile deleting every leftover object upon exiting an application because of that. I pointed out why this would be a mistake that could lead to problems beyond the lifetime of the program.
I do agree that any object allocated on the heap should be released (with delete) as soon as possible and not be kept around for longer than necessary. That is not what I understood from your statement though. Thanks for the clarification.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote: I pointed out why this would be a mistake that could lead to problems beyond the lifetime of the program.
Yes, great point!
Erik Westermann
|
|
|
|
|
DanielSheets wrote: aFunction()
You should have the documentation (or the source code) of aFunction in order to know what to do.
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
|
Thanks for the replies. All of them helped to shed light on the subject for me.
This is for a project being done with Qt. The documentation doesn't mention much about it (I couldn't find it anyway). I do have the source code though.
Thanks again.
|
|
|
|
|
A pointer is merely an address. In 32-bit Windows, it is a DWORD value. It's not even guaranteed that the address is valid, or that some data exists at that address.
A safe way to 'delete' your pointer, is just to assign it a value of zero.
That way, you can check first before attempting to use it.
|
|
|
|
|
Typically, well designed API functions (like those from QT) will not pass pointers to allocated memory and expect you to free it - unless the function is specifically designed to do just that. For the reasons pointed out above, that would be bad design.
In such cases, a better design would be to either return a container object by value, or a smart pointer (which, in a way, is also a kind of container), or the caller must pass a buffer to the function to hold the returned data - in which case both the allocation and deallocation are in the responsibility of the caller.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I've found the Qt documentation isn't all that great. The documentation for the MS frameworks is actually surprisingly good in comparison.
|
|
|
|
|
Be aware that in Qt, you don't always have to delete/free a pointer. When you add widgets, for example, the parent object takes ownership. I suspect that is the case here. (Moreover, you could argue that not freeing memory on exit isn't a leak since the entire process is going away and the applications heap will be deleted.)
|
|
|
|
|
Hi,
I think this may help you to get clarification, please see once. 
class student
{
int x;
public:
student()
{
x=0;
}
~student()
{
cout<<"I am in student destructor\n";
}
};
student* fun()
{
student *s = new student();
return s;
}
int main()
{
student *s = fun();
delete s;
getchar();
return 0;
}
|
|
|
|
|
Message Removed
modified 26-Jun-14 7:43am.
|
|
|
|
|
Hi,
I am no expert in C and I have started learning it again after several years. Excuse me for stupid questions. My question is simple.
When i give %f as conversion character inside printf, but pass some integer to it, what happens? It prints some garbage value? or is there any pattern?
Consider the below program..
#include <stdio.h>
main()
{
float gift1, gift2;
float total;
printf("How much do you want to spend on 1 \n");
scanf(" %f", &gift1);
printf("How much do you want to spend on 2 \n");
scanf(" %f", &gift2);
total = gift1+gift2;
printf("\nThe total you will be spending on gifts is $%.2f", total);
printf("\n %s %d %f %c", "Gokul", 90, 100, 'X');
return 0;
}
In the above program, i have added a final printf which has nothing to do with the rest of the program. I have simply added it. And i have passed the integer 100 to the %f conversion character. While executing the program, i give some random values for gift1,gift2 which accounts to, say 1958.9967. So, total is 1958.9967
But the value of total is also printed as part of my final line, like below
Gokul 90 1958.9967
Here, X is not printed as well. So, what is happening. Instead of 100, when i tried with 100.19, it gives the desired result (like below)
Gokul 90 100.19 X
I tried another small program like below..
#include<stdio.h>
main()
{
printf("\n %f specifies floating number, but i will give an integer",1987);
return 0;
}
Here, my output was like below
0.000000 specifies floating number, but i will give an integer.
Here, where does this 0.000000 comes from? In case of previous program it printed the value of "total" - why? what is the behavior here?
Btw, I am using Code Blocks compiler, if that's of any significance here.
Thanks in advance.
|
|
|
|
|
|
When %f is encountered in the format string, the computer attempts to pop a floating point number off of the stack, what it finds instead is 100, an integer. When you changed it to 100.19, the computer found what it was expecting.
My rule of thumb is always use a (double or float) cast, or append .0 to any floating point numbers. That way, these problems and others are avoided.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Dear You are trying to convert an int value into float without using any of the coversion processing thats why you got wrng ans. everytime when you put a int value
Similiarly when you are trying to put int value into float its also gave unrelevant answer
Frk
|
|
|
|
|
Hi Gokul,
I understood your doubt. Here i am trying to clarify why it is happening clearly.
printf("\n %s %d %f %c", "Gokul", 90,100,'X');
in the above piece of code if you observe clearly, with the assumption of starting address will be 0x1000, the contents of your piece of code will occupy memory as follows.
"Gokul"- at 0x1000
90 - at 0x1006
100 - at 0x1010
'X' - at 0x1015
Now as per your format specifiers first %s will fetch first 6 Bytes("Gokul"),
%d will fetch next 4 bytes of data as integer, so fetches 90,
now %f means it will fetch next 8 Bytes of data means from 0x1010 to 0x1017 which includes memory location of 'X' also, after fetching it will try to display float number but it won't display as no external coversion you are doing. So it will display 0.0000000
Then during this time we are at memory location 0x1018 in which some garbage value(Σ) will be there as we are not storing anything.
Even though if you give some other character in place of 'X' also it will give same value(Σ) as garbage is there in 0x1018 location.
if you change 100 to some float number or explicitly converted to float number((float)100), then it will occupy 8 bytes memory now. then no problems and no unwanted results you get.
If any clarifications feel free to ask, you will get help definitely.
Thank you.
modified 9-Aug-14 7:55am.
|
|
|
|
|
Hi I'm trying to learn 3D graphics using C++/MFC. I suppose the context of my questions don't really have to do with C++
perse but more linear algebra I guess. Please bear with me since I'm dumb as a rock.
From my research the pipeline consists of projections/transformation
"model (vertices)" -> World -> View Cube (or tho projection) -> screen.
after I transform the vertices of the model to "world" and then project it to the "view cube" for clipping I then flatten the vertices in the desired axis. So if I wanted a 2d orthographic side view, I would set the Y coordinate to 0 in the matrix to flatten.
Please see this graphic [^]
My question is, do I then need to rotate the left vector space I flatten the object(s) on to a "front" vector space and then draw on the screen?
thanks
modified 23-Jun-14 18:17pm.
|
|
|
|
|
Hi all
I want to achieve such an efect like - one view which takes all MDI area and some views which arelike non modal dialogs
How can I do it?
Two Child frames will be correct? one for "big" view which will be always visible and second for a "smal" views
maybe another solution would be better
Thank you in advance for help and advice
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
