Что мешает сделать динамический массив и после установить его размер?
Во-первых, лишний оператор Resize(). Во-вторых, если нужен конкретный размер массива, то всегда и везде создавался статический массив int aaa[100]; Причем, если прожка пишется в студии, то статический предпочтительнее, потому что в случае динамического его ещё и удалять надо. Конечно, без динамических не обойтись, но во всех случаях, где можно обойтись статическим, статический однозначно.
А кроме этого видятся странным советы, как избежать предупреждений. Т.е. будем писать прожки на N-ное количество строк больше, чем нужно? Чтобы это N-ное количество строчек убрало N-ное количество ненужных предупреждений. Поскольку, как я понял по прочтению сего форума, есть некоторое количество сограждан, которым плевать на предупреждения, но большинство программеров они всё ж раздражают. Ну, если и не раздражают, то точно напрягают. Клацнул кнопку F7 и получил 0 ошибок, 0 предупреждений - ожидаемая ситуация. А если вместо этого вывалилась кучка строк, которых быть не дОлжно, то лезешь разбираться. А с чем разбираться? Какой-то массив размером 8 мегабайт превышает размер 512 килобайт? Или осталась парочка неиспользованных переменных? Так не использованы они потому, что пара строк временно закомментирована (например). Но MQL сотоварищи решили в одностороннем порядке взвалить на плечи борьбу с безграмотностью населения на поприще кодинга. И никого не интересует, хочет население кодить или не хочет. Но если вдруг захочет, то вот ему, населению, непосильное вспомоществование.
Во-первых, лишний оператор 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 подобное явление не наблюдается и откуда ее можно загрузить?
Скорее всего вы заявили этот массив локально в функции с размещением в стеке, что может быть опасно из-за потенциального исчерпания стека. Особенно в рекурсивных функциях.
Такое сообщение о перегрузке локального стеа можно получить и в статических анализаторах С++ кода. Мы просто добавили такое предупреждение штатно.
Например, штатный Code Analysis в Visual Studio 2012 на int aaa[1000000]; выдает:
4 мегабайта в стеке - это очень много и так как обычные потоки запускаются с дефолтным стеком в 1 мб, то можно очень быстро получить проблемы.
Да, локально в функции. Функция не рекурсивная. Спасибо за разъяснения. Т.е. выход, как я понимаю, объявлять такие массивы глобально, чтоб не попасть на переполнение стека?
Почему нельзя #property strict добавлять в библиотеку?
Добавляю - функции в библиотеке не находит, убираю - находит.
Как все переплелось..
Увидел Ваше сообщение и решил проверить не может ли #property strict быть виновником разбухания лог-файла во время оптимизации - оказалось это ОН!
А пост выше "the size of local variables is too large (more than 512kb)" - тоже один из текущих вопросов. Вот только проблема из-за того что невозможно изменить размер массива во 2-м измерении при помощи стандартного ArrayResize, приходится постоянно задавать размер с учетом максимально возможного значения, по крайней мере на этом этапе.
Да, локально в функции. Функция не рекурсивная. Спасибо за разъяснения. Т.е. выход, как я понимаю, объявлять такие массивы глобально, чтоб не попасть на переполнение стека?
Что мешает сделать динамический массив и после установить его размер?
Во-первых, лишний оператор Resize(). Во-вторых, если нужен конкретный размер массива, то всегда и везде создавался статический массив int aaa[100]; Причем, если прожка пишется в студии, то статический предпочтительнее, потому что в случае динамического его ещё и удалять надо. Конечно, без динамических не обойтись, но во всех случаях, где можно обойтись статическим, статический однозначно.
Во-первых, лишний оператор Resize(). Во-вторых, если нужен конкретный размер массива, то всегда и везде создавался статический массив int aaa[100]; Причем, если прожка пишется в студии, то статический предпочтительнее, потому что в случае динамического его ещё и удалять надо. Конечно, без динамических не обойтись, но во всех случаях, где можно обойтись статическим, статический однозначно.
Скорее всего вы заявили этот массив локально в функции с размещением в стеке, что может быть опасно из-за потенциального исчерпания стека. Особенно в рекурсивных функциях.
Такое сообщение о перегрузке локального стеа можно получить и в статических анализаторах С++ кода. Мы просто добавили такое предупреждение штатно.
Например, штатный Code Analysis в Visual Studio 2012 на int aaa[1000000]; выдает:
4 мегабайта в стеке - это очень много и так как обычные потоки запускаются с дефолтным стеком в 1 мб, то можно очень быстро получить проблемы.Обращаюсь к разработчмкам с пожеланием, выраженным ранее, к сожалению незамеченным!
Могли бы сделать опцию для Сomment(), чтобы 1-й символ появлялся 1-ым справа, 2-ой на место 1-го, а 1-ый бы сдвигался налево и т.д. Тогда получится с ориентацией направо, что практикуется во всех программах для текста, наряду с ориентировкой по центру, что нам тоже пригодилось бы только с возможностью устанавливать точку центра на любую точку Х справа от котиров! Я думаю, что было бы очень удобно всем! Буду благодарен за ответ!
Например:
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 подобное явление не наблюдается и откуда ее можно загрузить?
Скорее всего вы заявили этот массив локально в функции с размещением в стеке, что может быть опасно из-за потенциального исчерпания стека. Особенно в рекурсивных функциях.
Такое сообщение о перегрузке локального стеа можно получить и в статических анализаторах С++ кода. Мы просто добавили такое предупреждение штатно.
Например, штатный Code Analysis в Visual Studio 2012 на int aaa[1000000]; выдает:
4 мегабайта в стеке - это очень много и так как обычные потоки запускаются с дефолтным стеком в 1 мб, то можно очень быстро получить проблемы.Да, локально в функции. Функция не рекурсивная. Спасибо за разъяснения. Т.е. выход, как я понимаю, объявлять такие массивы глобально, чтоб не попасть на переполнение стека?
Почему нельзя #property strict добавлять в библиотеку?
Добавляю - функции в библиотеке не находит, убираю - находит.
Почему нельзя #property strict добавлять в библиотеку?
Добавляю - функции в библиотеке не находит, убираю - находит.
Как все переплелось..
Увидел Ваше сообщение и решил проверить не может ли #property strict быть виновником разбухания лог-файла во время оптимизации - оказалось это ОН!
А пост выше "the size of local variables is too large (more than 512kb)" - тоже один из текущих вопросов. Вот только проблема из-за того что невозможно изменить размер массива во 2-м измерении при помощи стандартного ArrayResize, приходится постоянно задавать размер с учетом максимально возможного значения, по крайней мере на этом этапе.
Почему нельзя #property strict добавлять в библиотеку?
Добавляю - функции в библиотеке не находит, убираю - находит.
Пожалуйста, напишите заявку в Сервисдеск со всеми подробностями. Предоставьте код для воспроизведения.
Да, локально в функции. Функция не рекурсивная. Спасибо за разъяснения. Т.е. выход, как я понимаю, объявлять такие массивы глобально, чтоб не попасть на переполнение стека?
Большие массивы нужно выделять динамически.
На глобальном уровне тоже стека может не хватить.