C / C++ / MFC

21-Aug-07 17:13

Hello everyone,

I find that when using Debug build, we do not need to set linker --> input --> Advapi32.lib, but when using Release build, we need to set linker --> input --> Advapi32.lib. Or else, there will be error message, unresolved symbol RegSetValueEx.

I am using Visual Studio 2005.

thanks in advance,
George

ThatsAlok21-Aug-07 23:55

ThatsAlok

21-Aug-07 23:55

George_George wrote:
I am using Visual Studio 2005.

is there is any problem!!!

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief

George_George22-Aug-07 0:11

22-Aug-07 0:11

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

David Crow22-Aug-07 2:47

David Crow

22-Aug-07 2:47

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

George_George22-Aug-07 3:13

Fairly basic pointer/array question

22-Aug-07 3:13

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

MALDATA21-Aug-07 16:32

21-Aug-07 16:32

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 />
// This prints out garbage.<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];  // Make an array of pointers to 3 nodes<br />
<br />
  node* test1 = new node(7);   // Make new nodes and put them in there<br />
  node* test2 = new node(3);<br />
  node* test3 = new node(9);<br />
<br />
  out[0] = test1;   // Fill the array with pointers to the nodes<br />
  out[1] = test2;<br />
  out[2] = test3;<br />
<br />
  cout << out[0]->toString() << endl;  // This part works fine.<br />
  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!

cp987621-Aug-07 16:54

21-Aug-07 16:54

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."

MALDATA21-Aug-07 18:17

21-Aug-07 18:17

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?

cp987621-Aug-07 19:13

21-Aug-07 19:13

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."

Nelek21-Aug-07 20:14

21-Aug-07 20:14

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 Wink | ;)

). 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?

cp987621-Aug-07 21:12

21-Aug-07 21:12

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;
   // do something
   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."

Nelek22-Aug-07 1:20

22-Aug-07 1:20

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);

//do something

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?

MALDATA22-Aug-07 4:18

22-Aug-07 4:18

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!

Nelek22-Aug-07 4:55

22-Aug-07 4:55

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?

MALDATA22-Aug-07 8:39

22-Aug-07 8:39

You're right... I changed it from

<br />
myArray += sizeof(node*);<br />

<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.

Nelek22-Aug-07 20:01

22-Aug-07 20:01

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);  //Without the *<br />

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?

cp987622-Aug-07 20:40

CreateDirectoryA can not be resolved

22-Aug-07 20:40

Why are you messing around with sizeof(). The normal way to access members of the array is:

cout << "The array contains..." << endl;<br />
<br />
// This prints out garbage.<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."

George_George21-Aug-07 16:27

Re: CreateDirectoryA can not be resolved [modified]

21-Aug-07 16:27

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

Paresh Chitte21-Aug-07 18:36

Paresh Chitte

21-Aug-07 18:36

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

George_George21-Aug-07 20:51

21-Aug-07 20:51

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

Paresh Chitte21-Aug-07 22:05

Paresh Chitte

21-Aug-07 22:05

Linker could not find the definition of CreateDirectoryA, could not locate the correct library. It could be because of VS2005 installation (UNICODE support).

Please refer below threads,
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=673882&SiteID=1[^]
http://forums.microsoft.com/msdn/showpost.aspx?postid=673882&siteid=1&sb=0&d=1&at=7&ft=11&tf=0&pageid=1[^]

Regards,
Paresh.

George_George21-Aug-07 22:23

21-Aug-07 22:23

Thanks Paresh,

I suspect there is no implementation from Microsoft of CreateDirectoryA on Windows CE platform.

regards,
George

David Crow22-Aug-07 2:30

David Crow

22-Aug-07 2:30

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

George_George22-Aug-07 3:16