Ошибки, баги, вопросы - страница 1572

[A100]

MT4/950/32. Потеря цифр при смене профиля

 

Меняю профиль через иконку панели инструментов - сразу происходит потеря цифр на ценовой шкале (рисунок слева). Далее при смене графика путем выбора другой вкладки - цифры восстанавливаются (рисунок справа). Windows 8.1/32. Разрешение 1024x768, пробовал также 1280x1024. Масштаб 125%. На 4-x знаках терялся один знак, на пяти - два.

 Началось это наверное сразу после увеличения размера шрифта в MT4 до MT5

[A100]

CHART_SHIFT_SIZE не работает в динамике

void OnStart()
{
        ::ChartSetInteger( 0, CHART_SHIFT, true );
        for ( int i = 50; i >= 10; i-- )
        {
                ::ChartSetDouble( 0, CHART_SHIFT_SIZE, (double)i );
                ::ChartRedraw();
                ::Sleep( 100 );
        }
}

Ожидалась динамика как в test391.ex5

[Vladimir Karputov]

Не могу выкачать из Хранилища свои файлы через редактор MT4 - получаю ошибку

2016.05.05 15:11:05.427 Storage failed to read http data (storage.mql5.com:443 read failed [12152])

[Vladimir Karputov]

Karputov Vladimir:

Не могу выкачать из Хранилища свои файлы через редактор MT4 - получаю ошибку

Причём ошибка только на одном редакторе. На этом же компьютере в другой папке MT4 и его редактор спокойно выкачивает с хранилища коды.

[coderex]

Уважаемые разработчики, введите пожалуйста пространство имен как в Си подобных языках.

[Alexey Navoykov]

Доколе ж это будет продолжаться, что после каждого обновления билда перестают компилироваться коды!  А если и компилируются, то начинают работать не так, как прежде (что ещё страшнее).  Кому нужен такой язык программирования?

Восхищаюсь терпению A100, скрупулёзно копающегося в этих багах.  Меня так уже переполняет чувство отвращения.    

Тут выше кто-то предлагал, чтоб A100 собрал тесты проверки компилятора.  Забавно однако, что этой проблемой вынуждены заниматься пользователи, а не сами разработчики компилятора.

И самое главное, что всё это - мартышкин труд по сути.   Потратить годы трудов команды программистов (и соответственно колоссальные деньги), а также годы трудов пользователей, вынужденных многократно переписывать свои коды - и всё ради чего?  Чтобы изобрести велосипед под названием "компилятор C++" (с небольшими доработками).   Вместо того, чтобы просто взять какой-либо готовый компилятор с открытым кодом (или пусть даже купить),  и за пару месяцев допилить его под свои нужды.

Но нет же, простые пути не для нас... Ведь гораздо важнее - гордо бить себя пяткой в грудь, мол мы и сами с усами, и с каждым новым билдом по капельке воссоздавать велосипед.

А что касается конкретики, полностью поддерживаю идею A100 по поводу возможности отключения оптимизации.  Сделать например режимы Debug и Release, как во многих настоящих компиляторах.

Лично я из-за этой вашей хвалёной оптимизации до сих по остаюсь на билде 1159, потому как в нём мои проекты компилируются за 2 секунды, а на последующих билдах - за 20 секунд.  А небольшой прирост в производительности мне ничего не решает.   Основная часть времени тратится на разработку и редактирование программы.

[[Удален]]

Alexey Navoykov:

Лично я из-за этой вашей хвалёной оптимизации до сих по остаюсь на билде 1159, потому как в нём мои проекты компилируются за 2 секунды, а на последующих билдах - за 20 секунд.  А небольшой прирост в производительности мне ничего не решает.   Основная часть времени тратится на разработку и редактирование программы.

Проект на 100Кб исходников компилируется меньше секунды на 1325 билде. Сплошной ООП, много виртуальных функций и перегрузок, шаблоны, указатели, модификатор const (везде, где только возможно). Без DLL и OpenCL.

 

Хотелось бы выяснить причину Ваших тормозов. Возможно, именно const помогает компилятору быстро оптимизировать. С тормозами ни разу не сталкивался. Приведите, пожалуйста, исходник из кодобазы, который тормозит.

 

Насчет своего велосипеда в виде компилятора. Брать на доработку чужой проект - есть свои плюсы и минусы. Думаю, взвесив все За и Против склонился бы изначально к своему велосипеду. Конечно, когда принималось такое решение, никто не думал, что возникнет такая засада по срокам и возможностям языка/компилятора. Некоторая переоценка своих сил или, возможно, недооценка сложности задачи. Вбухали, конечно, тучу денег на разработку велосипеда. 

[Renat Fatkhullin]

Anton Zverev:

Хотелось бы выяснить причину Ваших тормозов. Возможно, именно const помогает компилятору быстро оптимизировать. С тормозами ни разу не сталкивался. Приведите, пожалуйста, исходник из кодобазы, который тормозит.

Скорее всего у него гигантские функции в виде портянок текста.

На таких портянках оптимизатор вынужден делать много проходов, раз за разом улучшая код. Достаточно уменьшить размеры функций, чтобы скорость оптимизатора резко возросла.

Ну и на последние билды обязательно переходить, так как мы в них постоянно улучшаем и качество и скорость.

[[Удален]]

Renat Fatkhullin:

Скорее всего у него гигантские функции в виде портянок текста.

На таких портянках оптимизатор вынужден делать много проходов, раз за разом улучшая код. Достаточно уменьшить размеры функций, чтобы скорость оптимизатора резко возросла.

Ну и на последние билды обязательно переходить, так как мы в них постоянно улучшаем и качество и скорость.

Возможно, дело и в портянках. У меня их, по крайней мере, нет.

 

Как-то слышал от победителей международных олимпиад по программированию, что функции должны быть максимум на 20 строк (условных). Если больше, значит архитектурно/алгоритмически не оптимальный подход.

Когда смотришь исходники Романа Елизарова, так там немеренное количество простых функций с дикой вложенностью. И почти все до пяти строк. Сам я гусеница, по сравнению с этой интеллектуальной глыбой.... Поэтому так круто не выходит, как не старался в свое время.

[A100]

При наведении курсора на наложенные друг на друга объекты отображается описание фонового объекта вместо топового. Ярко выражено на объектах OBJ_EVENT. Вижу красный, а описание от синего.