Ideally would have someone build it and walk me through it, or if prohibitive, maybe guide me through the process. From IB's tutorial, it looks like first steps would be to 1) download TWS 2) download API 3) presumably work with their API's samples. Open questions: how to implement your own analysis/functions in that environment. For example, right now my data structure reads in price history from a text file and grows as I do a number of function calls in my main. How does one transpose/integrate that to the sample file? etc Did you do any of this from scratch yourself?
So you need to write code that downloads the price history data via the API from your broker of choice and places it in the text file. And then have your strategy use that text file. The exact steps will likely differ from broker to broker.
First decide if you want to build something within existing platform or you want a standalone program.
Next make it easier on yourself and forget about IB for now ... Find a more user friendly API. For Futures I would recommend Rithmic (or TT). Write a program to receive market data, normalize it and feed to your strategy module/program. Write a module/program to receive generic orders from your strategy module and convert them to API specific orders to be sent. Once you have all that simply replace original API with IB api ... Voila! Don't build system specific to any API/broker so that you can easily switch without rewriting your strategies!
With some quick searching I found this project on GitHub. I have no idea if will suit your needs but it is written in C++ and has an IB connector. https://github.com/EliteQuant/EliteQuant_Cpp
It's unclear if you're asking for the sort of answers you've received or guidance on implementation. Since I feel the latter is more fun to write about you should: 1. Remember the SOLID principles here, particularly Dependency Inversion. You want your classes to be loosely coupled to the extent possible, and when classes must depend on each other they should do so via an interface. Why do you want to do this? So you backtest against the same API you face in live trading. How do you do this? Extract the common features of both APIs into an interface. Write adapter classes that implement the interface and wrap the functionality in whatever underlying APIs you applications consume. 2. I don’t know your background and this may sound rude, but remember I’m here to help and entertain myself talking about software dev: I really question the necessity of C++ here. I think java or C# might make more sense. If you do it in C++ there’s more boilerplate. Boilerplate isn’t just extra typing and time on stackoverflow. At the stage you’re at it will result in substantial extra work because you’re several iterations away from actually getting this done. You’re shooting yourself in the foot by doing all this “exploratory” work in C++. Also, earlier it sounded like you were wrestling with understanding how a trading API with sockets, etc. works. I recall in undergrad I got my hands on a “real” API for the first time only to realize I spent a bunch of money to be in over my head. A a year of doing this professionally later I understand the applied aspects of the (async) observer pattern much better and use features such as Java 8’s CompletableFuture to make the complexity of dealing with an async streaming API easy, but that year and change was a long road and I put in a lot of work. This wasn’t like some lost little kid watching YouTube videos, I was probably what most people would consider a highly recruited (albeit junior) engineer at this time and it took a good effort to figure it out. Don’t think you’ll figure this out overnight. Don’t multiply the number of nights, frustration, time paying for an API you don’t use by n because you heard XR trading was sponsoring CPPCON 2019. One of the biggest keys to productivity as a software engineer in my admittedly limited experience is being able to iterate new ideas quickly. That’s not C++. Maybe you already have professional experience in C++, but I did not get that sense from your replies, so apologies if I’m shooting you down or something. 3. Once you get hooked up to a live trading API you’ll want to toss whatever you’re backtesting against and leverage the data you could’ve actually actioned historically for testing. You may think this is some purist’s opinion, but dev and PROD will be different: prepare yourself to deal with this gracefully by writing the code to persist and replay the incoming market data BEFORE you start paying for it.