Converting TickZOOM Engine to C++? Support C++,Java,& C#?

Yes the custom code can still be in C# -- no difference. I have figured out how to make it "seamless" so there's no difference in how your strategies, etc will work with the engine itself in C++ instead of C#.

Does that answer your question?

None. It will be even faster that before. The reason is that the calls between C# and C++ are only slowed down by marshaling data heap data. So it should be seamless and fast.

What does POV mean?

Sincerely,
Wayne

 

If I stick with Metatrader I'll have to figure out a way to get those live ticks into the TickQueue. I'll burn that bridge when I get to it.

I believe that POV == point of view.

- Andrew.

 

So if I understand you right - all the calls from the engine to the custom code are parameterless and all the data access from the custom code to the data structured maintained by the engine ( like tick/bars and others ) are also unsafe.

Point of View.

 

I've seen a lot of projects in 30+ years of work in engineering, a lot of projects. Spending a lot of time in the design phase is much better than jumping in and building something. Once the designing is really done, the building part becomes much easier, it just flows in fact.

 

I would agree with that - makes perfect sense. However, the OP already agreed with a post of mine in a different thread whereby I warned of the dangers of feature creep and the need to avoid analysis paralysis.

 

Almost. At least in C# (maybe not Java) you can pass a structure by value. So there's no need to "marshall" it to the GC. (Sorry if getting too technical.)

So to be more precise, all the methods from the engine to the custom code are either parameterless like Initialize() or have one parameter.

Here's an example:

The engine will call custom code with (if you implement this method)

IntervalOpen()

This one means the default interval for the specific model. That way you can have EasyLanguage like code which works on any interval you configure.

And the engine also calls (if you implement this method)...

IntervalOpen(Interval interval)

The engine calls this one for every interval that the model requested in the Initialize() method.

So in this version of method you can do this:

if( interval == Intervals.Hour1) {

}

if( interval == Intervals.Second10) {

}

So again, all methods are either parameterless or have one parameter, the interval.

There's also IntervalClose(), StartHistorical() EndHistorical() etc.

Most are just events.

Unsafe, why? They will be available through the COM interface and in this case all the data is returned as ints. So they are based by value on the stack.

That means they are inherently "safe" if you're refering to C# "unsafe" concept or thread safety.

In other words, when you call Data.Hours.Open[5] it will call the Bars object in C++ and return an int which will be on the stack.

The same is true of Data.Hours.Time[5] or Data.Hours.EndTime[5] which return a TimeStamp struct which is only helper struct wrapping a double also on the stack.

Frankly, it will be seamless. So you won't have to worry about safety or threading.

Except, it will be unwise to use any static variable, singletons, etc in your custom code. But I can't think why that would ever be necessary. Member variables work fine.

Wayne

 

Thanks and I do agree. I stopped adding features almost 2 weeks ago and just cleaned up code and renamed stuff to make it more intuitive. I did some more thorough testing also.

Now, converting the engine to C++ won't add any features. For example, I won't add Java support before releasing.

And if you consider converting to C++ a feature creep problem then okay. I'll concede that.

Wayne

 

Interesting. Can metatrader call com objects?

Metatrader has an "engine" though for converting ticks to bars so it's unclear what use could come of running the TickZOOM engine in your strategies for MetaTrader. Interesting.

Wayne

 

To clarify, this isn't "only a utility" the utility just converts things like C# . to :: -> and . in C++ and it's accurate about 90% of the time.

That little issue could be very time consuming for me as a human to do.

Also, it's converting all properties to getters and setters.

In other words, it's saving an ENORMOUS amount of typing.

But it still forces me to review every line of code, also it throws in TODO comments anywhere it's unsure how to translate, etc.

Point is, it allows me to focus my energy on the parts that truly require human intervention. But eliminate the mindless grunt work.

Well, I respect that. I have often been qualified as "fearless". That has pros and cons, of course.

Guess what. The C# project is pristine and untouched throughout. That means I can "pull the plug" on the C++ conversion and release the original C# version if necessary.

Trust me, I won't let this drag on weeks before releasing. I don't want it to become vaporware. I'll fall back on C# in a pinch.

Certainly. That's true. There are always unknowns. So I'm open to pulling the plug.

Understood.

 

I strongly recommend against C++ if you already know Java. I'm very excited personally by having this engine accessible to Java. As that's my preferred language. There's so many gotchas in C++ that can be a BEAR to debug if you don't know what you're doing with serious experience behind you.

Java on the other hand is dream with garbage collection, elimination of the header file morass, etc. etc.

For sure, I'm going to write my personal strategies with Java after I or somebody else makes TickZOOM compatible charts. It should only take a few days to convert the TickzOOM C# Chart to use JFreeChart.

Well, I certainly want it accessible to techies, that's part of my commitment to open source. But it needs to be accessible to non-techies to survive as a project in the long term.

Sincerely,
Wayne