Виталий написал: Если у кого есть еще какие мнения - выслушаю.
тут нет никаких мнений, а либо есть знания, либо их нет - как в Вашем случае.
читайте про АТД и затем про ООП. это фундаментальные вещи.
Цитата
Виталий написал: Сам я знаком и очень хорошо с традиционным ООП на языках, изначально заточенных под это.... Отсюда вопрос: есть ли вообще смысл это понять и внедрять каждом проекте, что это реально дает: экономия памяти, скорость, еще что-то?
видимо пора перейти от поверхностного знакомства к системному изучению ... иначе так и будет - только ошибочное самомнение.
Latrop написал: Кстати, любопытно, зачем приходится разбирать нутро dat-файлов квика? Какая там есть полезная инфа, которая недоступна в скриптах?
это позволяет просто взять инфу без обращения к квику.
Цитата
Latrop написал: И можно где-то раздобыть уже готовые парсеры этих dat-файлов
это вряд ли разумно, тк некий объем работы проделан, а если это вывалить на всеобщее, то арка просто сменит структуры и опять их наново парсить. смысл?
как видите бесполезно объяснять мышевозилам, что без мыши можно вообще обойтись и когда-то их не было и это делает их потребителями
чем торговые терминалы отличаются от видеоигр? о чем говорить с людьми, которые всерьез пялятся в средние по OHLC. для них не падает - значит работает :)
если спросить любого грамотного технаря со стажем 20-25 лет для чего появились шарп, джава и прочие голанги, то они четко отвечают : чтобы и плохие программеры могли кодить , а манагеры это втюхать быстро
Чистый си - это как секс для подростков: он у всех на уме, все постоянно о нём говорят, все думают, что все остальные это делают, никто на самом деле этим не занимается. А те немногие, кто правда это делает - делают это плохо, небезопасно, и думают, что в следующий раз обязательно получится лучше. Вопрос - а нафига заниматься си если с той же эффективностью можно подушить питона??? Что же касается мышевозил, то вся эта мышевозня позволяет мне сосредоточится на решении основной задачи не отвлекаясь на написание большого количества кода чтобы заставить кнопку работать. Эту задачу в команде можно передать младшему сотруднику, пускай он формочки программирует формочки, вручную выписывая каждую кнопку. Чем вы по всей видимости и занимаетесь, и очень этим гордитесь. Люди давным давно придумали трактор чтобы землю пахать, а вы видимо даже о лопате не слышали, всё мотыгой машете, а развиваться судя по всему и не думаете так-как мозги давным давно покрыла плесень, а может срах перед чем-то новым, или лень (да мне в принципе пофиг)... А видеоигры от торгового терминала отличаются необходимостью невероятно огромного количества невероятно быстрых вычислений которые квику даже и не снились и об этом не знаете судя по всему только вы. С# реально быстрый, он на много быстрей других ЯПов. и гораздо более безопасный. Сергей Привалов здесь ещё привёл удачный пример реализации торговой платформы NinjaTrader... Я в своё время выучил пять языков программирования, точней четыре, пятый я вот уже пять лет как активно изучаю (это C#) и до сих пор не исчерпал всех его возможностей. А ваша квалификация программиста вызывает у меня большие сомнения, шли бы вы в детский сад трепаться там ваши высказывания смеха не вызовут. Кстати формы я давно не программирую, люди придумали вещи получше. Хотя куда вам до "получше" вы сегодня только про лопату услышали... Хотя, зачем узнавать что-то новое, так можно и грыжу мозга заработать.
ну вот никак нельзя пропустить возможность побиться в истерике ... эт святое .... попрыгай, в ладошки похлопай ... на шарпе поговнокодь ... узбагойся крч, к тебе нет вопросов :)
как видите бесполезно объяснять мышевозилам, что без мыши можно вообще обойтись и когда-то их не было и это делает их потребителями
чем торговые терминалы отличаются от видеоигр? о чем говорить с людьми, которые всерьез пялятся в средние по OHLC. для них не падает - значит работает :)
если спросить любого грамотного технаря со стажем 20-25 лет для чего появились шарп, джава и прочие голанги, то они четко отвечают : чтобы и плохие программеры могли кодить , а манагеры это втюхать быстро
Anton написал: И что дальше делать? Объяснить, что это туфта?
ага ... может еще игрунам пояснять, что они тупеют от игр? или заемщикам, что они заплатят в разы? или заказчикам, что они- мсяо? потише на поворотах ... Герман скажи ему ... https://www.youtube.com/watch?v=MQ8qMim7eIQ
Андрей написал: Ограничения не конкретно на Wine, ограничения на новых версиях MacOS в целом. Последние версии MacOS прекратили поддержку 32-битных систем. Если бы Wine был эмулятором, то это бы его не касалось.
_sk_ написал: примеры того, как Вы работаете с номерами заявок и сделок,
извините, но нет
Цитата
_sk_ написал: чтобы потребовались арифметические операции
есть арифметика, есть и другие моменты то, что можно озвучить: системы хранения и выборки должна быть вполне быстрой
но даже более тут главное - все эти вопросы совершенно пустые ... надуманные, тк лонг в qlua должен быть доступен и по массе других причин
очевидно пришло время апнуть луа до 5.3 и не потому, что 5.1 это мало, просто экосистема такова на текущий момент ( кстати - так себе экосистема, imo )
Александр М написал: и это точно вы не успеете за оставшиеся 14 дней
Александр, не могли бы сформулировать для обчего развития суть претензии к АРКА вида:
вы, нехорошие люди, давно должны были понимать, что число в 19 цифер в номерах срочно было очень надо, тк .... _вставить нужное_ ... и ничего не было сделано - позор!
Egor Zaytsev написал: Добрый день. Правильно понимаем, что вы хотите, чтобы мы добавили новое поле unix_datetime, (например, на сделках или заявках) т.к. Вам не удобен формат Lua таблицы?
Если все же решите добавить это поле, не забудьте добавить и дробную часть (микросекунды)
Anton написал: В фиксе как раз они самые, поле UTCTimestamp выглядит типа
бито-байты в железе и картинки на мониторе из табличек различаем? вам сиплюсплюс лоб напек наверное :)
а ..а, ну точно
Цитата
static int hibit(unsigned long long ull) throw () // нужно только для ассерта в отладочном режиме { int result = 0; while((ull >>= 1) != 0) ++result; return result; } double filetime_to_unix_time_with_microseconds(const ::FILETIME * pft) throw () { assert(pft); const unsigned long long uoffset = 116444736000000000ULL; const unsigned long long ftime = (static_cast<unsigned long long>(pft->dwHighDateTime) << 32) | pft->dwLowDateTime; const unsigned long long utime = (ftime - uoffset) / 10; assert(::hibit(utime) < 52); return static_cast<double>(utime); }
Imersio Arrigo написал: а) откуда уверенность что FILETIME
нету а..аще никакой :) , но ...
когда берем по адресу из .dat файла 8 байт как лонг и потом это делим на 10 млн и вычитаем 11644473600L, то хлоп .. и получается пхальное юникс_тайм в секундах
вот и подумалось могу быть неправ, ессно
Цитата
Imersio Arrigo написал: б) тогда уж лутше в луа отдавать FILETIME (ежели прям без конверсий)
ну с версии 5.3, когда будет лонг , то - да
Цитата
Imersio Arrigo написал: ну тогда всеравно в time_t конвертить нужно.
Anton написал: где оно у них в число превращается и превращается ли вообще
не просто превращается, а в dat файлах оно у них уже в FILETIME формате те считай всё уже тут, а потом бац и ... /* ... во вторую смену ... (с) */ ... в табличку
ткчт и делать то особенно ничего не нужно - нужно просто кое-чего НЕ делать
Если, как я понял, речь о целых числах в луа, так они как intptr_t определяются и на 64 битах должны быть 64-битные из коробки, а вот если заменить в заголовке на long, то получим внезапно 32 бита, ибо на винде long 32-битный. Или о другом чем-то?
лично у меня нет таких вопросов - есть и более прямой способ
здесь предложение реализовать то, как это должно быть зачем плоскую инфу загонять в табличный вид который все равно потом нужно обратно в плоский вид ну пусть с сервера дают пока что в double чтобы обходиться без преобразования типов и структур потом в 5.3 это будет более просто в long
Egor Zaytsev написал: Правильно понимаем, что вы хотите, чтобы мы добавили новое поле unix_datetime, (например, на сделках или заявках)
да, а вы пропатчили 5.1 для long?
Цитата
Egor Zaytsev написал: т.к. Вам не удобен формат Lua таблицы?
дело не в удобстве - пара строк не проблема, а в лишних временных затратах на преобразование или сборку своих полей из таблицы для массовых скоплений можете сами проверить затраты на сотне тысяч записей: передернуть времена в long отжирает как быстрая сортировка
Если на ваши сервера приходят данные с Unix-временем , то предлагаю сделать доступным такой формат тоже во избежание излишних трансляций на каждом трейде для автоматизированных систем, коль скоро QLua тут для этого.
Anton написал: Я на арку и не наезжал, народ просил - они сделали, но сделать с той же производительностью, что и нативный интерфейс, они вряд ли смогут, бо нативный читерствует при отрисовке, документированными способами сделать "то же самое без крыльев" не получится, а недокументированные использовать себе дороже, закончится это отдельной веткой кода под каждую версию винды.
вся индустрия ПК x86, будучи изначально аппаратным мусором, развила эту тему на 5+ в программном обеспечении нагородив ооп, vm, try-catch и прочее фуфло вокруг примитивной поделки 80-х годов прошлого века а предиктивная философия современных x86, поливаемых водичкой, замкнула этот адский круг глобального дерьма
судя по-всему единственный выход из этого реализуется в виде перевода основных вычислений любого рода на back-end c принципиальной заменой front-end хромбуками, win core os и surface neo/duo аналогами
ткчт имо: арка - не самый фиговый представитель в общей куче
Anton написал: Справедливости ради, с играми сравнивать некорректно.
абсолютно корректно, если иметь ввиду использование минутных OHLC - это очевидно 90% юзеров данного фронтенда пытаться анализировать и использовать такого рода "статистику", да еще расчитывать по ним некие суррогатные величины и при этом ставить на это свои деньги - это в чистом виде именно игра