qcustomplot - Кто-нибудь разбирается в этой библиотеке? Помогите использовать QCPFinancial::getVisibleDataBounds()

kvazar, 
— а как приготовить эти красивые грибы?
— это ядовитые грибы, их надо выбросить
— я не спрашивал как выбросить, я хочу их приготовить

kvazar, я посмотрел твой блог и до того, как продолжить разговор
мне придется спросить тебя о причинах использования С++ перед С# в твоем случае. на твое усмотрение.

kvazar, я увидел что ты творишь на форуме QT. :)

быстрее? — паходу  не быстрее тебя, чува… ак  :))

занесу тебя в ЧС, а то я тебя реально боюсь :))

kvazar, c++ qt мне кажется совсем не быстрое решение, если речь пошла о скорости.
ко мне обращались программисты, мне доводилось тестировать приложения, очень не понравилось. Но могу ошибаться тут.

kvazar, 

у С++ одна из высочайших производительностей по расчетам. это разве не так?

скорее всего это так. Но у меня нет достаточно опыта судить. Я не решал вопросы сравнения производительности, у меня не было таких задач. Могу только судить архитектурно. И на хорошем опыте знаю, что плюсы очень быстры. Больше тут сказать не могу.

Да и потом, о каких скоростях мы говорим. В каком масштабе? Секунды? Миллисекунды, микросеки или наносеки.
Чем ниже масштаб, тем компетентнее нужно быть в программировании. Иначе на плюсах можно влететь по скорости тоже. Понимать не только язык, но и железо. Уметь делать разные вещи типа профилирования и тд.

Если речь стоит о приросте в миллисекунду, я бы скорее всего плюсы не брал из за более сложных разработок. Ну какая вам будет разница, отправите вы заявку сейчас или через 10млсек? 

Но раз вы уже заморочились, попробуйте довести проект до конца. Что там вообще у вас не получается? Вы всегда очень кратко пишите без подробностей.

kvazar, 

Мне нужно сделать так, чтобы при изменении видимой части графика происходило его перестроение, строя только ту часть графиков, что попали на экран. И при этом нужно, что бы проходило автомаштабирование видимой части графиков по оси У, чтобы все точки по оси У попадали на экран

скорее всего это рядовые задачи, я такие тоже решал, когда надо было. Если структуировать, то

1) Чтобы сильных тормозов не было, не надо грузить всю историю. Загрузить часть. А при прокрутке влево/вправо только подгружать нужные участки. С таким подходом решится много вопросов, в том числе и масштабирование. То есть основная идея: как говорите, в ваш «виджет», грузить только малую часть и потом подгружать.
2) Масштабирование при таком подходе решится автоматически. Виджет ваш должен сам подстроить масштаб. Если этого не получится, у любого графика всегда есть настройка оси. Попробуйте менять у оси Y значения — минимальное и максимальное значение оси. Так он сам перемасштабируется скорее всего.
Ну а более подробно, нужно просто справку прочитать по вашему виджету, что он умеет в плане масштабирования, уверен справка такая есть.

kvazar, Нет единого ответа. Приложения Java будут быстрее при условии, что много памяти, т. к. в Java крутая оптимизация, то чего сложно добиться в нативных приложениях и сложно сделать нативным компилятором. Но если у приложения на java кончается память или память ограничена, наступают адские тормоза.
Поэтому с нативными приложениями ситуация стабильнее.
Также на Java хорошо реализованы потоки и примитивы для блокировки. Но в плане многопоточности можно использовать Go.

kvazar, Вы не верно подходите к проблеме производительности.
Во-первых, не каждый компилятор C++ генерирует быстрый код.
Во-вторых, многое зависит от вашей реализации. На сколько быстра будет ваша конкретная реализация. Если какой-то алгоритм на си++ реализован быстро, это ведь не значит, что вы другую задачу сможете реализовать быстро.

kvazar, Откуда же я знаю. Напишите тесты и проверьте.
Можно все вычисления загнать в DLL, а интерфейс писать на том, что удобно.
Я в основном пишу на Delphi. Я реализовываю плагинную систему для того, чтобы писать на разных языках программирования. Например, я могу использовать сборки на net. Сейчас задумался о Java. Посмотрим.

kvazar, мог бы, если услышишь
1. бросай плюсы и бери в руки Net: это широко юзают в мире частного трейдинга 
2. сбор данных напиши как консольный апп с перспективой в Core.Net
3. используй для визуализации либо S# или любую готовую либу: полно от мс до самодела
4. только когда упрешься в ограничение производительности в цифрах - начинай искать причины.

кроссплатформенность qt это скорее недостаток пока что, ибо глючен, текуч и на плюсах дофига работы. производительность ниже среднего.

на данный момент нет качественных кроссплатформееных  либ высокого уровня для гуя, увы. 

crazyFakir, слишком тяжело для квазара.

Андрей К, не общался, с бугра виднее. :)

kvazar, к сожалению нет, ни разу QT не использовал.

Андрей К, спасибо за маяк. это жесть :) 

crazyFakir, вы чушь какую-то про Qt и С++ написали…  конечно, если ничего кроме C# в жизни не видел, то да могут быть проблемы с плюсами. Qt — одна из лучших кросс платформенных GUI либ на сегодня.

vlad1024, п.здеть — не мешки ворочать :) 

crazyFakir, вот именно, я на C++/Qt ни один проект задеплоил.

Alex Hurko, 

Если вам важна кроссплатформенность, то посмотрите на JavaFX.

все западные движки  и брокеры РФ поддерживают шарп и никто джаву

На Core.Net я бы пока не особо надеялся

приучайся следить за базаром и обосновывать свои домыслы
вдруг придется со смрадлаба на улицу выйти :)

.Net Core 2.0 это основа для .Net Standard 2.0

crazyFakir, c Core.Net технология появилась в середине 2016 года. Лично для меня — это слишком маленький срок, чтобы использовать ее для личных нужд. Вопрос не в том, что технология плохая или сырая.  Просто она еще не достаточно обкатана. 

Alex Hurko, частично согласен

Alex Hurko, 

На Core.Net я бы пока не особо надеялся)

там вроде все хорошо. Переносимость очень высокая. Надежность то же. Написал, запустил и забыл, крутится там что то года полтора само без единого сбоя

ps про полтора я загнул. около года наверное