There are many reasons not to use std::whatever but you have not made any case for that yet. In any case, if you use the iterator concept, I couldn't give care less about what containers you end up using. The problem is that this kind of premature optimization-based decision making will percolate through the API and that is what makes me sad. You clearly have passion for the project but it will be a mess because of this kind of decision making. If other people have been paying you to algo trade, they have way more money invested in making it fast. For retail traders, it's less relevant. Is your mother in law going to trade ticks? fuck no, that's a good way to bankruptcy.
Code: //->silly me :-))) xTime time1(replayStartTimeAsMicrosecondsSinceEpoch); renko1.replay("192.168.1.43:27017", time1, HTML5); // to replay xBars container on father in-law's MetaTrader 4 // for symbol EURUSD as UltimateRenko bar type in the browser as HTML5 charts // LOL
Code: // time1 will be current time now in microseconds since epoch xTime time1(xTimeNowMS()); xSleepMS(50000); // wait 50000 microseconds time1.add(xTimeNowMS()); // add another time now in micros print (time1.year(0)); //print first element print (time1.month(1)); //print second element print (time1.MS(1)); //print time1 @ pos 1 microsecond part // shift container to the left for 2 positions // container empty after the operation time1.shiftLeft(2); print(time1.overflow()); //print the last overflow after shifting 2 x left //send time1 container remotely to pops a with message attached time1.message("incoming time container pops", 192.168.1.43:27017); // Linkers::X->theNextBigThing; in C++ HFT Event Driven Algorithmic Trading
Code: # this code will compile and execute on MQL4, 5 NinjaScript, cAlgo, ACSIL SierraChart #include<LinkersX.mqh> struct spread1 { double spread; xString symbol; }; xSort<spread1> sorted1; xQueue<sorted1> sortedQueue; sorted1.add(spread1); // add spread to sorted list //autosort goes on during every insert sorted1.add(spread1); // add sanother spred1 struct to tlist sorted1.shiftRight(1); // shift right sort container sortedQueue.push(sorted1); // push sorted1 into the queue //sending the sorted queue container to nooby_mcnoob computer with Linkers:X installed // his SierraChart will do something with it... sortedQueue.message("192.168.1.43:27017"); // Linkers::X->andThatsIt;
Sure. C++ is ugly to begin with anyway, but I'll do my best: The idea is that instead of dealing with classes, you deal with concepts (interfaces in other languages). While interfaces are generally a runtime thing in other languages, concepts are compile-time things in C++. So when you're writing an algorithm to operate on a container, you can do it in one of two ways (in C++): Code: template<typename T> bool myalgo(std::vector<T> const & t); template <typename T> bool myalgo(xVector<T> const & t); Or: Code: template <typename ForwardIterator>bool myalgo(ForwardIterator begin, ForwardIterator end); And you would call it like this: Code: myalgo(myVector.begin(),myVector.end()) This is conceptually ugly and I would not recommend it for INTERNAL USE. However, when you're talking about exposing your API to the world like Linker is doing, then it is the only way. With C++ concepts, you can now do something like this (syntax is imaginary) Code: template <concept Container>bool myalgo(Container const & c); Which gives you the best of all worlds: 1. Compile-time checking 2. Generic code 3. Flexibility When concepts are available, I believe I will be using them very liberally so I hope they are as easy to write as classes.
Code: sortedQueue.addMongo(BSON); i just wrote container as BSON to MongoDB sortedQueue.addMongo(JSON); i just wrote container as JSON to MongoDB //write container as JSON as file to c://LinkersX/json.txt sortedQueue.file("c://LinkersX/json.txt", JSON); // of course BSON is excripted
This is exactly why I am sad your passion does not match your design skills. You can write a TON of code, and with the right guidance, you would be incredible.