|
Thanks Alok,
I do not know why we need to add input for Advapi32.lib if we make a release build, and we do not need to import Advapi32.lib for debug build?
I think import library dependencies should be consistent for both debug and release version.
regards,
George
|
|
|
|
|
George_George wrote: I think import library dependencies should be consistent for both debug and release version.
That's true, so what is your question?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi David,
I do not know why we need to add input for Advapi32.lib if we make a release build, and we do not need to import Advapi32.lib for debug build?
If we need an import library, I think both debug and release version need the import library file. why only release version needs this file?
regards,
George
|
|
|
|
|
So I'm sure everyone else has seen stuff like this, but I'm not sure where in the array/pointer jungle I got lost. Here's a sample... I apologize for the huge chunk of code. A node is just a little class that holds an integer... it's for demonstration purposes. The toString() function is a method which prints out that node's integer.
<br />
#include <iostream><br />
#include "node.h"<br />
<br />
node** makeArray();<br />
<br />
using namespace std;<br />
<br />
int main(int argc, char* argv[])<br />
{<br />
node** myArray;<br />
myArray = makeArray();<br />
<br />
cout << "The array contains..." << endl;<br />
<br />
cout << (*myArray)->toString() << endl;<br />
myArray+=sizeof(node*);<br />
cout << (*myArray)->toString() << endl;<br />
myArray+=sizeof(node*);<br />
cout << (*myArray)->toString() << endl;<br />
}<br />
<br />
node** makeArray()<br />
{<br />
node* out[3];
<br />
node* test1 = new node(7);
node* test2 = new node(3);<br />
node* test3 = new node(9);<br />
<br />
out[0] = test1;
out[1] = test2;<br />
out[2] = test3;<br />
<br />
cout << out[0]->toString() << endl;
cout << out[1]->toString() << endl;<br />
cout << out[2]->toString() << endl;<br />
<br />
return out;<br />
}
The output is
<br />
7<br />
3<br />
9<br />
The array contains...<br />
1310504608<br />
1310520796<br />
-1077666540<br />
So where did I go wrong? By the way, this is all for the sake of learning and understanding, so I'm not looking for an easier way to do this particular job, I'm looking to understand what's going on in this case.
Thanks!
|
|
|
|
|
It's nothing to do with pointers. You are creating a stack object 'out' in the function makeArray() and returning a pointer to it, but it doesn't exist once you have left makeArray().
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
That makes sense, except that when I tried this initially I used integers rather than nodes in the makeArray function. It worked then. I am fairly certain that I didn't change anything other than the variable types. I suppose I did.
Thanks for the help, if I can't fix it, I'll post again. Everything else looks ok?
|
|
|
|
|
Returning a pointer to an object created on the stack in a function is definitely a no no, even if it worked once. This can lead to very hard to find bugs. When you created 'out' on the stack and used it in makeArray, all was fine until you returned. Then the stack pointer was altered and these old stack locations were available for reuse. Depending on the following code, and other variables declared on the stack in makeArray, sometimes you will find them intact, and at other times they will be overwritten. Every function you call (directly or indirectly through operator overloading such as <<) will use the stack and may overwrite them.
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
I had that problem in the first version of one project. It was pretty hard to find out what was happening because I was very bad programming (I now am not very good, but I at least can defend me a bit  ). The fact is that I had to remake the programm when I started in one Firm, to adapt it to the Firm wishes not to my teacher's wishes.
The fact is that pointers to local objects, may point to nothing or to wrong areas when returning values to other point of the program. But you can still do that, if you want, making a different aproach.
If you are using Doc/View architecture (If not you can "simulate" it using a "DataStore" class/module), You may code more or less the same as you have, but returning a reference to an object that will not be destroyed when you return.
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
Nelek wrote: If you are using Doc/View architecture (If not you can "simulate" it using a "DataStore" class/module), You may code more or less the same as you have, but returning a reference to an object that will not be destroyed when you return.
Returning a reference to a local object is just as bad as returning a pointer (same thing in fact, different syntax). The only safe way to return a local object is to return a copy of it, e.g.
int function()
{
int n;
return n;
}
You can do the same thing with objects, but you will invoke the object's copy constructor.
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
If you look at what I said correctly... I haven't said that.
"You may code more or less the same as you have, but returning a reference to an object that will not be destroyed when you return."
COneThing* function ()
{
COneThing* thing = pDoc->FindOneThing (szName);
return thing;
}
You return the reference to a local object, but the local object is pointing to Doc's saved datas. I have made so and works
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
OK, I changed it so that the out array is now allocated from the heap
<br />
node* out = new node*[3];<br />
And now the output looks something like this:
7
3
9
The array contains...
7
garbage
garbage
So it looks like you solved the problem, and that makes sense to me. It gets the array back and can dereference the first element of the array, but I'm apparently not iterating the pointer properly to get to the next elements. As it is, I use the pointer, myArray, plus sizeof(node*) to get to the next element of the array.
<br />
myArray+=sizeof(node*);<br />
Should it be something other than node*? If so, what and why? It's an array of pointers to nodes, so shouldn't the next one just be sizeof(node*) away from the first?
Thanks for the help!
|
|
|
|
|
node* out = new node*[3];
Should it not be...
node* out[3] = new node* [3]; ???
And with the sizeof... im not sure about. I had problems with it too.
I made:
(THIS IS FALSE)
DWORD Header [9];
void CTool::WriteHeader (CFile* file)
{ Header[0] = MAGIC;
Header[1] = VERSION;
Header[2] = CalculateCodeLarge ();
Header[3] = CalculateDataLarge ();
Header[4] = CalculateNumberOfElements ();
Header[5] = RESERVE;
Header[6] = (DWORD) m_cmlSet1.GetCount ();
Header[7] = (DWORD) m_cmlSet2.GetCount ();
Header[8] = PCRES;
file->Write (&Header[0], sizeof (Header));
return;
}
and I solved it with:
(THIS IS WORKING GOOD)
DWORD Header [9];
void CTool::WriteHeader (CFile* file)
{ Header[0] = MAGIC;
Header[1] = VERSION;
Header[2] = CalculateCodeLarge ();
Header[3] = CalculateDataLarge ();
Header[4] = CalculateNumberOfElements ();
Header[5] = RESERVE;
Header[6] = (DWORD) m_cmlSet1.GetCount ();
Header[7] = (DWORD) m_cmlSet2.GetCount ();
Header[8] = PCRES;
DWORD* pHeadBuf;
pHeadBuf = &Header[0];
file->Write (pHeadBuf, sizeof (Header));
return;
}
I think is because a Pointer has a fixed longitude for the sizeof, but your object does not. So if you increment in the size of a pointer, you will may have not enough place to the datas contained in your object, or maybe too much place. Or just looking with a completely false adress, what would made you have garbage.
Actually you should increment the pointer in one adress to point your next element, but the size you are moving is actually the size of your object.
I hope that I have explained myself not meaningless (im not englishspeaker) and that it helps you (im not such a good programmer as many others in this site)
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
You're right... I changed it from
<br />
myArray += sizeof(node*);<br />
to
<br />
myArray++;<br />
which may have been what I had when I was using integers, and everything works fine now.
Thanks everyone, I think I understand all of this a little better now.
|
|
|
|
|
Exactly,
with this you are automatically pointing to the next element on your array.
But it actually is not the same as working with integers. because with integers you increase by one an interger that specify the index.
Im not 100% sure, but
<br />
myArray++;<br />
should be the same as
<br />
myArray += sizeof(node);
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
Why are you messing around with sizeof(). The normal way to access members of the array is:
cout << "The array contains..." << endl;<br />
<br />
cout << myArray[0]->toString() << endl;<br />
cout << myArray[1]->toString() << endl;<br />
cout << myArray[2]->toString() << endl;
This also has the advantage of keeping the myArray pointer, which you will need to delete the memory.
I'm not 100% sure what is happening in your old code, but by default the compiler will take ptr++ as moving ptr to the next element in the array. If one of the gurus reads they will probably be able to tell you, but I guess that to make your code work:
myArray+=sizeof(node*);
you would have to cast the myArray pointer to void*.
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
|
Hello everyone,
I am developing a DLL project for Windows Mobile (C/C++). I have removed the UNICODE and _UNICODE definition from project --> settings. But build the following code, there is an error (compile could pass, but link can not pass),
error LNK2019: unresolved external symbol CreateDirectoryA referenced in function foo
<br />
#include "winbase.h"<br />
<br />
int foo()<br />
{<br />
CreateDirectory (L"hello", NULL);<br />
CreateDirectoryA ("hello", NULL);<br />
CreateDirectoryW (L"hello", NULL);<br />
<br />
return 0;<br />
}<br />
thanks in advance,
George
|
|
|
|
|
Look at "winbase.h" header for typedef of CreateDirectory,
WINBASEAPI<br />
BOOL<br />
WINAPI<br />
CreateDirectoryA(<br />
__in LPCSTR lpPathName,<br />
__in_opt LPSECURITY_ATTRIBUTES lpSecurityAttributes<br />
);<br />
WINBASEAPI<br />
BOOL<br />
WINAPI<br />
CreateDirectoryW(<br />
__in LPCWSTR lpPathName,<br />
__in_opt LPSECURITY_ATTRIBUTES lpSecurityAttributes<br />
);<br />
#ifdef UNICODE<br />
#define CreateDirectory CreateDirectoryW<br />
#else<br />
#define CreateDirectory CreateDirectoryA<br />
#endif // !UNICODE
Regards,
Paresh.
-- modified at 0:42 Wednesday 22nd August, 2007
|
|
|
|
|
Hi Paresh,
I have read that reply. In my situation, I invoke CreateDirectoryA directly, but why there is an unresolved link error?
I think even if UNICODE is not defined, I could invoke CreateDirectoryA directly, right?
regards,
George
|
|
|
|
|
|
Thanks Paresh,
I suspect there is no implementation from Microsoft of CreateDirectoryA on Windows CE platform.
regards,
George
|
|
|
|
|
George_George wrote: error LNK2019: unresolved external symbol CreateDirectoryA referenced in function foo
This is because you do not have Unicode defined.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Yes David,
I have not defined UNICODE. But if I do not define UNICODE, CreateDirectoryA should be linked. Why there is unresolved symbol error? Microsoft does not have the implementation for CreateDirectoryA for Windows CE?
regards,
George
|
|
|
|
|
Hi,
I would really appreciate if anyone could help me with a project in which I want to write code for encoder. Can you guys help that what do I need for it?
I will be very much helped.
Thanks
C++Prog
|
|
|
|
|
I want to know what do I need for starting up this project. If you guys can give me your ideas, all will be very much appreciated.
Thanks again
C++Prog
|
|
|
|
|
SHJDU UYSJD DIFGD KJDDP DNDIF DDEEK JUFUD UDIKS UUDEP UIMHQ SUJDO SUBAF
Peter
"Until the invention of the computer, the machine gun was the device that enabled humans to make the most mistakes in the smallest amount of time."
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
