quickfix-developers — QuickFIX developers forum

[Quickfix-developers] Content messages not counting as heartbeats ?

[Andrew C. <And...@Tw...>]

Does anyone remember a bug in which perhaps content messages did not count as HB in the QuickFix engine?

I have a (rate-feed) scenario in which upon logon I send off a boatload (technical term) of 35=R messages to start up a rate stream for different currency pairs and value dates when a session becomes active again - this seems to bring about a "socket connection reset by peer" message.

Restarting the service hosting QuickFix resolves the issue, but when it comes time for the session to restart again (daily sessions with a 30 min downtime) I get the same behavior.

This is an older version of the C++ implementation - just wondering if this sounds familiar to anyone and/or the latest version has fixed it.

Andrew Culross
TwoFour
10 Bank Street
White Plains, NY 10601
Direct +1 (914) 220-8849
Main   +1 (914) 220-8800
Fax      +1 (914) 220-8899
www.TwoFour.com<http://www.twofour.com/>
http://www.twofour.US.com/emaildisclaimer.aspx<http://www.twofour.us.com/emaildisclaimer.aspx>

[Quickfix-developers] Kenny Song

[Kenny S. <kso...@ya...>]

http://maxprints.net/kkdtwxas/3ekpo44qe1slua0g7f8b4.8c110u69vn


Kenny Song

[Quickfix-developers] Semi-OT: Minor request for the List Managers -- unsubscribe ghost user

[K. F. <kfr...@gm...>]

To the List Managers -

A minor request -- not urgent or important.

There is a defunct list subscriber, presumably "ia...@ar...".
Whenever I post a message I get a reply from his mail server:

   pos...@ar...
	
   6:42 AM (1 hour ago)
		
   to me
   Final-Recipient: rfc822;ia...@ar...
   Action: failed
   Status: 5.1.1

Hardly a big deal, but it someone has the appropriate access, it would be
helpful if he could unsubscribe the defunct user.

Thanks.


K. Frank

Re: [Quickfix-developers] Absence of Symbol in FIX44::NewOrderSingle constructor

[K. F. <kfr...@gm...>]

Hi Mike!

Thanks.  That's very informative, and clears up my questions.


K. Frank


On Sun, Feb 17, 2013 at 11:10 PM, Mike Gatny <mg...@co...> wrote:
>
> On Feb 17, 2013 4:27 PM, "K. Frank" <kfr...@gm...> wrote:
>> First, could someone give me a quick explanation about the difference
>> between a "field" and a "component"?  Is this something defined in FIX,
>> or is it a distinction specific to QuickFIX?
>
> FIX protocol distinction.  As far as the quickfix data dict is concerned,
> "component" is like "include".
> ...
>> where would I find the generator, and information on how to run the
>> upstream build process, i.e., the part that builds and runs the generator,
>> instead of just using its output?
>
> Just cd spec/ and run the generate script.  Then build as usual.

Re: [Quickfix-developers] Absence of Symbol in FIX44::NewOrderSingle constructor

[Mike G. <mg...@co...>]

On Feb 17, 2013 4:27 PM, "K. Frank" <kfr...@gm...> wrote:
> First, could someone give me a quick explanation about the difference
> between a "field" and a "component"?  Is this something defined in FIX,
> or is it a distinction specific to QuickFIX?

FIX protocol distinction.  As far as the quickfix data dict is concerned,
"component" is like "include".

> If it's a FIX concept, is it something new to FIX 4.4

Correct.

>
> My second question appear in line, below:
>
> On Fri, Feb 15, 2013 at 5:38 PM, Grant Birchmeier
> <gbi...@co...> wrote:
> > I think you nailed it.  The difference in the data dictionary is
> > causing the generator to generate the constructor slightly
> > differently.
>
> It's very interesting to me to hear that you use a code generator, that,
> I presume, reads the data dictionary.

Correct.

>
> Am I correct that the source bundle I downloaded, quickfix-1.13.3.zip
> (or the nearly identical linux version, quickfix-1.13.3.tar.gz) contains
> the output of the code generator, but not the generator itself?

Contains both the generated files and the generator.  See the spec/ dir.

> > I think your workaround is the correct way to go.  (To be honest, it's
> > probably the only way to go.)
>
> It seems very reasonable, if a little imperfect to use the two-step
> construct / set process.
>
> > Of course, if you want to try your hand at extending the generator to
> > include required component fields in ctors, I'm sure the patch will be
> > welcome :)
>
> I doubt I would have the strength for that, but if I wanted to look into
> it, where would I find the generator, and information on how to run the
> upstream build process, i.e., the part that builds and runs the generator,
> instead of just using its output?

Just cd spec/ and run the generate script.  Then build as usual.

Re: [Quickfix-developers] Absence of Symbol in FIX44::NewOrderSingle constructor

[K. F. <kfr...@gm...>]

Hello Grant!

Two follow-up questions

First, could someone give me a quick explanation about the difference
between a "field" and a "component"?  Is this something defined in FIX,
or is it a distinction specific to QuickFIX?

If it's a FIX concept, is it something new to FIX 4.4?

My second question appear in line, below:

On Fri, Feb 15, 2013 at 5:38 PM, Grant Birchmeier
<gbi...@co...> wrote:
> I think you nailed it.  The difference in the data dictionary is
> causing the generator to generate the constructor slightly
> differently.

It's very interesting to me to hear that you use a code generator, that,
I presume, reads the data dictionary.

Am I correct that the source bundle I downloaded, quickfix-1.13.3.zip
(or the nearly identical linux version, quickfix-1.13.3.tar.gz) contains
the output of the code generator, but not the generator itself?

> I think your workaround is the correct way to go.  (To be honest, it's
> probably the only way to go.)

It seems very reasonable, if a little imperfect to use the two-step
construct / set process.

> Of course, if you want to try your hand at extending the generator to
> include required component fields in ctors, I'm sure the patch will be
> welcome :)

I doubt I would have the strength for that, but if I wanted to look into
it, where would I find the generator, and information on how to run the
upstream build process, i.e., the part that builds and runs the generator,
instead of just using its output?

> -Grant

Thanks for helping explain what's going on.


K. Frank


> On Fri, Feb 15, 2013 at 4:15 PM, K. Frank <kfr...@gm...> wrote:
>>
>> Hello List!
>>
>> The constructor for FIX44::NewOrderSingle:
>>
>>     NewOrderSingle(
>>       const FIX::ClOrdID& aClOrdID,
>>       const FIX::Side& aSide,
>>       const FIX::TransactTime& aTransactTime,
>>       const FIX::OrdType& aOrdType )
>>
>> takes fewer arguments than that for FIX42::NewOrderSingle:
>>
>>     NewOrderSingle(
>>       const FIX::ClOrdID& aClOrdID,
>>       const FIX::HandlInst& aHandlInst,
>>       const FIX::Symbol& aSymbol,
>>       const FIX::Side& aSide,
>>       const FIX::TransactTime& aTransactTime,
>>       const FIX::OrdType& aOrdType )
>>
>> in particular, not including the Symbol, even though the instrument to
>> be traded is a required field.
>>
>> I'm guessing this has something to do with the FIX 4.2 required field:
>>
>>    <field name='Symbol' required='Y' />
>>
>> being replaced with the FIX 4.4 required component:
>>
>>    <component name='Instrument' required='Y' />
>>
>> I have two questions:
>>
>> First, what is going on here?
>>
>> Second, what is the "right" way to construct a FIX44::NewOrderSingle?
>>
>> I have been calling the shorter constructor:
>>
>>   FIX44::NewOrderSingle order (/* doesn't include Symbol */ );
>>   order.set (FIX::Symbol (mySymbol));
>>
>> This works, but it seems like I am mixing styles, using both a
>> constructor and setters.
>>
>> Is this construct / set approach the cleanest way to go?
>>
>> (The same issue applies to other messages, but NewOrderSingle
>> is a typical example.)
>>
>> Thanks for any insight.
>>
>> K. Frank

Re: [Quickfix-developers] Absence of Symbol in FIX44::NewOrderSingle constructor

[Grant B. <gbi...@co...>]

I think you nailed it.  The difference in the data dictionary is
causing the generator to generate the constructor slightly
differently.

I think your workaround is the correct way to go.  (To be honest, it's
probably the only way to go.)

Of course, if you want to try your hand at extending the generator to
include required component fields in ctors, I'm sure the patch will be
welcome :)

-Grant


On Fri, Feb 15, 2013 at 4:15 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
>
> Hello List!
>
> The constructor for FIX44::NewOrderSingle:
>
>     NewOrderSingle(
>       const FIX::ClOrdID& aClOrdID,
>       const FIX::Side& aSide,
>       const FIX::TransactTime& aTransactTime,
>       const FIX::OrdType& aOrdType )
>
> takes fewer arguments than that for FIX42::NewOrderSingle:
>
>     NewOrderSingle(
>       const FIX::ClOrdID& aClOrdID,
>       const FIX::HandlInst& aHandlInst,
>       const FIX::Symbol& aSymbol,
>       const FIX::Side& aSide,
>       const FIX::TransactTime& aTransactTime,
>       const FIX::OrdType& aOrdType )
>
> in particular, not including the Symbol, even though the instrument to
> be traded is a required field.
>
> I'm guessing this has something to do with the FIX 4.2 required field:
>
>    <field name='Symbol' required='Y' />
>
> being replaced with the FIX 4.4 required component:
>
>    <component name='Instrument' required='Y' />
>
> I have two questions:
>
> First, what is going on here?
>
> Second, what is the "right" way to construct a FIX44::NewOrderSingle?
>
> I have been calling the shorter constructor:
>
>   FIX44::NewOrderSingle order (/* doesn't include Symbol */ );
>   order.set (FIX::Symbol (mySymbol));
>
> This works, but it seems like I am mixing styles, using both a
> constructor and setters.
>
> Is this construct / set approach the cleanest way to go?
>
> (The same issue applies to other messages, but NewOrderSingle
> is a typical example.)
>
> Thanks for any insight.
>
>
> K. Frank
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers



-- 
Grant Birchmeier
Connamara Systems, LLC
Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.
http://connamara.com

[Quickfix-developers] Absence of Symbol in FIX44::NewOrderSingle constructor

[K. F. <kfr...@gm...>]

Hello List!

The constructor for FIX44::NewOrderSingle:

    NewOrderSingle(
      const FIX::ClOrdID& aClOrdID,
      const FIX::Side& aSide,
      const FIX::TransactTime& aTransactTime,
      const FIX::OrdType& aOrdType )

takes fewer arguments than that for FIX42::NewOrderSingle:

    NewOrderSingle(
      const FIX::ClOrdID& aClOrdID,
      const FIX::HandlInst& aHandlInst,
      const FIX::Symbol& aSymbol,
      const FIX::Side& aSide,
      const FIX::TransactTime& aTransactTime,
      const FIX::OrdType& aOrdType )

in particular, not including the Symbol, even though the instrument to
be traded is a required field.

I'm guessing this has something to do with the FIX 4.2 required field:

   <field name='Symbol' required='Y' />

being replaced with the FIX 4.4 required component:

   <component name='Instrument' required='Y' />

I have two questions:

First, what is going on here?

Second, what is the "right" way to construct a FIX44::NewOrderSingle?

I have been calling the shorter constructor:

  FIX44::NewOrderSingle order (/* doesn't include Symbol */ );
  order.set (FIX::Symbol (mySymbol));

This works, but it seems like I am mixing styles, using both a
constructor and setters.

Is this construct / set approach the cleanest way to go?

(The same issue applies to other messages, but NewOrderSingle
is a typical example.)

Thanks for any insight.


K. Frank

[Quickfix-developers] Access to the socket from within the application

[Alex G. <vro...@gm...>]

Hello Quickfix Developers,

Is there a way to access the loop that initiator/acceptor runs from inside
the quickfix application? Basically, I need it to be able to perform
operations at a predefined time intervals without blocking.

For example, i want to send a Market Data request every 30 seconds. My
first thought was to set my Heartbeat interval at 30 seconds and tie my
data request to it. However, heartbeats are sent only when there is no
activity, so if my application is sending and receiving messages all the
time, it's possible I won't get any heartbeats for much longer than 30
seconds.

Is there a neat way around this issue?

Thank you,
Alex

Re: [Quickfix-developers] What thread or threads are involved when FIX::Session::sendToTarget is called?

[K. F. <kfr...@gm...>]

Hi Hei!

Thank you for the answer.

On Tue, Feb 5, 2013 at 10:53 PM, Hei Chan <str...@ya...> wrote:
> If you use ThreadSocketInitiator, the caller's thread will be used all the
> way till send() returns.
> Otherwise, your message will be handed off to another thread.

Would you happen to know if the same is true on the acceptor side?
(I.e., SocketAcceptor --> caller's thread, ThreadedSocketAcceptor
--> handed off to another thread?)

> ...
> From: K. Frank <kfr...@gm...>
> To: Quickfix Developers List <qui...@li...>
> ...
> Hello List!
>
> When the static member function FIX::Session::sendToTarget is called,
> does the calling thread execute the entire send procedure synchronously,
> all the way down to a socket write?  Or does the processing get handed
> off to some other thread (such as the SocketAcceptor thread) to do most
> of the work.
>
> On a related note, I was trying to trace though the code, but I got
> confused:
> It looks to me like Session::send calls Session::sendRaw, but that
> Session::sendRaw calls Session::send.  I must have missed a code
> branch somewhere, but I couldn't figure out where send drills down to
> actually pumping stuff over the wire.  Could someone explain what is
> going on here?
>
> Thanks.
>
> K. Frank

Re: [Quickfix-developers] What thread or threads are involved when FIX::Session::sendToTarget is called?

[Hei C. <str...@ya...>]

If you use ThreadSocketInitiator, the caller's thread will be used all the way till send() returns.
Otherwise, your message will be handed off to another thread.


________________________________
 From: K. Frank <kfr...@gm...>
To: Quickfix Developers List <qui...@li...> 
Sent: Tuesday, February 5, 2013 5:52 PM
Subject: [Quickfix-developers] What thread or threads are involved when FIX::Session::sendToTarget is called?
 
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Hello List!

When the static member function FIX::Session::sendToTarget is called,
does the calling thread execute the entire send procedure synchronously,
all the way down to a socket write?  Or does the processing get handed
off to some other thread (such as the SocketAcceptor thread) to do most
of the work.

On a related note, I was trying to trace though the code, but I got confused:
It looks to me like Session::send calls Session::sendRaw, but that
Session::sendRaw calls Session::send.  I must have missed a code
branch somewhere, but I couldn't figure out where send drills down to
actually pumping stuff over the wire.  Could someone explain what is
going on here?

Thanks.


K. Frank

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] What thread or threads are involved when FIX::Session::sendToTarget is called?

[K. F. <kfr...@gm...>]

Hello List!

When the static member function FIX::Session::sendToTarget is called,
does the calling thread execute the entire send procedure synchronously,
all the way down to a socket write?  Or does the processing get handed
off to some other thread (such as the SocketAcceptor thread) to do most
of the work.

On a related note, I was trying to trace though the code, but I got confused:
It looks to me like Session::send calls Session::sendRaw, but that
Session::sendRaw calls Session::send.  I must have missed a code
branch somewhere, but I couldn't figure out where send drills down to
actually pumping stuff over the wire.  Could someone explain what is
going on here?

Thanks.


K. Frank

Re: [Quickfix-developers] QuickFIX's threading model and multiplexing other sources of events

[K. F. <kfr...@gm...>]

Hello Mike!

On Fri, Feb 1, 2013 at 3:22 PM, Mike Gatny <mg...@co...> wrote:
> On Fri, Feb 1, 2013 at 7:58 AM, K. Frank <kfr...@gm...> wrote:
>>
>> I've built a little test app (that appears to work) that is based closely
>> on the ordermatch example.
>
> What if you use the actual ordermatch example instead, and connect the
> tradeclient to it?  Do you see the same behavior?

That's a fair question.  I will take a look at that when I get the chance.

>> So I don't understand the thread count.  If I follow what you are saying,
>> I would expect two threads: one for the main thread (the while loop
>> that reads the console) and one for the SocketAcceptor.
>
> For ordermatch on linux, you will definitely see only two threads: a thread
> blocked on a socket select() and a thread blocked on a stdin read() (easy to
> confirm with gdb "info threads").

And that's a fair answer.  I don't have a linux system at the moment,
but I will take your word for it.

> I have to assume that the extra threads
> are some kind of behind-the-scenes Windows behavior.

Then something is odd.  I'm not aware of any behind-the-scenes
threads created by windows with ordinary win32 code.  I'm quite
certain that win32 threads don't sneak off and spawn extra
threads.  I don't really know about winsock, but since winsock
(and, of course, sockets in general) date back the the
predominantly single-threaded days, I would also be surprised
if the socket stuff were directly responsible for the "extra" threads.

> Whatever it is, the
> observable situation on linux is the same one you can use as your conceptual
> model for SocketAcceptor: For messages you receive, one thread (owned by
> quickfix) will deliver all messages for all Sessions to your Application
> callbacks.  For messages that you send, whatever thread you call
> sendToTarget() from will be used.  The sendToTarget() method is
> synchronized, so you can call from wherever you like.

Thank you for the further clarification.

Coming back to my original question about design:

Would it make sense then to have a centralized event queue,
serviced, for example, by the main thread, that has a
synchronized pushQueue method that gets called by the
FIX Application callbacks?  (And similarly, a price-feed thread
might also use pushQueue to push price-feed events onto
the centralized queue.)

I'm imagining that that would be something of a standard
design for a QuickFIX application that needs to process a
variety of events, other than just FIX events.

But please let me know if people have found this kind of
design troublesome, and what some better alternatives
might be.

> Mike Gatny
> Connamara Systems, LLC

I appreciate your explanations.


K. Frank

[Quickfix-developers] Custom DataDictionary ignored in QF Python API

[Alex G. <vro...@gm...>]

Hello Folks!

I'm using quickfix for Python and it seems that quickfix ignores the custom
dictionary that I pass to my session via config file. So my questions are:

1. Is it possible that custom DataDictionary is not implemented in Python
API at all? (I have suspicion that field definitions are simply hardcoded
at the end of /usr/lib/python2.7/site-packages/quickfix.py (line 34366 and
below))
2. Is there a way to verify that my custom dictionary is actually being
used?
3. Is there a way to set the custom dictionary programmaticaly rather than
via config file?

Thanks,
Alex

Re: [Quickfix-developers] QuickFIX's threading model and multiplexing other sources of events

[K. F. <kfr...@gm...>]

Hi Mike!

Thanks for the explanation.

On Fri, Feb 1, 2013 at 8:26 AM, Mike Gatny <mg...@co...> wrote:
> If using SocketAcceptor/Initiator, QF will process messages for all Sessions
> on a single thread.  QF starts this thread, and all callbacks (e.g. fromApp)
> occur on it.

Thank you.  That answers my main question.

> Return from callbacks as soon as possible to prevent backing
> up QF's queue of incoming msgs.  Copy messages to your own work/event queue
> if necessary.

Yes, that makes good sense.

> ThreadedSocketAcceptor/Initiator use one thread per Session.  This can
> increase throughput if 1) you have multiple sessions and 2) you don't share
> (much) data between them.

I have a follow-up question:

I've built a little test app (that appears to work) that is based closely
on the ordermatch example.  When I launch it, windows task manager
shows it starting out with three threads, then, after half a minute, going
up to six threads, and then after an additional minute-plus, settling
back down to three threads.

I haven't drilled down into the code to see what is happening, but I
do note the I am using SocketAcceptor, as does ordermatch (rather
than ThreadedSocketAcceptor).  (Both the ordermatch example and
my test app are acceptors.)  I have my test app configured for two
sessions.

So I don't understand the thread count.  If I follow what you are saying,
I would expect two threads: one for the main thread (the while loop
that reads the console) and one for the SocketAcceptor.

I suppose if I were using ThreadedSocketAcceptor, I would expect
three threads: one main thread, and two more, one for each of my
two sessions.

But I certainly don't understand why the thread count goes up and
back down again.

Any further insight would be appreciated.


Best regards.


K. Frank

Re: [Quickfix-developers] QuickFIX's threading model and multiplexing other sources of events

[Hei C. <str...@ya...>]

There are ThreadedSocket* vs Socket* classes.
The latter has a queue for sending messages (for initiators) or a queue for receiving messages.


________________________________
 From: K. Frank <kfr...@gm...>
To: Quickfix Developers List <qui...@li...> 
Sent: Thursday, January 31, 2013 7:02 PM
Subject: [Quickfix-developers] QuickFIX's threading model and multiplexing other sources of events
 
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Hello List!

What is QuickFIX's conceptual threading model?

In realistic applications it is often necessary to "multiplex" several
different sources of events" command-line input from a console,
mouse and keyboard events from a gui, commands coming in
over a proprietary socket connect, market data, and of course,
FIX message traffic.

What's the QuickFIX-approved way of handling this kind of common
challenge?

What guarantees does QuickFIX make about which thread or threads
will call the various callbacks (e.g., fromApp or onMessage)?

Are there some standard design approaches that people have found
work well and fit the "QuickFIX way" of doing things?


Thanks.


K. Frank

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] QuickFIX's threading model and multiplexing other sources of events

[K. F. <kfr...@gm...>]

Hello List!

What is QuickFIX's conceptual threading model?

In realistic applications it is often necessary to "multiplex" several
different sources of events" command-line input from a console,
mouse and keyboard events from a gui, commands coming in
over a proprietary socket connect, market data, and of course,
FIX message traffic.

What's the QuickFIX-approved way of handling this kind of common
challenge?

What guarantees does QuickFIX make about which thread or threads
will call the various callbacks (e.g., fromApp or onMessage)?

Are there some standard design approaches that people have found
work well and fit the "QuickFIX way" of doing things?


Thanks.


K. Frank

[Quickfix-developers] [Mingw-w64-public] QuickFIX using mingw-w64

[K. F. <kfr...@gm...>]

Hello Lists!

It looks like I've managed to port QuickFIX to mingw-w64.

I haven't run the unit tests (because I didn't have the energy to port
UnitTest++), and I haven't run the acceptance tests (because I didn't
want to deal with the ruby dependency), but I have built a relatively
simple QuickFIX application using my ported library.

Its socket connections work, it runs multiple threads, and it parses
its xml data dictionaries, so the three most platform-dependent pieces
of the system seem, at least on the surface, to be working.

I ended up going with libxml2 (because mingw-w64's msmxl2 seemed
to have some bugs, and, in any event, QuickFIX lists MSXML3 as its
dependency).  I used the pre-built mingw-w64 libxml2 from:

   http://www.stats.ox.ac.uk/pub/Rtools/R215x.html

that Prof Brian Ripley suggested in an earlier thread.  I had had
some concern that a version mismatch between the compiler
used to build libxml2 and the version I'm using might cause an
incompatibility, but then I recalled that libxml2 is a c library, rather
than c++ where such abi breakage would have been more likely.

Most of the porting work involved selectively changing various
#ifdef's dependent on _MSC_VER (not defined by mingw-w64)
to use _WIN32 instead.  There were some minor fixes to
microsoft stuff and a little bit of 64-bit tweakage.

As I said, I don't have any reason to expect my current version
to be bug free, but the basic functionality is there, and I haven't
seen anything break yet.

Thanks for folks suggestions that helped get me going.


Best regards.


K. Frank

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

[Djalma R. d. S. F. <drs...@gm...>]

On Tue, Jan 22, 2013 at 4:38 PM, K. Frank <kfr...@gm...> wrote:

> "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 '&'.
>

Well, I think you are correct here. Indeed, if you get the function pointer
declaration in utility.h it is missing the expected * just after _stdcall,
but the compiler does not care.

#ifdef _MSC_VER
typedef unsigned int (_stdcall THREAD_START_ROUTINE)(void *);

After fixing the declaration,

typedef unsigned int (_stdcall *THREAD_START_ROUTINE)(void *);

and trying to use &func the compiler starts to complain as expected,
although with a weired error message.

1>.\Utility.cpp(517) : error C2664: '_beginthreadex' : cannot convert
parameter 3 from 'FIX::THREAD_START_ROUTINE *' to 'unsigned int (__cdecl
*)(void *)'

I believe that for some kind of magic behind the scenes (that I
definitively would not dare to try to explain), everything works fine and
the compiler currently generates the correct code for Windows platform.

It is really very confusing issue.

Unfortunately I don't have VC11/VC12 at the momento to check whether this
is something that was fixed in newer versions of Microsoft compiler.

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

[K. F. <kfr...@gm...>]

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

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

[Djalma R. d. S. F. <drs...@gm...>]

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
>

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

[K. F. <kfr...@gm...>]

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

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

[Djalma R. d. S. F. <drs...@gm...>]

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.

http://www.mingw.org/wiki/C99

If so, you are right, an #ifdef for mingw would fix it.

But, why don't you try Visual Studio Express for free?


On Thu, Jan 17, 2013 at 11:16 AM, K. Frank <kfr...@gm...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> 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
>
>
> > On Tue, Jan 15, 2013 at 8:05 PM, K. Frank <kfr...@gm...> wrote:
> >>
> >> Hi Mike!
> >>
> >> On Tue, Jan 15, 2013 at 1:10 PM, Mike Gatny <mg...@co...>
> wrote:
> >> > It works with the VS compiler (32-bit, anyway).  Can you post the
> actual
> >> > error message that mingw-w64 is giving you?
> >>
> >> Yes, I'd be happy to post the mingw-w64 error message.
> >>
> >> But before I do, I would like to check whether the code looks to you
> >> like it has an error, or whether I'm missing something simple about
> >> relatively basic c++.  (Again the issue is that I see a
> >> pointer-to-pointer-to-function (double pointer) being passed, while a
> >> pointer-to-function (single pointer) is expected.)  Does this look
> >> like an error to you?
> >>
> >> Anyway, here's the mingw-w64 error message:
> >>
> >>    Utility.cpp: In function 'bool FIX::thread_spawn(unsigned int
> >> (*)(void*), void*, FIX::thread_id&)':
> >>    Utility.cpp:510:56: error: cannot convert 'unsigned int
> >> (**)(void*)' to 'unsigned int (*)(void*)' for argument '3' to
> >> 'uintptr_t _beginthreadex(void*, unsigned int, unsigned int
> >> (*)(void*), void*, unsigned int, unsigned int*)'
> >>
> >> In a way, I'm not surprised that you don't see the issue with visual
> >> studio, because if you did, you would have changed the code.  So
> >> I wonder whether visual studio might be doing something wrong or
> >> non-standard here.  (I'm not aware of anything, but I'm not that
> >> expert with visual studio.)  Or maybe g++ / mingw-w64 is doing
> >> something non-standard.  But again, when I parse the code by
> >> eye, I come up with a type mismatch.
> >>
> >> (Just to note, the linux builds with g++ wouldn't have caught this
> >> because this is in the windows-specific part of the threading code.
> >> I verified -- at least to my eye -- that the analogous posix-threading
> >> part of the code doesn't have this issue.)
> >>
> >> By the way, if I "fix" the code by changing
> >>
> >>    result = _beginthreadex( NULL, 0, &func, var, 0, &id );
> >>
> >> to
> >>
> >>    result = _beginthreadex( NULL, 0, func, var, 0, &id );
> >>
> >> (that is, removing what appears to be the extra '&' from "&func")
> >> the code compiles under mingw-w64.  I don't know whether the
> >> code runs correctly because I haven't been able to compile all
> >> of the rest of the code.  But I would be worried about just making
> >> this change blindly because there is something going on that I
> >> don't understand.
> >>
> >> Thanks for helping me sort this out.
> >>
> >> 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
>

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

[K. F. <kfr...@gm...>]

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


> On Tue, Jan 15, 2013 at 8:05 PM, K. Frank <kfr...@gm...> wrote:
>>
>> Hi Mike!
>>
>> On Tue, Jan 15, 2013 at 1:10 PM, Mike Gatny <mg...@co...> wrote:
>> > It works with the VS compiler (32-bit, anyway).  Can you post the actual
>> > error message that mingw-w64 is giving you?
>>
>> Yes, I'd be happy to post the mingw-w64 error message.
>>
>> But before I do, I would like to check whether the code looks to you
>> like it has an error, or whether I'm missing something simple about
>> relatively basic c++.  (Again the issue is that I see a
>> pointer-to-pointer-to-function (double pointer) being passed, while a
>> pointer-to-function (single pointer) is expected.)  Does this look
>> like an error to you?
>>
>> Anyway, here's the mingw-w64 error message:
>>
>>    Utility.cpp: In function 'bool FIX::thread_spawn(unsigned int
>> (*)(void*), void*, FIX::thread_id&)':
>>    Utility.cpp:510:56: error: cannot convert 'unsigned int
>> (**)(void*)' to 'unsigned int (*)(void*)' for argument '3' to
>> 'uintptr_t _beginthreadex(void*, unsigned int, unsigned int
>> (*)(void*), void*, unsigned int, unsigned int*)'
>>
>> In a way, I'm not surprised that you don't see the issue with visual
>> studio, because if you did, you would have changed the code.  So
>> I wonder whether visual studio might be doing something wrong or
>> non-standard here.  (I'm not aware of anything, but I'm not that
>> expert with visual studio.)  Or maybe g++ / mingw-w64 is doing
>> something non-standard.  But again, when I parse the code by
>> eye, I come up with a type mismatch.
>>
>> (Just to note, the linux builds with g++ wouldn't have caught this
>> because this is in the windows-specific part of the threading code.
>> I verified -- at least to my eye -- that the analogous posix-threading
>> part of the code doesn't have this issue.)
>>
>> By the way, if I "fix" the code by changing
>>
>>    result = _beginthreadex( NULL, 0, &func, var, 0, &id );
>>
>> to
>>
>>    result = _beginthreadex( NULL, 0, func, var, 0, &id );
>>
>> (that is, removing what appears to be the extra '&' from "&func")
>> the code compiles under mingw-w64.  I don't know whether the
>> code runs correctly because I haven't been able to compile all
>> of the rest of the code.  But I would be worried about just making
>> this change blindly because there is something going on that I
>> don't understand.
>>
>> Thanks for helping me sort this out.
>>
>> K. Frank
>> ...

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

[Djalma R. d. S. F. <drs...@gm...>]

Hi Frank,

Is the name of the function the function pointer itself?
IMHO, this is just a matter of syntax and compiler implementation detail.
You might want to check the C99 spec and the compiler documentation.

Djalma


On Tue, Jan 15, 2013 at 8:05 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 Mike!
>
> On Tue, Jan 15, 2013 at 1:10 PM, Mike Gatny <mg...@co...> wrote:
> > It works with the VS compiler (32-bit, anyway).  Can you post the actual
> > error message that mingw-w64 is giving you?
>
> Yes, I'd be happy to post the mingw-w64 error message.
>
> But before I do, I would like to check whether the code looks to you
> like it has an error, or whether I'm missing something simple about
> relatively basic c++.  (Again the issue is that I see a
> pointer-to-pointer-to-function (double pointer) being passed, while a
> pointer-to-function (single pointer) is expected.)  Does this look
> like an error to you?
>
> Anyway, here's the mingw-w64 error message:
>
>    Utility.cpp: In function 'bool FIX::thread_spawn(unsigned int
> (*)(void*), void*, FIX::thread_id&)':
>    Utility.cpp:510:56: error: cannot convert 'unsigned int
> (**)(void*)' to 'unsigned int (*)(void*)' for argument '3' to
> 'uintptr_t _beginthreadex(void*, unsigned int, unsigned int
> (*)(void*), void*, unsigned int, unsigned int*)'
>
> In a way, I'm not surprised that you don't see the issue with visual
> studio, because if you did, you would have changed the code.  So
> I wonder whether visual studio might be doing something wrong or
> non-standard here.  (I'm not aware of anything, but I'm not that
> expert with visual studio.)  Or maybe g++ / mingw-w64 is doing
> something non-standard.  But again, when I parse the code by
> eye, I come up with a type mismatch.
>
> (Just to note, the linux builds with g++ wouldn't have caught this
> because this is in the windows-specific part of the threading code.
> I verified -- at least to my eye -- that the analogous posix-threading
> part of the code doesn't have this issue.)
>
> By the way, if I "fix" the code by changing
>
>    result = _beginthreadex( NULL, 0, &func, var, 0, &id );
>
> to
>
>    result = _beginthreadex( NULL, 0, func, var, 0, &id );
>
> (that is, removing what appears to be the extra '&' from "&func")
> the code compiles under mingw-w64.  I don't know whether the
> code runs correctly because I haven't been able to compile all
> of the rest of the code.  But I would be worried about just making
> this change blindly because there is something going on that I
> don't understand.
>
>
> Thanks for helping me sort this out.
>
>
> K. Frank
>
>
> ------------------------------------------------------------------------------
> Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
> and more. Get SQL Server skills now (including 2012) with LearnDevNow -
> 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only - learn more at:
> http://p.sf.net/sfu/learnmore_122512
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>