Ошибки, баги, вопросы - страница 1409
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
По поводу анонса нового билда 1200.
Очень костыльно смотрятся такие решения, когда наряду с datetime time в структуру добавляются ещё и long time_msc. Спрашивается, зачем тогда здесь нужен time? Бессмысленное растрачивание ресурсов.
Это же относится и к uint flags, в то время как там хватило бы uchar, ну или на крайняк - ushort (это уже с существенным запасом на будущее). А зачем там uint - уму непостижимо. Печально, что разработчики совсем перестали задумываться о рациональном хранении данных. Массив тиков - это колоссальный объём сам по себе. А тут ещё и так халатно разбазаривается память...
Ну и вообще что касается времени. Может пора уже ввести в MQL нормальный временной тип, содержащий миллисекунды? Иначе так и будет нагромождение этих костылей. Тем более что сам по себе datetime в существующем виде - крайне нерациональная вещь: расходует 8 байт, но содержит только секунды - и кому это надо? Для этой задачи хватает и 4-х байт (uint) на ближайшие 90 лет (а Дунканов Маклаудов среди нас нет).
Это решение сохраняет совместимость для старых программ, использующих время в секундах или функцию SymbolInfoTick().
Поверьте нашему опыту, игра "давайте уложимся в байт или два" приводит к чудовищным проблемам в будущем. Понимание этого приходит только тогда, когда пишешь софт на 10 лет вперед.
4 байта datetime в секундах кончаются в 2038 году (22 года еще), а не через 90 лет.
Что означает здесь ТМ=30М ?:
Поверьте нашему опыту, игра "давайте уложимся в байт или два" приводит к чудовищным проблемам в будущем. Понимание этого приходит только тогда, когда пишешь софт на 10 лет вперед.
Так речь и не идёт о том, чтоб делать в притык. Разумеется, надо оставлять задел на будущее. Но в разумных же пределах. Вот в обсуждаемом случае поле flags хранит инфу лишь о шести других полях. Если сделать её тип ushort, то это даст запас ещё на 10 полей. Куда уж больше то? Что в неё ещё можно такого напихать?
Если же вы планируете например сохранение туда полного стакана, то тогда уж и 32 бит не хватит. Чё ж тогда сразу 64 бита не сделать? Хотя очевидно, для стакана понадобится совсем другая структура.
Я конечно понимаю, что лишних 2 байта - это не очень существенно. Но ведь получается так, что 2 байта здесь, 2 байта там... и в итоге набегает прилично.
4 байта datetime в секундах кончаются в 2038 году (22 года еще), а не через 90 лет.
Я же говорю - помучаетесь с нерасширяемыми экономными структурами, начнете мыслить категориями десятков лет, необходимости долгой поддержки и все станет ясно.
С 4 байтовым datetime у массы софта будут большие проблемы с переполнениями как раз в 2038 году, что приведет к судорожному переписыванию старого кода. Причем переполнения будут ловиться даже раньше на мат операциях и дельтах.
Программирую уже 25 лет и знаю о чем говорю. Писал экономичные программы всю жизнь. Посмотрите на наши терминалы - они реально шедевры по объему заключенного функционала в одиночных exe файлах малого размера. Для интереса запустите одиночный голый terminal.exe на чистом компьютере и посмотрите, что произойдет.
Но сейчас все изменилось - или ты пишешь 64 битный код с запасом практически везде или остаешься за бортом будущего. Особенно это важно для нас, так как мы не закрытые ящики выпускаем, а платформы разработки с обязательным требованием совместимости.
Через пару лет мы еще будем локти кусать, так как снова окажется, что недозаложились. А вокруг компьютеры с десятками гигабайт в базовой комплектации.
Что означает здесь ТМ=30М ?:
С 4 байтовым datetime у массы софта будут большие проблемы с переполнениями как раз в 2038 году, что приведет к судорожному переписыванию старого кода. Причем переполнения будут ловиться даже раньше на мат операциях и дельтах.
Вы имеете ввиду коды на MQL4 ? (где datetime изначально был основан на int). Тогда конечно другой разговор, связанный с проблемами совместимости. Но я изначально вёл разговор о рациональности. Так вот в данном случае рациональность страдает.
Впрочем в любом случае, я думаю вы согласитесь, что нужен новый тип времени, содержащий миллисекунды. И начинаться отсчёт должен не с 1970 года, а гораздо раньше, например с 1900 года. Речь ведь уже не только о форексе. Биржи существуют с очень давних времён.
...
Впрочем в любом случае, я думаю вы согласитесь, что нужен новый тип времени, содержащий миллисекунды. И начинаться отсчёт должен не с 1970 года, а гораздо раньше, например с 1900 года. Речь же теперь не только о форексе. Биржи существуют с очень давних времён.
Проблема только в том, что при царе Горохе было не модно пользоваться компьютерами и историю тиков биржи не сохраняли для будущих поколений...
Да речь же необязательно о тиках. Например дневные свечи вполне сохранились.
Стесняюсь спросить, а зачем Вам цены дневных свечек за 1900.. годы? Теханализом заниматься? Адвизоров на истории тестировать?
Прирост скорости исполнения от 2 до 10 раз для x64 версий MetaTrader 5 терминала.
Результат стоит того. Хотя над скоростью компиляции мы еще поработаем.
Вы недавно хвастались, что скорость MQL уже близко C++. А теперь с ваших слов получается, что будете обгонять C++ в разы? ))
Если на неких специально подготовленных тестах вы и получили такое ускорение, то это отнюдь не значит, что ускорение будет и в других случаях. Зато торможение компиляции идёт во всех случаях.