Home >> Support Board

Support Board

Date/Time: Thu, 25 Apr 2024 07:00:19 +0000

How to Post a Message for Support

Post From: DTC Protocol

[2016-01-19 11:12:18] Link To Thread - Link To Post [Go To First Post]
paska.houso - Posts: 7
Dear SierraChart Team, I had a look at your application and had a project in my backlog to implement a DTC Server in Python. With the advent of 2016 I have started that and rather than hand-coding everything and risking falling behind potential changes, I have written a small C++ Header Parser (specifically suited for the DTCProtocol.h). The syntax allows that and with an "almost" automatic translation to Python. I have only come to 3 corner cases, 2 of which you may possibly and easily iron out. Here my feedback (C++ Fixed Length Strings) 1. Some of the "structs" define a "Clear" method which is invoked from the constructor. This should either be the standard for ALL structs or not be present in anyone. Consistency is key. The "Clear" method does not only clear standard "operating" values of the "struct" but also things like the "Size" and "Type" fields, which can be seen as an integral part of each instance. I would personally opt for having a Clear Method for each and every struct. 2. Two of the structs feature a "SetToUnsetValues" method which is doing more or less (it doesn't touch Size/Type) than Clear. The most annoying thing about this method is that unlike "Clear" ... it is not defined in the header file but rather in the "cpp" part. If "Clear" breaks consistency, this "SetToUnsetValues" goes a step beyond. In this case you could put the functionality of "SetToUnsetValues" into a "Clear" method in the header and then have the "SetToUnsetValues" call "Clear" (for backwards compatibility) Structs with this method: s_MarketDataSnapshot (call to it missing in the constructor) and s_MarketDataSnapshot_Int 3. Nested "struct" by having 2 arrays of s_DepthEntry structs as members of s_MarketDepthFullUpdate20 and s_MarketDepthFullUpdate10. Although for a regular API this is no issue, for an over-the-wire transmission it is not. It is not because these two do not resist the comparison with all other structs which are made up of simple types. Encoding/Decoding over-the-wire packets may be as simple as doing a "memcpy" in C/C++, but this adds an unneeded burden on Dynamic Languages in which the exact representation of double and floats (for example Python) is not simply a set of bytes, but rather and object. Of course it can be overcome and given these 2 structs are already well defined, there is no easy way out. But let me suggest that future structures should avoid declaring composite types. In any case and as soon as I am reasonable satisfied with my development, it will be available on GitHub. Best regards P.S. Having your files and documents on GitHub would also be a good idea to allow people to propose changes/corrections/improvements via Pull Requests (GitHub is just a suggestion, many other sites fare also as good)