если ты не знаешь возможно или нет, то лучше не надо начинать)))
а так бери stocksharp и пиши что душа пожелает, много времени не займет если програмить умеешь
Не так давно пытался написать робота. Скачал библиотеки, пытался разобраться в примерах и в документации. Оказалось, последняя версия билиотек сильно отличалась от того, что написано в документации, много чего не работало. Саму же документацию уже несколько месяцев(а может и лет) не исправляли. По крайней мере в тех примерах, которые мне были нужны и которые изменились. При попытках выяснить всё на форуме S# отвечать как-то не пытались. Это моё личное мнение.
V.V., тоже столкнулся с этим. перешел на тслаб и не жалею. тоже родной c#, все понятно, документация есть (хоть и скудноватая), плюс большое сообщество. Спустя месяц после знакомства роботы уже пашут.
smartlab, была когда-то библиотека ZedGraph. Не знаю развивают ли её ещё или уже помер проект. Но на момент когда мне это было интересно ничего лучше не было для графиков. Но это дотнет.
smartlab, для этого достаточно Lua
прямо из квика запускаешь отдельное графическое окно (Lua умеет графику) и алга.
в принципе через Lua можно запустить и Delphi dll, если надо.
с помощью технологии ffi.
если совсем без квика, то надо на Delphi или протокол серверной части Quik поддерживать, или делать клиента для FIX протокола — что для небольшого эксперимента слишком сложно.
Идея мертва до рождения.
Допустим, Вы решили занять нишу на рынке современных терминалов. Это возможно, потому как конкуренты не особо Ж. рвут в борьбе за пользователя.
Однако...
Компилятор дельфи практически не оптимизирует код. Там хлама будет комом накатывать от релиза к релизу. На нём можно писать простые или тормозные штуки. Если Вы ставите задачу написать что-то лучше Квика и лучше МТ, тогда сразу надо C++ брать за основу. Интеловский компилятор даст фору. Если не хватит обвязки (для графики и всяких рюшечек), далее добавляется дотнет. Но уж никак не дельфи.
Ну а для себя… Однозначно нет. Смысл?
HFT боту терминал ваще не нужен, а для остальных задач полно всяких софтин.
SECRET, я думал борланду каюк. сам в 1999 один год зарабатывал на Delphi, потом устроился на другую работу где успешно изучил C++, C# и остановился на Java
хотя про лёгкость программирования GUI в Delphi помню до сих пор. легче с тех пор ничего не видел. но я и мало смотрел, GUI не люблю.
Delphi ничем не хуже, чем c++, я бы сказал что даже лучше в плане удобства разработки. Сам серьёзно и глубоко работал и на том, и на другом, поэтому мне совершенно не понятно о чём тут говорят некоторые товарищи, которые осуждают Delphi. Какой бы компилятор не был у Delphi (по мне так нормальный компилятор), он в любом случае будет намного лучше чем тот же .NET, ибо нативный.
На счёт торгового терминала — громко сказано. Даже если и создашь что-то подобное квику за несколько лет, то это будет никому не нужный огромный труд, и возможно что и самому автору к тому времени он будет не нужен. Сольёт депозит, уйдёт с биржи… Если и создавать что-то, то как примочку и надстройку для квика или плазы. Типа скальперский стакан с графиками и индикаторами.
Дмитрий — Челябинск, если вы ставите на один уровень delphi и C++ то вы явно ничего не смыслите в оптимизации ресурсов и качественной разработке неглючного приложения. На дельфе «умельцев» дофига только потому что во многих технарьских вузах его берут за основу обучения + к тому же там можно вообще не заморачиваться — минимальное приложение «Hello, World!» получаешь в размере 2 мегабайт ))))
S# тоже достаточно тормознутая штука, но конечно же на порядок быстрее дельфи поганой
самый оптимал это действительно С++, в идеале ассемблер, но тут соотношение трудоемкость/скорость работы приложения не стоит свеч для конкретно этой задачи (хотя под asm есть даже неплохая GUI среда разработки — компилятор masm и gui radasm)
Андрей,
Если Вас удивляет размер
«приложение «Hello, World!» получаешь в размере 2 мегабайт», значит Вы совершенно не знаете и не представляете откуда берётся этот объём, для чего и как от него можно избавиться. И кроме как в своём «технарском вузе» вы о нём нигде не слышали, иначе такого бы не писали.
А, следовательно, вести с Вами далее дискуссию на этот счёт бессмысленно. (Даю подсказку на C++ — Библиотека времени выполнения Многопоточная /MT и кое что ещё...)
Скажу лишь по поводу фразы: «качественной разработке неглючного приложения».
За свой многолетний опыт разработки на Delphi (и не только), я не видел ни одного глюка софта, разработанного на Delphi, который бы не был следствием кривых рук программиста. Вы сейчас будете рассказывать про «Access Violation» и подобное? — в 100% случаев это недоработка программиста и чаще всего в синхронизации потоков.
Доказывать ничего не буду, останусь при своём мнении. Можете считать так, как Вам угодно. Мне просто лень сейчас вести дискуссию на этот счёт и спорить. Пойду анализировать графики по Si и RI. Удачи…
Вряд ли это поможет заработать больше денег, чем в любом другом терминале. Это как играть в покер. Какая разница, на чем сидеть, на стуле, кресле или табуретке? Есть только один критерий — умеешь играть или нет.
Вполне можно написать свой терминал. Я сам написал примерно за полгода. Сейчас подумываю 2-ю версию написать. Пишу на делфи. На си-шарпе по-моему получается писать сложнее. Да на си-шарпе приложение будет несколько быстрее при условии, что приложению нужно мало памяти, но если приложению требуется много память — это реальные тормоза и глюки. Возможность управлять памятью — это одно из главных преимуществ нативного кода при условии, что памяти необходимо использовать достаточно много. В делфи тоже приходится оптимизировать некоторый код. TChart достаточно глючный компонент.
Терминал пишу с несколькими целями:
1. Не хватает функциональности в текущих терминалах. Нужны дополнительные функции.
2. За частую неудобный интерфейс
а так бери stocksharp и пиши что душа пожелает, много времени не займет если програмить умеешь
к котировкам брокера через шлюзы plaza например.
описания протоколов все есть в свободном доступе
Я бы форму свечек поменял. Не нравятся они мне.
прямо из квика запускаешь отдельное графическое окно (Lua умеет графику) и алга.
в принципе через Lua можно запустить и Delphi dll, если надо.
с помощью технологии ffi.
если совсем без квика, то надо на Delphi или протокол серверной части Quik поддерживать, или делать клиента для FIX протокола — что для небольшого эксперимента слишком сложно.
Допустим, Вы решили занять нишу на рынке современных терминалов. Это возможно, потому как конкуренты не особо Ж. рвут в борьбе за пользователя.
Однако...
Компилятор дельфи практически не оптимизирует код. Там хлама будет комом накатывать от релиза к релизу. На нём можно писать простые или тормозные штуки. Если Вы ставите задачу написать что-то лучше Квика и лучше МТ, тогда сразу надо C++ брать за основу. Интеловский компилятор даст фору. Если не хватит обвязки (для графики и всяких рюшечек), далее добавляется дотнет. Но уж никак не дельфи.
Ну а для себя… Однозначно нет. Смысл?
HFT боту терминал ваще не нужен, а для остальных задач полно всяких софтин.
а в дельфях есть какие нибудь готовые компоненты для торговли?
хотя про лёгкость программирования GUI в Delphi помню до сих пор. легче с тех пор ничего не видел. но я и мало смотрел, GUI не люблю.
На счёт торгового терминала — громко сказано. Даже если и создашь что-то подобное квику за несколько лет, то это будет никому не нужный огромный труд, и возможно что и самому автору к тому времени он будет не нужен. Сольёт депозит, уйдёт с биржи… Если и создавать что-то, то как примочку и надстройку для квика или плазы. Типа скальперский стакан с графиками и индикаторами.
S# тоже достаточно тормознутая штука, но конечно же на порядок быстрее дельфи поганой
самый оптимал это действительно С++, в идеале ассемблер, но тут соотношение трудоемкость/скорость работы приложения не стоит свеч для конкретно этой задачи (хотя под asm есть даже неплохая GUI среда разработки — компилятор masm и gui radasm)
Если Вас удивляет размер
«приложение «Hello, World!» получаешь в размере 2 мегабайт», значит Вы совершенно не знаете и не представляете откуда берётся этот объём, для чего и как от него можно избавиться. И кроме как в своём «технарском вузе» вы о нём нигде не слышали, иначе такого бы не писали.
А, следовательно, вести с Вами далее дискуссию на этот счёт бессмысленно. (Даю подсказку на C++ — Библиотека времени выполнения Многопоточная /MT и кое что ещё...)
Скажу лишь по поводу фразы: «качественной разработке неглючного приложения».
За свой многолетний опыт разработки на Delphi (и не только), я не видел ни одного глюка софта, разработанного на Delphi, который бы не был следствием кривых рук программиста. Вы сейчас будете рассказывать про «Access Violation» и подобное? — в 100% случаев это недоработка программиста и чаще всего в синхронизации потоков.
Доказывать ничего не буду, останусь при своём мнении. Можете считать так, как Вам угодно. Мне просто лень сейчас вести дискуссию на этот счёт и спорить. Пойду анализировать графики по Si и RI. Удачи…
Терминал пишу с несколькими целями:
1. Не хватает функциональности в текущих терминалах. Нужны дополнительные функции.
2. За частую неудобный интерфейс