Всем привет друзья.
пишу робота под америку и столкнулся вот с такой проблемой:
писал всегда на СИ подобном языке )) МКЛ это усеченный до нельзя СИ. и тем не менее все хорошо писалось..
сейчас же пишу под нинзю, а в нинзе си шарп. и вот с такой задачей уже долгое время не могу справиться:
как писал на МКЛ:
создаю структуру:
//--------------------------------------------------------------------------------------------
struct sDataBar { ... };
//--------------------------------------------------------------------------------------------
создаю 2 экземпляра стуктуры:
sDataBar OsnDataBar; // Структура с ДАННЫМИ на баре для основного ТФ
sDataBar HlpDataBar; // Структура с ДАННЫМИ на баре для вспомогательного ТФ
далее в теле программы:
передаю в цикле на каждый бар обе структуры
MathDataForBar(OsnDataBar, i, 1);
MathDataForBar(HlpDataBar, i, 2);
в самой функции принимаю структуру так:
void MathDataForBar(sDataBar &DataBar,int i, int variant)
{
...
//делаю с данными шпили вили ))
...
}
ключевая фишка в СИ это передача по ссылке &
я просто передаю в функцию указатель на необходимую мне структуру, и уже непосредственно в функции работаю с той структурой — ссылку на которую передал.
но блин не тут то было в СИ ШАРПЕ (( заветная & нифига не работает ((
а читать пруфы не могу ибо туп (( мне надо на пальцах ((
люди добрые программисты, если вы есть, и если вы можете для чайника на пальцах описать как это воплотить в шарпе — буду крайне признателен и благодарен!
Если вам нужно менять структуру в методе, передавая её как параметр, то есть ключевые слова ref и out.
Передача по ссылке применяется только для того, чтобы изменить в методе и получить это изменение снаружи.
Кроме того, в C# есть разница между Value и Reference type сущностями.
Вторые всегда передаются по ссылке, поэтому & не требуется.
Но Struct — это value type.
Спасибо ОГРОМНОЕ!!!
public struct Book
{
public string Name;
}
Book b;
protected override void OnBarUpdate()
{
b.Name = «b»; Print(b.Name);
func(ref b, «BookName»); Print(b.Name);
}
public void func(ref Book Tek, string txt)
{
Tek.Name = txt;
}
и все работает
выводит:
b
BookName
вот этого
вообще не понял ))
самое простое это заявки и сделки, которые так и просятся объединить. создаёте базовый класс с общими свойствами и функциями от него наследуете классы ордер и трейд, а дальше уже сам код подскажет как с этим добром жить :)
я по природе своей тугодум, мне крайне сложно читать теорию если я сразу же не вижу как это может быть воплощено на практике. причем голый код меня не впечатлит, нужен переводчик с кода на человеческий язык… пока таких книжек не придумали, а потому я иду от обратного — не изучаю теорию и потом практикую, а ставлю практическую задачу и копаюсь в теории в поисках что поможет для ее решения — путь гораздо более трудо и ресурсоемкий, однако я только так и могу что то изучить — через непосредственную практику.
в программировании вообще ничего сложного нет, музыку написать или картину в разы сложней.
не знаю как люди умудряются учиться по книгам, обычно достаточно справочника по функциям. в книгах нужно опыт перенимать: почему применялся такой то подход или алгоритм, а на начальном этапе это лишнее.
разбиваешь проект на модули, эти модули на задачи по одной делаешь. а после завершения на этапе оптимизации можно и книжки почитать, а когда наберетесь опыта будет проще выбрать правильный способ ещё на первом этапе.
и вообще новичкам я бы сейчас рекомендовал, что то попроще чем шарп, он слишком гибкий. если софт с gui то я бы выбрал angular.
Тихая Гавань, классы понадобятся, когда будете реализовывать более сложные и функциональные сущности.
Содержащие/ссылающиеся на другие классы.
я честно не совсем понимаю о чем вы, но постараюсь перевести для себя таким образом:
пока я научился использовать структуры дабы избежать повторяющегося кода.
у меня есть структура и есть методы в отдельной функции.
я передаю структуру в функцию и сторонние методы работают с данными и результат записывают в структуру, наверняка это не совсем правильно, я не знаю ))
скорее всего было бы правильней создать класс, и в него передать данные, чтобы в самом классе их обработать и записать результаты.
может быть это и есть правильно, но чесс слово я бы так и поступил, если бы знал как в класс передать массив истории котировок.
причем у меня мультитаймфреймовая система, соответственно необходимо передавать разные данные, а этого я пока не умею делать…
в русскоязычном сегменте поддержки Нинзи — все идет лишь — заплати денег и мы тебе напишем, а англоязычный сегмент поддержки не доступен по причине капитального баранизма в английском языке ))
PS от слова СУЩНОСТИ меня сразу бросает в легкую панику )) ибо последний раз когда мне попадалось это слово — это когда читал Блаватскую ))
Тихая Гавань, примерно так.
Класс в котором набор свойств и методов.
А почему выбор пал на ниндзю ?
IB предоставляет хорошие условия, как по комиссиям, так и по спектру рынков ?
API достаточно стройный, функциональный и гибкий.
вы же понимаете мой уровень )) я такого ни в жизть не напишу ))
к томуже мне совершенно не нравится тех поддержка в IB, зимой они меня можно сказать обманули на 400 долларов, потом признали свою ошибку, но деньги не вернули под предлогом — САМ ДУРАК.
в нинзе я хорошо знаком с Ланой Орловской, на мой взгляд это самая лучшая тех поддержка вообще во всем мире среди вообще ВСЕХ брокеров!
Тихая Гавань, API у них, как и везде.
Подключаешься, посылаешь команды, получаешь результат.
Он менее интегрирован с визуальной частью терминала, чем Ninja, но это плюс, а не минус.
Потому как лишних зависимостей нет, а значит и потенциальных проблем.
Для контроля работы робота есть масса других вариантов.
От логов до таблиц в программе(графиков при необходимости).
Это не сложно.
А по комиссиям кто выгоднее IB или Ninja ?
так как необходим не просто код робота, но и оболочка.
с нинзей проще — в качестве оболочки выступает сама нинзя ))
комиссии в принципе одинаковы что там что там…
Тихая Гавань, ну ок.
В IB я значительно сильнее, чем в Ninja.
Хотя при необходимости разобраться не проблема.
Принципы везде едины.
Спрашивайте в случае чего.
Алексей Васильев, это проблеск параллельной реальности.
Исключение так сказать.