|
1. the line
tree1->findOWN(new Student("",12105092))->merge(s1);
creates a memory leak, as the function argument is created on the heap, but never deleted.
2. your function CTree<t>::TCompare compares objects of type Student using
operator<(const Student&, const Student&) Did you define that operator? If not, the result of these comparisons are undefined. If you did, the error may be within the code of that operator definition.
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)
|
|
|
|
|
|
Member 10914803 wrote: Due to the sensitive nature of this project and the intellectual properties involved, we prefer to keep our exposure to a minimum. Thus, if you're interested in possibly getting involved then please reply here...
"That's funny right there!" -- Mater
"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
|
|
|
|
|
Member 10914803 wrote: keep our exposure to a minimum
The Backroom[^] would meet your requirement.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
|
|
|
|
|
Member 10914803 wrote: I am a seasoned Software Engineer
Does that mean you are covered with herbs and spices?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
|
Hello guys. I am trying to make and use a dll in VC++. I am following this sample. The dll compiles successfully. But when I try to integrate it's .dll, .lib and .h files in another project, then it gives me 5 linker errors. One of them is Error LNK2019 and rest are Error LNK2001. Couple of them look like this
1 - error LNK2019: unresolved external symbol "public: __thiscall CMyClass::CMyClass(void)" referenced in function "public: __thiscall CClientDlg::CClientsDlg(class CWnd *)"
2 - error LNK2001: unresolved external symbol "public: __thiscall CMyClass::~CMyClass(void)"
Just to let you know, I make a new folder and put all the said files in it. Then I add this path to the following properties
+ Properties-> Linker-> General-> Additional Library Directories<br />
+ Properties-> C/C++-> General-> Additional Include Libraries
What could I be doing wrong here? Thanks for any pointer.
|
|
|
|
|
|
Is that one of your export classes? ...how is it defined in the header? ...make sure you've labeled it as an import (that's the declspec part of the example) in the header file.
One thing I noticed about that example is that it's exporting functions, not really exporting classes. Difference is the constructor, if you're exporting/importing a whole class, this[^] is the way to do it. Look at the section labeled as "C++ Native Approach: Exporting a Class".... although it wouldn't hurt to read the whole article so you know get as much info as possible.
|
|
|
|
|
I am using a Windows host machine to cross compile programs on to a Linux RT platform using a GCC cross compiler.
Assume, the C program I write, links to a shared library libShared.so as I am using functions defined in that library inside my program.
In the Eclipse editor I am providing the library name (libshared.so), and its path under linker options. Now when I compile the program, I get compilation errors since libShared.so links to multiple other libraries (eg: lib11.so, lib12.so, lib13.so), but I am not explicitly calling any functions from these libraries.
My question is, Why should the compiler generate errors, when I don't explicitly use functions defined in those libraries ?
However when I specify the name and path of the libraries liked by libShared.so, the compilation passes.
|
|
|
|
|
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)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
