Re: [Quickfix-developers] Confused by possible bug in Utility.cpp / thread_spawn

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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

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.

Indeed, it is very weird but for non-static member functions it would be
required.

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.

What is your opinion?

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

Djalma

On Thu, Jan 17, 2013 at 12:30 PM, K. Frank <kfr...@gm...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> 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
> >> ...
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>