One’s view of this of Microsoft .NET CLR managed vs unmanaged Visual C++ code for a trader
Glad you found a way to wrap unmanaged code dlls for dot net clients.
That will give you a good market for getting new members of your group, I think.
The biggest barrier to an analyst or trader these days is that proprietary vendors create barriers to lock their customers into their proprietary solutions, and then bit by bit feed out upgrades for revenue to solve problems of keeping up with all the competitors. That applies generally to many fields of technology which are enabled using computer simulation and design.
So a barrier busting business model will find a growing market. Traders and analysts are hungry for barrier busting because of the notorious shroud of secrecy surrounding the idea of Trader’s EDGE.
What is so great about Multicharts, as you saw, is the potential it has for being a “front end” engine for interfacing analysis “backends” with analysts and traders alike. Maybe it is not HFT platform, but it has backend simulation capabilities, and if you can connect Matlab analytics to any front end at all which traders have already learned how to use, and there is a migration path for using the same code to build the FPGA hardware/firmware which hooks up to the traders’ platforms of their choice( they all copy the old Omega Research, TradeStation, Multicharts EasyLanguage lineage standard formats),you have defined your market quite closely.
So I do not think you have to worry too much about MC dot net. It will take some time before it becomes adopted widely enough to create your market. TradeStation and Multicharts and Ninjatrader all have thousands of already built commercial frontend users ready to use your C, or even C++ coded DLLs generated from your Matlab/Cuda/FPGA/ etc.,etc, development and testing backend(s)integration with graphical and trading simulator front ends solution.
Dot net is frowned on by those developers afraid of others snooping into the code of their trade secret strategies. Straight C driven FPGA firmware for HFT keeps their secrets locked away very well, while the current front end platforms are only beginning to be adequate for running simulations and viewing the back test and strategy optimization graphics. Meanwhile, plain old Multicharts is right up front of the startup prototyper/execution testing (and even retail quantity buy side trading) platform pack in terms of jump-starting wanna-be as well as many current proprietary trading strategy developers.
Real minimum latency algorithmic HFT deployment is yet another upgrade stage, once performance metrics of the prototypes are considered probably worth the effort of further investment in state of the art competitive hardware and co-located data feeds.
Right now, the state of the art in simulation does not fare well in telling you what the difference will be between your simulation results with historical data and real time ordering/fill results. How would the Matlab toolbox software be programmed, for example, so it is able to decide whether to use market orders or stop/limit orders, time based bars or range-quantized bars based on the full order versus partial order fill price sequence execution feedback loop from the exchange? The platforms (front ends) can gather the information and display it, but the programming effort is still frustrating, to say the least.
But I am very glad you like the idea of using “unmanaged C” or C++ for the backend coding interface.
Dot net might help with the integration for prototyping, or even deployment of slower than HFT as well.
It is people like this who respect what I am trying to do with this thing. This surprise of managed vs unmanaged C++ CLR code threw me off. I have got a better handle of it now. I am just some dude who worked with Java for many years but that platform has it unique challenges as well. Personally, I am digging .NET development despite its limitations within Windows. I am just more productive and I am getting closer to finish line. I keep saying that but I think I would still a be lot of farther away if I stuck it out with Unix or Linux.NOTE I now post my TRADING ALERTS into my personal FACEBOOK ACCOUNT and TWITTER. Don't worry as I don't post stupid cat videos or what I eat!
Just posted working source code for C# .NET client to call C++ managed wrapper DLL to call unmanaged C++ static library
I have found a really good online resource to accomplish. There was even a comment from someone where they worked on this solution for over a week. Wow! This is why you should join the QuantLabs.net Premiium Membership now to save yourself this amount of time. Not only that, it prevents you going down rabbit holes like my recent venture with Multicharts.net. Bleh.
Anyhow, I have created a Static Library which is native C++ unmanaged code. Then you need to write a C++ managed wrapper DLL to call the static library. After that, you want a C# client to call the managed C++ DLL. Get it?
I placed working code of this for my QuantLabs.net Premium Membership.
You may want to stand by to what I do with this.
Join now for it
or get my FREE newsletter what I plan to do with this.
Most ciritical note for those integrating Matlab with Microsoft .NET with C# or even Visual C++: Managed versus unmanaged code with a DLL
As I am trying to integrate both this open source .NET trading platform, this read me has strongly hinted at integrated Matlab with C#.
Who knew right? So ensure follow these instructions after all this time, you think you would have it right.
NOTE UPDATE: In the above link, pay attention to the comment of:
I have a function file in matlab and I created .Net assembly of it and used it in C# but it worked very slow there.
As a result, this method might be recommended.
NOTE I now post my TRADING ALERTS into my personal FACEBOOK ACCOUNT and TWITTER. Don't worry as I don't post stupid cat videos or what I eat!