Обновление платформы MetaTrader 4 build 670: виртуальный хостинг, web-запросы и работа с сигналами из MQL-программ - страница 35

Новый комментарий
 
sanyooooook:

Что мешает сделать динамический массив и после установить его размер?


Во-первых, лишний оператор Resize(). Во-вторых, если нужен конкретный размер массива, то всегда и везде создавался статический массив int aaa[100]; Причем, если прожка пишется в студии, то статический предпочтительнее, потому что в случае динамического его ещё и удалять надо. Конечно, без динамических не обойтись, но во всех случаях, где можно обойтись статическим, статический однозначно.

 
А кроме этого видятся странным советы, как избежать предупреждений. Т.е. будем писать прожки на N-ное количество строк больше, чем нужно? Чтобы это N-ное количество строчек убрало N-ное количество ненужных предупреждений. Поскольку, как я понял по прочтению сего форума, есть некоторое количество сограждан, которым плевать на предупреждения, но большинство программеров они всё ж раздражают. Ну, если и не раздражают, то точно напрягают. Клацнул кнопку F7 и получил 0 ошибок, 0 предупреждений - ожидаемая ситуация. А если вместо этого вывалилась кучка строк, которых быть не дОлжно, то лезешь разбираться. А с чем разбираться? Какой-то массив размером 8 мегабайт превышает размер 512 килобайт? Или осталась парочка неиспользованных переменных? Так не использованы они потому, что пара строк временно закомментирована (например). Но MQL сотоварищи решили в одностороннем порядке взвалить на плечи борьбу с безграмотностью населения на поприще кодинга. И никого не интересует, хочет население кодить или не хочет. Но если вдруг захочет, то вот ему, населению, непосильное вспомоществование.
 
Alexey_74:


Во-первых, лишний оператор Resize(). Во-вторых, если нужен конкретный размер массива, то всегда и везде создавался статический массив int aaa[100]; Причем, если прожка пишется в студии, то статический предпочтительнее, потому что в случае динамического его ещё и удалять надо. Конечно, без динамических не обойтись, но во всех случаях, где можно обойтись статическим, статический однозначно.

Скорее всего вы заявили этот массив локально в функции с размещением в стеке, что может быть опасно из-за потенциального исчерпания стека. Особенно в рекурсивных функциях.

Такое сообщение о перегрузке локального стеа можно получить и в статических анализаторах С++ кода. Мы просто добавили такое предупреждение штатно.

Например, штатный Code Analysis в Visual Studio 2012 на int aaa[1000000]; выдает:

warning : C6262: Function uses '4000028' bytes of stack:  exceeds /analyze:stacksize '16384'.  Consider moving some data to heap.
4 мегабайта в стеке - это очень много и так как обычные потоки запускаются с дефолтным стеком в 1 мб, то можно очень быстро получить проблемы.
 

Обращаюсь к разработчмкам с пожеланием, выраженным ранее, к сожалению незамеченным!

Могли бы сделать опцию для Сomment(), чтобы 1-й символ появлялся 1-ым справа, 2-ой на место 1-го, а 1-ый бы сдвигался налево и т.д. Тогда получится с ориентацией направо, что практикуется во всех программах для текста, наряду с ориентировкой по центру, что нам тоже пригодилось бы только с возможностью устанавливать точку центра на любую точку Х справа от котиров! Я думаю, что было бы очень удобно всем! Буду благодарен за ответ!

 
Во время оптимизации в версии 670 за считанные минуты лог файл разбухает до сотен мегабайт. Такими темпами места на диске не хватит и на час оптимизации, а планируется порядка суток или более. Посмотрел - тестер помещает туда информацию об открытии, удалении ордеров и т.д.

Например:
Tester: order #yyyy, buy 0.01 EURUSD is opened at 1.xxxxx
delete #kkkk buy stop 0.01 EURUSD at 1.xxxxx sl: 1.xxxxx tp: 1.xxxxx ok

Это что-то новое или может быть связано с кодом Советника?
Если новое то в какой последней версии МТ4 подобное явление не наблюдается и откуда ее можно загрузить?
 
Renat:

Скорее всего вы заявили этот массив локально в функции с размещением в стеке, что может быть опасно из-за потенциального исчерпания стека. Особенно в рекурсивных функциях.

Такое сообщение о перегрузке локального стеа можно получить и в статических анализаторах С++ кода. Мы просто добавили такое предупреждение штатно.

Например, штатный Code Analysis в Visual Studio 2012 на int aaa[1000000]; выдает:

4 мегабайта в стеке - это очень много и так как обычные потоки запускаются с дефолтным стеком в 1 мб, то можно очень быстро получить проблемы.


Да, локально в функции. Функция не рекурсивная. Спасибо за разъяснения. Т.е. выход, как я понимаю, объявлять такие массивы глобально, чтоб не попасть на переполнение стека?
 

Почему нельзя #property strict добавлять в библиотеку?

Добавляю - функции в библиотеке не находит, убираю - находит.

 
Y.A.K._:

Почему нельзя #property strict добавлять в библиотеку?

Добавляю - функции в библиотеке не находит, убираю - находит.


Как все переплелось..

Увидел Ваше сообщение и решил проверить не может ли #property strict быть виновником разбухания лог-файла во время оптимизации - оказалось это ОН!

А пост выше "the size of local variables is too large (more than 512kb)" - тоже один из текущих вопросов. Вот только проблема из-за того что невозможно изменить размер массива во 2-м измерении при помощи стандартного ArrayResize, приходится постоянно задавать размер с учетом максимально возможного значения, по крайней мере на этом этапе.
 
Y.A.K._:

Почему нельзя #property strict добавлять в библиотеку?

Добавляю - функции в библиотеке не находит, убираю - находит.


Пожалуйста, напишите заявку в Сервисдеск со всеми подробностями. Предоставьте код для воспроизведения.
 
Alexey_74:

Да, локально в функции. Функция не рекурсивная. Спасибо за разъяснения. Т.е. выход, как я понимаю, объявлять такие массивы глобально, чтоб не попасть на переполнение стека?

Большие массивы нужно выделять динамически.

На глобальном уровне тоже стека может не хватить.

1...282930313233343536373839404142...56
Новый комментарий