Re: [Quickfix-developers] Confused by possible bug in Utility.cpp / thread_spawn
Brought to you by:
orenmnero
From: K. F. <kfr...@gm...> - 2013-01-22 18:38:44
|
Hi Djalma - On Tue, Jan 22, 2013 at 12:34 PM, Djalma Rosa dos Santos Filho <drs...@gm...> wrote: > > Hi Frank, > > Sorry, I thought that it had something to do with the C spec because _beginthreadex belongs to the C runtime libraries and mingw is a gcc port that relies in the obsolete VC 6 (according to the project's wiki). First, I'm using mingw-w64 which is a different project than mingw. Second, I wouldn't be surprised is the mingw wiki is out of date. Third, my guess is that mingw was never trying to be consistent with language idiosyncrasies of VC6. It is a port of gcc, so I think they were -- both by default and by intent -- sticking with the gcc "interpretation" of the language. Mingw does want to interoperate with VC (although not necessarily anything as old as 6) in the sense of ABI compatibility (with C, and where possible). > Actually, I was curious and then I found out that the ampersand (&) to specify the address of a function is optional for Visual C++ compiler. It means that utility.cpp will compile under msvc with or without the & in front of func. I believe that '&' is optional for taking the address of a function in the standard (not just VC). That is void f() {} void (*fp) (); fp = f; // these two line are equivalent fp = &f; // these two line are equivalent But that is not what we're doing. "func" in the thread_spawn call is a formal argument (that happens to be a pointer to a function), and is stored on the stack when thread_spawn is called. "func" is not a function, in the technical sense that "f" is a function in the example above. So &func is the address on the stack where the value of the argument func is stored. &func and func are not the same, and (if you want a pointer to a pointer) there is nothing optional about the '&'. > > Indeed, it is very weird but for non-static member functions it would be required. Well, pointers to member functions are different, both in what they actually are, and in syntax. > error C3867: 'MyStruct::f': function call missing argument list; use '&MyStruct::f' to create a pointer to member > > Maybe we can conclude that it is a bug in mingw for not accepting the optional ampersand (C language) and an inconsistency in the C++ language for having different rules for static and non-static member functions. I think mingw-w64 is correct. Also, as explained above, the case we're dealing with is not the case where the '&' is optional. > What is your opinion? I can't figure out how the code could work. When func is a pointer to a function, then &func is a pointer to (the address of) that pointer. I can't imagine that VC doesn't do it that way, because if VC didn't, it would break a lot of code. And if VC is taking the pointer to the pointer, then 1) the code in question shouldn't compile, and 2) the code should fail. > Check these links for more clarification: > http://www.velocityreviews.com/forums/t277815-pointer-to-member-functions-is-and-required.html > http://msdn.microsoft.com/en-us/library/ms177253%28v=vs.80%29.aspx The question of pointers to member functions is an interesting side issue, but is not directly relevant to the case of free functions, which is what we're discussing. > Djalma Thanks for looking into this. K. Frank > On Thu, Jan 17, 2013 at 12:30 PM, K. Frank <kfr...@gm...> wrote: >> >> Hi Djalma! >> >> Thanks for the follow-up. >> >> On Thu, Jan 17, 2013 at 8:53 AM, Djalma Rosa dos Santos Filho >> <drs...@gm...> wrote: >> > >> > In the last couple of years, Microsoft has made a huge effort to be compliant with the C/C++ standard. >> > Perhaps, the problem relies in the fact that you are using MinGW which has been forced to conform to C89. >> >> I don't think this is the explanation. >> >> First off, this is all C++, not C or C89. Second mingw-w64 is very >> compliant. (Not perfect, but what is?) Third, there really shouldn't >> be any mystery here. The code looks pretty straightforward here, >> and according to my reading of the standard, the '&' in "&func" is >> an error. I could well be wrong, but I'd like to know specifically what >> I'm wrong about. >> >> > http://www.mingw.org/wiki/C99 >> >> Again, C99 is not directly relevant. C++ is. But I'm not aware of any >> relevant changes to function-pointer syntax that have occurred between >> the various versions of C and of C++. >> >> > If so, you are right, an #ifdef for mingw would fix it. >> >> Indeed. But maybe such an #ifdef isn't needed. Perhaps "func" (without >> the '&') would also work for visual studio. >> >> > But, why don't you try Visual Studio Express for free? >> >> Compatibility issues with other code that isn't specifically part of >> QuickFIX. >> >> I appreciate your help with this. >> >> K. Frank >> ... |