Индикатор или Эксперт - страница 5

Новый комментарий
 
2. проблема вроде бы так не снимается - то же выражение в качестве параметра функции используется.

нет. в качестве параметров будут отдельные переменные через запятую (как в функции Print), а не их выражение.
 
нет. в качестве параметров будут отдельные переменные через запятую (как в функции Print), а не их выражение.

ОК, ясно.
Но это все же выглядит как заплатка.
Этот пункт выглядел бы интереснее:
будем работать над кодогенерацией
 
когда в одном выражении присутствуют данные разных типов, полученные не только из переменных или констант, но и возвращённые из функций, то тут никуда от временных строк не деться, как ни кодогенерируй. хотя надо стараться.
 
Наверное все так, НО

1. предлагаемая функция для слияния строк должна использоваться всегда для таких случаев?
(как будто да)
2. тогда почему бы не включить ее явно в кодогенератор?
Т.е. во всех таких случаях (присваивание строкового выражения) в кодогенераторе вместо приведенного выше текста использовать вызов этой функции.

Получаем:
1. Пользователям не требуется загромождать текст постоянным вызовом этой функции.
2. Отсутствует вероятность пользователю забыть поставить эту функцию.
3. Исчезают обращения в суппорт по поводу этой проблемы (если кто забудет функцию).
4. Эта проблема просто исчезает.

(это так, мысли вслух)
 
(это так, мысли вслух)
Если это технически реализуемо и не притянет за собой чего-то левого и ненужного, то я однозначно за.
(это тоже мысли:)
 
Наверное все так, НО

1. предлагаемая функция для слияния строк должна использоваться всегда для таких случаев?
(как будто да)
2. тогда почему бы не включить ее явно в кодогенератор?
Т.е. во всех таких случаях (присваивание строкового выражения) в кодогенераторе вместо приведенного выше текста использовать вызов этой функции.

Получаем:
1. Пользователям не требуется загромождать текст постоянным вызовом этой функции.
2. Отсутствует вероятность пользователю забыть поставить эту функцию.
3. Исчезают обращения в суппорт по поводу этой проблемы (если кто забудет функцию).
4. Эта проблема просто исчезает.

(это так, мысли вслух)

Мы постараемся все сделать прозрачно для пользователей. Надо только найти экономный способ.

Также месяца 3 назад у нас пошел паралельный проект создания нового компилятора языка MQL4 (полностью соответствует текущей версии), который лучше контролирует корректность исходного кода и генерит более качественный оптимизированный код. Вероятно, именно в этой версии будет кардинальное решение с автоматическим перевыделением мелких строк.
 
Также месяца 3 назад у нас пошел паралельный проект создания нового компилятора языка MQL4 (полностью соответствует текущей версии), который лучше контролирует корректность исходного кода и генерит более качественный оптимизированный код. Вероятно, именно в этой версии будет кардинальное решение с автоматическим перевыделением мелких строк.

Хорошо.
Главное что проблема найдена.

По новому компилятору.
Хотелось бы чтобы язык точнее соответствовал С по части области действия переменных (была такая проблема, не знаю исправлена она сейчас или нет).

И если есть еще какие-то варианты по реализации,
хотел бы обратить ваше внимание реализацию кода в языке Forth - так называемый "Шитый код".

Это очень компактный и быстрый способ кодирования.
По скорости он не сильно уступает ассемблеру.
Если есть время и возможность, посмотрите, может пригодится.
 
Хотелось бы чтобы язык точнее соответствовал С по части области действия переменных (была такая проблема, не знаю исправлена она сейчас или нет).

В новом компилере уже исправлена.

И если есть еще какие-то варианты по реализации,
хотел бы обратить ваше внимание реализацию кода в языке Forth - так называемый "Шитый код".

Ради полной совместимости новый компилятор генерит тот же код что и существующий. К тому же, мы практически генерим ассемблерный (байт код MQL4) код, который исполняется в виртульной машине MQL4.
12345
Новый комментарий
Причина обращения: