C / C++ / MFC

Re: external variables for C and C++ mixed program

31-Jul-06 12:14

hi,
i met a dreadful problem with my program
i decleared and defined an external variables in one .c file like this:
//File 1.c
int a=0;
...
main()
{}
...

and then i wanna use a as an external variable in one .cpp file where i defined a class ABC like this:
//file 2.cpp
extern int a;
....
Class ABC::MemberFunction()
{
int tmp=a;
}

the program passed compiling but not linking
the error message says: error LNK2001: unresolved external symbol "int a" (?a@@3HA)..

what happened??
i also tried to declare "a" as:
extern "C" int a;
but still doesn't work.

what's more, my boss started pushing me on the program

Taka Muraoka31-Jul-06 15:00

Taka Muraoka

31-Jul-06 15:00

In file2.cpp, you want your extern to look like this:

extern "C" { extern int a ; }

This tells the compiler the variable lives in a C module.

0 bottles of beer on the wall, 0 bottles of beer, you take 1 down, pass it around, 4294967295 bottles of beer on the wall.

Awasu 2.2.3 [^]: A free RSS/Atom feed reader with support for Code Project.

Re: external variables for C and C++ mixed program

zhijia.yuan1-Aug-06 9:44

A question about postmessage. [modified]

1-Aug-06 9:44

thanks
i gotcha!;)

zhijia.yuan31-Jul-06 12:11

Re: A question about postmessage.

31-Jul-06 12:11

i have a program like this:
main app is CMyApp ::CWinApp

i give an ID for a button on the main window:
ID_MY_BUTTON

i want to handle the click message in CWinApp's member function
so i mapped the message as:
ON_COMMAND(ID_MY_BUTTON, OnMyButton);

and write the code for the function
actually it works very well
but the question comes up when i tried this:
::postmessage(hMainWnd, ID_MY_BUTTON,Null,Null)

i used hMainWnd because i believe the message mapping net can automatically send the message to the main thread.
but, finally, i found this does not cause the OnMyButton to be called.

i also tried this one:
::PostMessage(hMainWnd, WM_COMMAND, ID_MY_BUTTON, 0)

but it still doesn't work Frown | :(

so, how should i send this ID_MY_BUTTON message so that the main thread can handle it?

thanks alot!

-- modified at 18:11 Monday 31st July, 2006

User 58385231-Jul-06 17:13

User 583852

31-Jul-06 17:13

I think generally its a bad idea to mix the mfc message handling stuff with the win32 functions. It should all work ok but your program will be easier to maintain if you pick one and stick with it.

You need to send the message to the parent window of the button. Off the top of my head you should try something like

MyButton->GetParent()->SendMessage(...);

Objects in mirror are closer than they appear

Re: A question about postmessage.

zhijia.yuan1-Aug-06 9:45

Getting the hStdOutput from CreateProcess.hStdOutput [modified]

1-Aug-06 9:45

thanks, i'll try!

darkcloud.42o31-Jul-06 11:17

darkcloud.42o

31-Jul-06 11:17

Hi,
Having some trouble getting a char* from the Stupinfo.hStdOutput which is a HANDLE.

STARTUPINFO Stupinfo; PROCESS_INFORMATION ProcessInfo;
char* procnm="Test.exe";
HANDLE h;
LPWSTR lpwString = L"";
lpwString = (LPWSTR)procnm;
IntPtr StdOutput;
Stupinfo.dwX=0;
Stupinfo.dwY=0;
Stupinfo.hStdOutput=h;
CreateProcess(NULL, lpwString, NULL, NULL, FALSE, 0, NULL, NULL, &Stupinfo, &ProcessInfo);
char* tesst="test";
tesst=Stupinfo.hStdOutput;
send(AcceptSocket, tesst, strlen(tesst), 0);

I know its not going to be easy unless there is simple convesion. but ive seen methods which output to .txt file for some reason.. but i dont see why you couldn't get the char*
Please Help

-- modified at 17:31 Monday 31st July, 2006

Re: Getting the hStdOutput from CreateProcess.hStdOutput

James Brown31-Jul-06 11:43

James Brown

31-Jul-06 11:43

You have to create a HANDLE *before* calling CreateProcess. Usually people use CreatePipe, but you can also pass socket handles as well. Then you ReadFile/WriteFile to the handle to read/write data.

http://www.catch22.net

Re: Getting the hStdOutput from CreateProcess.hStdOutput [modified]

darkcloud.42o31-Jul-06 12:10

darkcloud.42o

31-Jul-06 12:10

Could you please show me some code?

STARTUPINFO Stupinfo; PROCESS_INFORMATION ProcessInfo;
char* procnm="Test.exe"; char* tesst; BOOL readIntoMemory;
HANDLE h, hWritePipe; LPSECURITY_ATTRIBUTES lpPipeAttributes; DWORD nSize;
LPWSTR lpwString = L"";
lpwString = (LPWSTR)procnm; LPVOID inBuffer; DWORD nBytesToRead; LPDWORD nBytesRead, lpNumberOfBytesWritten;
DWORD bytestowrite;
IntPtr StdOutput;
Stupinfo.dwX=0;
Stupinfo.dwY=0;
Stupinfo.hStdOutput=h;
CreateProcess(NULL, lpwString, NULL, NULL, FALSE, 0, NULL, NULL, &Stupinfo, &ProcessInfo);
ReadFile( h, inBuffer, nBytesToRead, nBytesRead, NULL);
WriteFile( (HANDLE)AcceptSocket, inBuffer, bytestowrite, lpNumberOfBytesWritten, NULL);

how to use the WriteFile to get a char*?? and do i have it setup correctly?

-- modified at 19:25 Monday 31st July, 2006

Adding member variables crashes app

Wheatbread31-Jul-06 9:49

31-Jul-06 9:49

Hi!

We have a class CDriver which inherits from IDriver. CDriver is defined in a library, CDriver.lib. CDriver.lib is added to the library definition of the project settings, and we have CDriver.h included in the file list for the project.

If we create a new class, CMyDriver, which inherits from CDriver, and add member variables to it, when we run the app, things crash when the destructor is called. If we remove the member variables things work properly. We can add as many member functions as we want, but cannot add member variables.

We dont understand that's happening. Any ideas? This is basic inheritance!! This is weird that I cannot add member variables.

Help!?!?!?
-C

C^hris L^osinger31-Jul-06 9:57

C^hris L^osinger

31-Jul-06 9:57

sounds less like an inability to add member variables, and more a case where something is happening in the destructor of the CMyDriver class that crashes the app.

can you step into the destructor in the debugger ?

Why donchoo take a peekchur mayn?
OK, cleeeeek

Wheatbread31-Jul-06 10:34

31-Jul-06 10:34

I cannot step through it in the debugger as it simply crashes. Frown | :-(

Hans Dietrich31-Jul-06 10:02

Hans Dietrich

31-Jul-06 10:02

When you say, "CDriver is defined in a library", I assume you mean a DLL. If that is the case, then search for any old copies of the DLL that may be getting loaded. For example, did you previously copy it to the Windows directory? If you find old copies, rename them and make sure the current DLL is in the app's exe directory, and try again.

This may not be the cause of the crash, but it is a good starting point.

Best wishes,
Hans

Wheatbread31-Jul-06 10:35

31-Jul-06 10:35

CDriver is defined in a library (.lib) file that statically linked at compilation. I'm pretty sure its loading the correct lib file, but I'll double check.

Zac Howland31-Jul-06 10:13

31-Jul-06 10:13

Is the destructor in CDriver declared as virtual?

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Wheatbread31-Jul-06 10:37

Re: Adding member variables crashes app [modified]

31-Jul-06 10:37

No, the destructor is not virtual. Should this be? If so, I guess I've forgotten basic C++ inheritance rules in which my question makes me look silly!! Smile | :)

Zac Howland31-Jul-06 10:47

31-Jul-06 10:47

Yes. The destructor MUST be declared virtual if you plan to derive from it. Here is why:

class Base
{
public:
	Base() {}
	~Base() {}
private:
	// whatever you want here
};

class Derived : public Base
{
public:
	Derived() {}
	~Derived() {}
private:
	int m_MyInt;
};

void main()
{
	Base* pB = new Derived;
	delete pB;	// memory leak
}

What happens is that the ~Base() destructor is called, but not the ~Derived(). Thus, m_MyInt stays allocated in memory (that is, the portion of memory allocated for a Base object is freed, but not that for Derived). This is called memory slicing (see "Effective C++" by Scott Meyers for more details).

The rule of thumb: If your class is meant to have classes derived from it, it MUST have a virtual destructor.

This problem can (and will) blow up your memory eventually (either stack or heap or both).

-- modified at 16:48 Monday 31st July, 2006

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Wheatbread31-Jul-06 11:06

31-Jul-06 11:06

Thanks. This was a good catch. Unfortunately, I still get an 'access violation' at destructor. I set a breakpoint in my derived class CMyDriver, and it doesnt step into the CDriver nor IDriver.

I'm just confused. If I remove the member variables from the class definition, things work fine. Frown | :-(

Zac Howland31-Jul-06 11:14

31-Jul-06 11:14

Any way you can actually show the code (slimmed down) you are using? The definitions of all 3 classes and the implementations for the destructors would be helpful in evaluating your problem.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Wheatbread1-Aug-06 12:28

1-Aug-06 12:28

CIDriver, CDriver and CMyDriver all have virtual destructors.

__declspec(dllexport) CIDriver* InitDriver(CIKernel* i_hKernel)
{
//__asm { int 0x03 }

CMyDriver* hUserDriver = new CUserDriver;
hUserDriver->Create(i_hKernel);
return (CIDriver *)hUserDriver;
}
__declspec(dllexport) void EndDriver(CIDriver* i_hIDriver)
{
CMyDriver * hUserDriver = (CMyDriver *)i_hIDriver;
hUserDriver->Destroy();
delete hUserDriver;
}

My app crashes at the 'delete hUserDriver'. EndDriver is an exposed interface call that another DLL calls to detroy the driver. hUserDriver->Destroy() destroy all internal structures of CDriver (not CMyDriver, as this function isnt overloaded in CMyDriver). CMyDriver is not referencing any objects destroyed by the Destroy call. Nothing is available in the debugger as its all assembly at that point.

In the class definition for CMyDriver, if I add public member variables, it crashes on the delete. If I make them global (file scope), it doesnt crash.

I"m wondering if its looking at the class size or something. I'm just confused.
-C

Zac Howland1-Aug-06 17:07