Результаты выполнения показывают, что компилятор действует вопреки логике:
Для константной строки памяти выделяется больше чем нужно (ее длину увеличить будет нельзя принципиально )
Для неконстантной строки дополнительной памяти не выделяется (при увеличении ее длины, потребуется новое распределение памяти)
Если пользователь инициализирует строку через StringInitInit, то памяти выделяется больше, чем нужно, потому что размер буфера пользователем задан явно и в подавляющем большинстве случаев он не будет увеличен (пользователь уже сам подумал какой конечный буфер ему нужен и задал его размер явно)
Для чистой константной строки размер буфера по StringBufferlen=0, что означает константность строки:
string s1 = "_"; // исходное "чистое" присвоение константной строки
Print(StringBufferLen(s1)); // показывает 0 верно, не должно быть 260
Перекладка "якобы" константной строки не является работой с константой, а создается именно динамическая переменная с преаллокацией в 260 символов:
conststring s2 = s1; // динамическое создание переменной копированием данных из другой переменной (не константной строки)
Print(StringBufferLen(s2)); // показывает 260 верно
Потому что в нынешнем варианте функция всегда возвращает валидное время, даже если в строке содержится мусор, причём возвращается текущая дата, что особенно странно:
StringToTime("aaabbbccc") возвращает "2019.09.05 01:00:00" Разве это нормально? В таком исполнении функция вообще опасна для здоровья. Поэтому необходим вариант с проверкой на корректность.
Пока приходится парсить собственной функцией. Но проблема в том, что время может быть задано в различных форматах. А кодить все эти форматы, изобретая велосипед, не очень хочется, коль оно уже реализовано в MQL.
В принципе это касается и других функций преобразования строк: StringToInteger, StringToDouble. Для них тоже не предусмотрено проверки валидности.
p.s. Хм, оказывается GetLastError() выдаёт ошибки в этих случаях. Вот уж не не знал. В документации по этим функциям ничего такого не сказано. Тогда проблема снимается. Хотя через bool было бы проще.
Свойства программы в файле проекта имеют приоритет над свойствами, указанными в исходном коде. Если вы укажете свойства и в проекте, и в исходном коде, будут использоваться свойства из проекта.
MetaEditor позволяет удобно работать над большими проектами: объединять множество файлов в одну структуру, управлять настройками проекта и вести совместную разработку с командой программистов через версионное онлайн-хранилище MQL5 Storage. Что такое проект Проект — это отдельный файл с расширением "MQPROJ", в котором хранятся настройки...
Стилизатор позволяет быстро привести оформление исходного кода к рекомендуемому стандарту. Это делает код легко читаемым, выглядящем профессионально. Грамотно оформленный код гораздо проще читать и анализировать в последующем как его автору, так и другим пользователям. Чтобы запустить стилизатор, нажмите " Стилизатор" в меню "Сервис" или...
Результаты выполнения показывают, что компилятор действует вопреки логике:
Для чистой константной строки размер буфера по StringBufferlen=0, что означает константность строки:
Перекладка "якобы" константной строки не является работой с константой, а создается именно динамическая переменная с преаллокацией в 260 символов:
Для чистой константной строки размер буфера по StringBufferlen=0, что означает константность строки:
Перекладка "якобы" константной строки не является работой с константой, а создается именно динамическая переменная с преаллокацией в 260 символов:
пора вводить аллокаторы )))
Напоминаю, что есть баг со строковым буффером:
Функция из ДЛЛки может быть любая.Предлагаю добавить в MQL расширенный вариант функции StringToTime в виде:
Потому что в нынешнем варианте функция всегда возвращает валидное время, даже если в строке содержится мусор, причём возвращается текущая дата, что особенно странно:
StringToTime("aaabbbccc") возвращает "2019.09.05 01:00:00" Разве это нормально? В таком исполнении функция вообще опасна для здоровья. Поэтому необходим вариант с проверкой на корректность.
Пока приходится парсить собственной функцией. Но проблема в том, что время может быть задано в различных форматах. А кодить все эти форматы, изобретая велосипед, не очень хочется, коль оно уже реализовано в MQL.
В принципе это касается и других функций преобразования строк: StringToInteger, StringToDouble. Для них тоже не предусмотрено проверки валидности.
p.s. Хм, оказывается GetLastError() выдаёт ошибки в этих случаях. Вот уж не не знал. В документации по этим функциям ничего такого не сказано. Тогда проблема снимается. Хотя через bool было бы проще.Поддерживаю предложение Алексея, безопасная работа со строками, залог исключения скрытых ошибок.
ошибка "property already exists with different value and will be skipped".
Использовал впервые. Ни в одном файле еë больше нет. От значения не зависит. Билд 2136.
Пожалуйста верните старый стиль стилизатора.
Теперь не могу понять, что же здесь должно выполняться:
Раньше этот кусок выглядел так:
ошибка "property already exists with different value and will be skipped".
Использовал впервые. Ни в одном файле еë больше нет. От значения не зависит. Билд 2136.
Такая ошибка возникает при работате с проектами - если значения свойства, указанное в исходном коде конфликтует со значением в настройках проекта.
Свойства проекта
Пожалуйста верните старый стиль стилизатора.
Теперь не могу понять, что же здесь должно выполняться:
Раньше этот кусок выглядел так:
Множественные вложенные if не спасти никакими выравниваниями. Нужно код менять, чтобы его можно было читать.
Множественные вложенные if не спасти никакими выравниваниями. Нужно код менять, чтобы его можно было читать.
Нет никаких множественных вложений - на верхнем уровне if, затем if else.
Я прошу вернуть старый стиль, когда if else выглядел так:
- был в одну строку и не было смещения последующего текста вправо.
Вот пример из справки Условный оператор if-else (старый стилизатор)
и вот что творит новый стилизатор: