代写C++ IOrderManager英文、代做IOrderManager C++程序、代写C++/C

日期：2018-06-29 07:32

Coding challenge (test for interviewees)

Create a solution for maintaining information about orders that are being placed on an exchange by an order router. This should derive from

IOrderManager (provided in challenge.h).

The in-house trading system tracks orders using a unique internal identifier (provided in challenge.h). The exchange tracks orders using a unique

text identifier.

Each order has a price and a quantity. Both are uint32_t. Prices and quantities must be positive numbers.

When an order request operation is received from a trader, the order manager must be able to store and retrieve information using the

OrderIdentifier.

When a response is received from the exchange the order manager must be able to retrieve the information using the text identifier.

The trader can perform the following requests. Each of these includes the OrderIdentifier but not the exchange's identifier:

Enter order. Includes OrderIdentifier, price and quantity but not exchange's identifier (this is provided when the exchange confirms the

order).

Cancel order. Only the OrderIdentifier is provided. The order is considered as still in the market until the exchange confirms the

cancellation.

The exchange can provide the following updates:

New order confirmed. Contains both the OrderIdentifier and the exchange's text identifier.

Order traded. Includes quantity traded and exchange's identifier.

Order cancelled. This can be due to the trader cancelling it, or the exchange cancelling the order. Contains only exchange's identifier.

If all the order quantity is traded then the order should be considered to be removed from the market and stops being active. An order can be

traded multiple times until all its quantity is used up.

The trader must not reuse a previously used order identifier, and they are only allowed cancel an order which is active in the market and which

they haven't already sent a cancel request for.

An order becomes active when the exchange confirms it, and stops being active when the exchange provides a cancel update on the order or a

trade update which uses all of the remaining quantity of the order.

Requests and updates have restrictions in the sequence in which they can occur for a specific order. Here A->B means that B can only occur after

A, if it occurs. There are no restrictions on sequencing between different orders.

Enter order -> New order confirmed

New order confirmed -> Order traded

New order confirmed -> Order cancelled

Order traded -> Order cancelled

You can assume the exchange never sends incorrect information, for instance a trade greater than the order quantity or a cancellation for an

order which doesn't exist.

Your order manager solution should handle requests from the trader and responses from the exchange in the form of methods being called in the

class you derive from IOrderManager. You are free to create other classes as part of the solution.

Please include explanatory comments describing why you chose to design each part of the solution in the way you did, plus a description of your

testing methods. If you discover ambiguities in the challenge, describe what assumptions you have made to allow you to continue.

Put all your files in an archive along with instructions how to build and run it.

challenge.h

#pragma once

#include <stdint.h>

#include <string>

// company's order identifier

struct OrderIdentifier {

OrderIdentifier() = default;

OrderIdentifier(uint16_t m, uint16_t d, uint16_t t, uint32_t s)

: _market(m)

, _desk(d)

, _trader(t)

, _sequence(s)

{}

uint16_t _market{0};

uint16_t _desk{0};

uint16_t _trader{0};

uint32_t _sequence{0}; // increments with each order from a particular

trader

};

//

// The order router will call these methods as it receives order operations

from the

// trader and exchange.

// Note:

// 1. Thread safety needs to be considered for your implementation of this

class: e.g.

// - OnTraderXXX may be called from different threads

// - You can assume OnExchangeXXX will only be called from a single

thread.

// - But OnTraderXXX and OnExchangeXXX maybe called from different

threads.

// 2. Performance, in terms of latency, of all the interface functions are

important.

//

class IOrderManager

{

public:

// trader operations - these return false if there is a problem

virtual bool OnTraderEnter(const OrderIdentifier& aInternal, uint32_t

aPrice, uint32_t aQuantity) = 0;

virtual bool OnTraderCancel(const OrderIdentifier& aInternal) = 0;

// exchange operations - these return false if there is a problem

virtual bool OnExchangeNew(const OrderIdentifier& aInternal, const

std::string& aExternal) = 0;

virtual bool OnExchangeTrade(const std::string& aExternal, uint32_t

aQuantity) = 0;

virtual bool OnExchangeCancel(const std::string& aExternal) = 0;

virtual bool IsOrderActive(const OrderIdentifier& aInternal) const = 0;

virtual bool IsOrderActive(const std::string& aExternal) const = 0;

// returns the quantity of the order that is active in the market, or

zero if the order isn't

// recognised or is not active

virtual uint32_t GetActiveOrderQuantity(const OrderIdentifier&

aInternal) const = 0;

};