Re: [Quickfix-developers] Confused by possible bug in Utility.cpp / thread_spawn
Brought to you by:
orenmnero
From: K. F. <kfr...@gm...> - 2013-01-17 14:30:35
|
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 > ... > On Thu, Jan 17, 2013 at 11:16 AM, K. Frank <kfr...@gm...> wrote: >> >> Hello Djalma! >> >> Thanks for taking a look at this. >> >> On Thu, Jan 17, 2013 at 7:17 AM, Djalma Rosa dos Santos Filho >> <drs...@gm...> wrote: >> > >> > Hi Frank, >> > >> > Is the name of the function the function pointer itself? >> >> As I understand c++ (and c), yes. When you use the name of a >> it "decays" into a function pointer (in the same way that the name >> of an array decays into a pointer to the first element of the array). >> >> > IMHO, this is just a matter of syntax and compiler implementation detail. >> > You might want to check the C99 spec and the compiler documentation. >> >> It is syntax, but I think it's standardized, and therefore it shouldn't >> be a compiler-specific detail. >> >> Also, the unix branch for the code (line 488 of Utility.cpp): >> >> if( pthread_create( &result, 0, func, var ) != 0 ) return false; >> >> does not have the '&' on "func" and compiles fine. Note, that "func" >> is not the name of a function, but rather a formal argument to the >> thread_spawn function (line 479): >> >> bool thread_spawn( THREAD_START_ROUTINE func, void* var, thread_id& thread ) >> >> (If I parse the typedef of THREAD_START_ROUTINE correctly, >> THREAD_START_ROUTINE is indeed a pointer to a function in >> both the windows and unix branches of the code.) >> >> So the unix branch looks right -- func is a function pointer, and >> there is no '&' to take the pointer to the pointer. >> >> But the windows branch (line 484): >> >> result = _beginthreadex( NULL, 0, &func, var, 0, &id ); >> >> has the '&' so "&func" is a pointer to func (the address of wherever >> func is stored on the stack when thread_spawn is called), and >> func is a pointer to a function, so "&func" is, as I read t, a >> pointer-to-pointer-to-function. >> >> What I don't understand, following up on Mike's comment, is >> why this would compile with visual studio. (I don't have visual >> studio to test.) To me it looks like a straightforward c++ issue. >> Either visual studio is doing something non-standard (wrong), >> of I've missed a different typedef hidden somewhere in an >> #ifdef somewhere in the windows branch of the code. (But, if >> so, it would be a typedef that mingw-w64 isn't picking up on.) >> >> So I think "&func" is an error. But I am also puzzled, because >> it compiles with visual studio, which doesn't make sense to me. >> >> > Djalma >> >> Thanks for your help. >> >> K. Frank >> ... |