|
Hi,
while converting C code to C++, I get a casting warning that I can't get rid of
"Warning (Anachronism): Assigning void(*)(int) to extern "C" void(*)(int)"
Anyone? Thanks
#include <signal.h>
struct sigaction sgnl_action;
void handle_alarm() {
alarm_timededout_=TRUE;
...
}
void alarm_manager_(char *typ) {
if (!strcmp(typ,"init")) {
void (*func)() = handle_alarm;
sgnl_action.sa_handler = func;
....
}
void alarm_manager_(char *typ) {
if (!strcmp(typ,"init")) {
sgnl_action.sa_handler = (void (*)(int))handle_alarm; ....
}
|
|
|
|
|
What happens with:
void handle_alarm( int )
{
}
...
sgnl_action.sa_handler = handle_alarm;
|
|
|
|
|
I get the same exact warning, thats how I had it originally, then I explicitly specified the casting thinking it will get rid of the warning.
It seems to get rid of the warning if I do this, but not sure if its correct functionality?
extern "C" void print(char *)
{
...
}
|
|
|
|
|
The parentheses you have in
sgnl_action.sa_handler = (void (*)(int))handle_alarm; looks strange to me. Perhaps
sgnl_action.sa_handler = (void*)((int)handle_alarm); would solve your problem.
Just a guess at the moment - not near my VS to test it.
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
This would give an error because the cast is (void(*)(int))(func). Anyways, the complain is about tryiing to cast to an extern "C", when I change my function to an extern "C", it seems to work fine. So, it looks as the signal handler functions have to be standalone external C functions.
Thanks
|
|
|
|
|
Because the unix / posix libraries work with either C or C++, they all declare their external functions as 'extern "C"' to get the C calling conventions. This is done in the header files, in your case, Signal.h
#ifdef __cplusplus
extern "C" {
#endif
The field sa_handler needs to point to a function that is declared as "C" callable. Use __cdecl. Note that C calling conventions also affect how the stack arguments are cleaned up so unless you declare the action function correctly, you will end up with stack corruption problems later.
void __cdecl handle_alarm() {
alarm_timededout_=TRUE;
...
}
|
|
|
|
|
hi I dnt knw clearly what type of
sgnl_action.sa_handler is. But this is a little piece of code without any warning and errors might be helpful to you.
#include <stdio.h>
void (*sa_handler)(int);
void handle_alarm() {
printf("helooo");
}
void main(int argc, _TCHAR* argv[])
{
handle_alarm();
sa_handler = (void (*)(int))handle_alarm;
sa_handler(0);
}
|
|
|
|
|
I need to know if focus is on a treeview, and I try it in follow way :
BOOL CMainFrame::IsTreeView(CWnd* pWnd)
{
ASSERT(pWnd != NULL);
HWND hWnd = pWnd->GetSafeHwnd();
if(hWnd == FALSE)return FALSE;
TCHAR szClassName[10];
return ::GetClassName(hWnd, szClassName, 10) && _tcsicmp(szClassName, _T("TreeView")) == 0;
}
but didn't work it ... what I've do wrong ? Thanks.
In fact, I need to enable an menu item, if I got focus on a treeview window :
void CMainFrame::OnUpdateEditNewItemMenu(CCmdUI* pCmdUI)
{
CWnd* pWnd = GetFocus();
pCmdUI->Enable(IsTreeView(pWnd));
}
void CMainFrame::OnEditNewItemMenu()
{
MessageBox(_T("aaaa"));
}
|
|
|
|
|
The answer is in my question 
::GetClassName(hWnd, szClassName, 12);
TRACE("%s\n",szClassName);
|
|
|
|
|
In fact, the class name of Tree View is SysTreeView32, it can be found in commctrl.h.
|
|
|
|
|
Hi, I'm developing a win32 dll, I'm a c# programmer without a lot of experience in c++. Anyway, my dll have to expose a few functions and also has to communicate with a serial port, but my questions is, if one of these functions to expose is like "WriteCommMsg(MsgStr * msg)", I don't know were to declare the necesary variables, for example if I'd have to save the last send msg, were this variable would be declared?, I mean, my doubt is what is the lifetime of the variables in a dynamic win32 dll.
thanks
skabo - Robots are a dynamic work of art...
|
|
|
|
|
The lifetime of static objects for a DLL application is from the Load of your DLL up to the removal (often, program termination) from the executable it is used in.
Some extra information (though not entirely answering your question) can be found here: DllMain entry point[^]. In terms of this article, the static objects live from just before the call with DLL_PROCESS_ATTACH and just until after the call to DLL_PROCESS_DETACH.
Specifically for WriteCommMsg, it looks like the variable (MsgStr) is caller allocated, so you do not need to worry about lifetime of objects there. If msg is used to output data, just write it to the location pointed to. If it is used for input, either use it right away, or save it by copying it to a variable with the appropriate lifetime (probably static in that case).
Easiest way to look at a DLL is as just another executable, except for that it doesn't run stand-alone, but always as part of another executable.
|
|
|
|
|
skaboFer wrote: WriteCommMsg(MsgStr * msg)", I don't know were to declare the necesary
variables
The caller would supply the variable, either stack, or heap based, so your dll wont need to worry about it.
skaboFer wrote: if I'd have to save the last send msg
Then your dll will have to allocate some stack memory and copy the message to it (alloc() or new).
As for lifetime, it is as long as you like with the heap. Remember to free it befoire your dll exits, because if not, you have a memory leak.
You could use static variables, these last the lifetime of the dll in memory.
==============================
Nothing to say.
|
|
|
|
|
skaboFer wrote: I mean, my doubt is what is the lifetime of the variables in a dynamic win32 dll.
In general the only variables you shaould keep in your DLL are const values that will never change. All non-const variables should belong in your main program and be passed to the DLL routine as required, in the same way as in C#. In your sample function above you define a library function (in the DLL) with the signature
WriteCommMsg(MsgStr * msg)
Here msg is a pointer (reference in C#) to a variable of type MsgStr, but the actual data that msg refers to is stored within the application not the DLL, something like:
MsgStr myMsgString = "message to write"; WriteCommMsg(&myMsgString);
If you wish to keep variable data within your library routines during the lifetime of your application then you should use a static library rather than a DLL.
|
|
|
|
|
First of all thanks!
Ok I understand the part of the pointer to the struct that tha main app pass to my function.
But you say that to keep data in my library I should use a static lib instead of a dll, but
could I just declare a static global variable/object?
And what do you think about the object to handle the serial port? where should I declare
the serialPort variable?
Again, thanks for the answers!
skabo - Robots are a dynamic work of art...
|
|
|
|
|
skaboFer wrote: could I just declare a static global variable/object?
You could but it is generally not considered good form, you should use proper parameter passing between methods in the same way that you would in C#.
skaboFer wrote: where should I declare
the serialPort variable?
Again declare it in your main application and use the classes or functions in your library to access it without the need to know its actual values. If the code in your DLL becomes specific to the application then there is absolutely no point in creating the DLL in the first place, just put everything in the application.
|
|
|
|
|
That's my point...this dll it's not for a especific application, it is a dll based in a norm that only specified the prototypes of the functions that the dll has to have, so then every user application could use it, but the user app doesn´t matter about de serial port...so I have to manage it in my dll...
thanks
skabo - Robots are a dynamic work of art...
|
|
|
|
|
hello guys... I have a static library. Now I used this library with another project and compiled both of these. I got plenty of linking error (mostly LNK2001 and LNK2005). I went to both projects' properties and changed
Use of MFC: Use MFC in Shared DLL
Now question is: since the library is static, should I be using
Use of MFC: Use MFC in Static Library ? Some tutorial on it is more than welcome. thnx
|
|
|
|
|
This setting purely affects the way the MFC dlls are used with your applicaiton. They are either linked statically, ie, they are built into the exe (like a .lib file) or they are not, in which case the machine your exe is going to run on had better have the latest MFC dlls installed. (See Microsofts ludicrously named 'side by side' installation for more info on what an utter joke this has become. Yes, with manifests, and versions. Dll hell just became manidest hell...).
Anyway, enough slaging off the people at Microsoft...
Your library is either a dll or a lib.
If it is a lib then you want to use static linking. Make sure the lib is in the link path, and make sure the lib is added to the projects link settings.
If it is a dll you want to use dynamic linking. Even with a dll there is a tiny little lib file, make sure that is in your link path and that it is added to your projects link settings. And deploy the dll with your exe.
==============================
Nothing to say.
modified on Thursday, September 15, 2011 6:12 AM
|
|
|
|
|
For Visual Studio, under the project properties go to the Linker tab. Under general, you can modify the Additional Library directories field if the *.lib file created by your other project is not in a standard directory and not in the same directory as the project. Then under Input, you add the lib file under Additional Dependencies (you probably already see the standard files, such as kernel32.lib, user32.lib, etc. added).
|
|
|
|
|
Yes, I know. That is what I said to the OP. 
==============================
Nothing to say.
|
|
|
|
|
I hate it when people reply to me when they meant that for OP. 
|
|
|
|
|
I thought it cleaner (view-wise) to respond to you, to make it clear it was a small specific addition to what you said. If the OP read your answer, he/she (I figured) would probably read my answer right after it.
Unfortunately, the alert system at CP only decides to inform you. But in this case, it doesn't matter because my post was only an addition to your post for if the OP hadn't seen it yet.
|
|
|
|
|
OK, so next time reply to the OP and say "in addition to what xxx said..."
That way you are seen as giving credit, rather than copying someone else, and the right person gets your post.
==============================
Nothing to say.
|
|
|
|
|
I should think that, assuming I was not doing this by mistake, one would see this as giving credit.
If I had posted in parallel without referring to the other person's post, now that would indeed look like copying.
And I already explained why I thought it was acceptable that the OP did not receive a notification.
All in all, I don't see why everybody is getting all round up about this. Technically, I was doing it right ... But apparently, I am in heavy violation of CP forum etiquette (specifically CP forum, as other forums I have been active on do not go into a /rage mode over such as I've seen happen here :P )
Maybe it's the extra spam? Then again, one can hardly post on a board and then complain about notifications.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
