Sorry to clutter the Post but as it looks like issue is raised about old lib 10.11, hhereafter is a past of an internal memo about it.
?
ONLY of interest (aside of curiosity) to users using c++ language (while it may look like it’s could help Java user too)
AND API rev >= 10.11 and somewhere < 10.25 (earlier version may work but not checked, as the hereafter patch worked for 10.11 version, we jumped to 1.25 afterwards)
The IB lib work as expected in C# and most probably in Python (not tested)
And did work well in C++ with rev 9.xx
?
?
The internal Post:
?
?
?
?
FYI about 10.11
The IB lib work as expected in C# and most probably in Python (not tested)
And did work well in C++ with rev 9.xx
?
In EClient.cpp, ?the following method as delivered by IB, doesn’t work (at least for me, tell me if I am alone with that issue) and need a mandatory patch (from my perspective)
?
void EClient::placeOrder( OrderId id, const Contract& contract, const Order& order)
This method is very fundamental and have no alternative,
Environment:
VStudio 2019 c++ default compiler, however I have reason to believe that using gcc would raise same issue
?
The issue:
1- When upgrading the API to support Decimal, (API_Version>= 10.10.01), IB did introduce a new method to handle Encoding of Decimal when building the msg Message to local server.
?template<> void EClient::EncodeField<Decimal>(std::ostream& os, Decimal);
?
2- Decimal type is defined through a typedef unsigned long long Decimal;
However in EClient.cpp, the methode EClient::placeOrder while preparing it’s buffer does need run code: ENCODE_FIELD(order.conditions.size());
?
3-? As .size() deliver a size_t type which is also a unsigned __int64 (on X64) compiler see the same basic type than Decimal, because being define as typedef unsigned long long Decimal;
?
Consequence:
The compiler does call the ::EncodeField<Decimal>(std::ostream& os, Decimal); template to encode the order.conditions.size();
?
This is legitimate from compiler standpoint;
however, Decimal is NOT at all able to encode a size_t properly. In particular Decimal 0 is not at all delivering "0" in the stream but a crazy value.
Such messy message with a wrong size, are rejected by the server (and the connection brutally severed)
?
?
The workaround:
patch the IB code in EClient::placeOrder ?call with a cast (double) to force usage of another method un-equivocally, like:
ENCODE_FIELD((double)order.conditions.size());?
?
This force polymorphism to call the ‘double’ method instead of the 'Decimal'
And "voila" it works, as message size have no known reason to be bigger than 2GB and IEEE double is properly encoding int, this casting is safe enough.
?
?
=> Updated as of 10/19/2023 (maybe earlier):
In Lib like 10.25 IBKR seems to have done about the same thing but casting to a long
?????????? ENCODE_FIELD((long)order.conditions.size());
Which is safer because long is a better guaranty from compiler stand point to be an integer type.
So you better use 10.25 and discard 10.11
