Пожалуйста, верните старый стиль METAQUOTES или хотя бы убедитесь, что коды, написанные в одной строке, не отформатированы.
Пример:
Старая модель и я считаю ее идеальной моделью для однострочных кодов.
if(TakeProfit>0){btp=Ask+(TakeProfit*Point());}else{btp=0;}
if(StopLoss>0){bsl=Ask-(StopLoss*Point());}else{bsl=0;}
Новый стиль, который портит всех моих роботов.
if(TakeProfit>0)
{
btp=Ask+(TakeProfit*Point());
}
else
{
btp=0;
}
if(StopLoss>0)
{
bsl=Ask-(StopLoss*Point());
}
else
{
bsl=0;
}
используйте стиль Pico , он очень похож на то что Вы ищете
но стиль Pico делит оператор if - else на 2 строки если используете { }
Ваш код, где используете { }
если не пользоваться { }
Да !!! сделал полный анализ доступных стилей и выбрал PICO и RATLIFF
ПИКО самая компактная.
RATLIFF самый умный.
Но для METAQUOTES абсурдно менять стиль, который использовался годами. Это нарушит жизнь всех пользователей. Безответственное изменение. Несколько месяцев назад я испортил что-то в их стиле, я думал, что двигаться было неправильно, несмотря на небольшие изменения, но теперь они облажались.
Да !!! мы знаем, что это бета-версия, но если что-то было верно в старых версиях и теперь изменилось в бета-версии, то, скорее всего, с этими изменениями. Лучше пожаловаться сейчас, чтобы убедиться, что все идет правильно
Есть два предложения, которые я хотел бы, чтобы METAQUOTES принял.
1) Установите замок на график, чтобы предотвратить закрытие используемого графика вместе с ненужными графиками при использовании CTRL-F4.
2) Разрешить пользователю определять количество ядер для использования в облачной сети. Например: я мог бы ограничить использование до 50 ядер в CLOUD NETWORK только для того, чтобы помочь и увеличить скорость оптимизации вместе со 100 ядрами, которые у меня уже есть на моих серверах. Таким образом, мне не пришлось бы покупать еще один или два сервера.
В настоящее время я не могу использовать CLOUD NETWORK, потому что это делает мои серверы бесполезными и ценность оптимизации становится высокой.
Сейчас ради эффективности строки преаллоцируются больше запрашиваемого, так как в подавляющем большинстве случаев они наращиваются последующими операциями.
С этим теперь понятно. Но как не меняю длину строки, результат StringBufferLen остаётся всегда 260.
Сейчас ради эффективности строки преаллоцируются больше запрашиваемого, так как в подавляющем большинстве случаев они наращиваются последующими операциями.
Добавил в тест StringLen, и инициализировал строку по другому. В документации одно, по факту совсем другое поведение. И буфер в этом случае показывает 0 а не 260. В общем или с инициализацией строк проблемы. Или StringBufferLen бажит.
Пожалуйста, верните старый стиль METAQUOTES или хотя бы убедитесь, что коды, написанные в одной строке, не отформатированы.
Пример:
Пожалуйста, верните старый стиль METAQUOTES или хотя бы убедитесь, что коды, написанные в одной строке, не отформатированы.
используйте стиль Pico , он очень похож на то что Вы ищете
но стиль Pico делит оператор if - else на 2 строки если используете { }
Ваш код, где используете { }
если не пользоваться { }
2133 вот такой прикол
используйте стиль Pico , он очень похож на то что Вы ищете
но стиль Pico делит оператор if - else на 2 строки если используете { }
Ваш код, где используете { }
если не пользоваться { }
Да !!! сделал полный анализ доступных стилей и выбрал PICO и RATLIFF
ПИКО самая компактная.
RATLIFF самый умный.
Но для METAQUOTES абсурдно менять стиль, который использовался годами. Это нарушит жизнь всех пользователей. Безответственное изменение. Несколько месяцев назад я испортил что-то в их стиле, я думал, что двигаться было неправильно, несмотря на небольшие изменения, но теперь они облажались.
2133 uma piada
Да !!! мы знаем, что это бета-версия, но если что-то было верно в старых версиях и теперь изменилось в бета-версии, то, скорее всего, с этими изменениями. Лучше пожаловаться сейчас, чтобы убедиться, что все идет правильно
Документация устарела в этом случае.
Сейчас ради эффективности строки преаллоцируются больше запрашиваемого, так как в подавляющем большинстве случаев они наращиваются последующими операциями.
С этим теперь понятно.
Но как не меняю длину строки, результат StringBufferLen остаётся всегда 260.
Документация устарела в этом случае.
Сейчас ради эффективности строки преаллоцируются больше запрашиваемого, так как в подавляющем большинстве случаев они наращиваются последующими операциями.
А разве в данном случае
s2 может нараститься в дальнейшем?
Результат: 260
Ожидалось: 100 или 0
Добавил в тест StringLen, и инициализировал строку по другому.
В документации одно, по факту совсем другое поведение.
И буфер в этом случае показывает 0 а не 260.
В общем или с инициализацией строк проблемы. Или StringBufferLen бажит.