Ошибки, баги, вопросы - страница 1572
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Не могу выкачать из Хранилища свои файлы через редактор MT4 - получаю ошибку
Доколе ж это будет продолжаться, что после каждого обновления билда перестают компилироваться коды! А если и компилируются, то начинают работать не так, как прежде (что ещё страшнее). Кому нужен такой язык программирования?
Восхищаюсь терпению A100, скрупулёзно копающегося в этих багах. Меня так уже переполняет чувство отвращения.
Тут выше кто-то предлагал, чтоб A100 собрал тесты проверки компилятора. Забавно однако, что этой проблемой вынуждены заниматься пользователи, а не сами разработчики компилятора.
И самое главное, что всё это - мартышкин труд по сути. Потратить годы трудов команды программистов (и соответственно колоссальные деньги), а также годы трудов пользователей, вынужденных многократно переписывать свои коды - и всё ради чего? Чтобы изобрести велосипед под названием "компилятор C++" (с небольшими доработками). Вместо того, чтобы просто взять какой-либо готовый компилятор с открытым кодом (или пусть даже купить), и за пару месяцев допилить его под свои нужды.
Но нет же, простые пути не для нас... Ведь гораздо важнее - гордо бить себя пяткой в грудь, мол мы и сами с усами, и с каждым новым билдом по капельке воссоздавать велосипед.
А что касается конкретики, полностью поддерживаю идею A100 по поводу возможности отключения оптимизации. Сделать например режимы Debug и Release, как во многих настоящих компиляторах.
Лично я из-за этой вашей хвалёной оптимизации до сих по остаюсь на билде 1159, потому как в нём мои проекты компилируются за 2 секунды, а на последующих билдах - за 20 секунд. А небольшой прирост в производительности мне ничего не решает. Основная часть времени тратится на разработку и редактирование программы.
Лично я из-за этой вашей хвалёной оптимизации до сих по остаюсь на билде 1159, потому как в нём мои проекты компилируются за 2 секунды, а на последующих билдах - за 20 секунд. А небольшой прирост в производительности мне ничего не решает. Основная часть времени тратится на разработку и редактирование программы.
Проект на 100Кб исходников компилируется меньше секунды на 1325 билде. Сплошной ООП, много виртуальных функций и перегрузок, шаблоны, указатели, модификатор const (везде, где только возможно). Без DLL и OpenCL.
Хотелось бы выяснить причину Ваших тормозов. Возможно, именно const помогает компилятору быстро оптимизировать. С тормозами ни разу не сталкивался. Приведите, пожалуйста, исходник из кодобазы, который тормозит.
Насчет своего велосипеда в виде компилятора. Брать на доработку чужой проект - есть свои плюсы и минусы. Думаю, взвесив все За и Против склонился бы изначально к своему велосипеду. Конечно, когда принималось такое решение, никто не думал, что возникнет такая засада по срокам и возможностям языка/компилятора. Некоторая переоценка своих сил или, возможно, недооценка сложности задачи. Вбухали, конечно, тучу денег на разработку велосипеда.
Хотелось бы выяснить причину Ваших тормозов. Возможно, именно const помогает компилятору быстро оптимизировать. С тормозами ни разу не сталкивался. Приведите, пожалуйста, исходник из кодобазы, который тормозит.
Скорее всего у него гигантские функции в виде портянок текста.
На таких портянках оптимизатор вынужден делать много проходов, раз за разом улучшая код. Достаточно уменьшить размеры функций, чтобы скорость оптимизатора резко возросла.
Ну и на последние билды обязательно переходить, так как мы в них постоянно улучшаем и качество и скорость.
Скорее всего у него гигантские функции в виде портянок текста.
На таких портянках оптимизатор вынужден делать много проходов, раз за разом улучшая код. Достаточно уменьшить размеры функций, чтобы скорость оптимизатора резко возросла.
Ну и на последние билды обязательно переходить, так как мы в них постоянно улучшаем и качество и скорость.
Возможно, дело и в портянках. У меня их, по крайней мере, нет.
Как-то слышал от победителей международных олимпиад по программированию, что функции должны быть максимум на 20 строк (условных). Если больше, значит архитектурно/алгоритмически не оптимальный подход.
Когда смотришь исходники Романа Елизарова, так там немеренное количество простых функций с дикой вложенностью. И почти все до пяти строк. Сам я гусеница, по сравнению с этой интеллектуальной глыбой.... Поэтому так круто не выходит, как не старался в свое время.
При наведении курсора на наложенные друг на друга объекты отображается описание фонового объекта вместо топового. Ярко выражено на объектах OBJ_EVENT. Вижу красный, а описание от синего.
Проект на 100Кб исходников компилируется меньше секунды на 1325 билде. Сплошной ООП, много виртуальных функций и перегрузок, шаблоны, указатели, модификатор const (везде, где только возможно). Без DLL и OpenCL.
Хотелось бы выяснить причину Ваших тормозов. Возможно, именно const помогает компилятору быстро оптимизировать. С тормозами ни разу не сталкивался. Приведите, пожалуйста, исходник из кодобазы, который тормозит.
Ну дык 100 кб - это ж разве много? У меня почти мегабайт. Присутствует всё то же, что и у вас. Плюс к этому много макросов. Только вот const проставлено не везде. Но это не повод для таких сумасшедших тормозов. Тем более что в билде 1159 всё компилировалось почти мгновенно.
В 1325 билде я протестировать не могу, поскольку там проект вообще не компилируется, возникает целая гора ошибок, причём на ровном месте. Вон и товарищ A100 отписывался о куче появившихся багов в новом билде. У меня нет желания впустую тратить своё время на ковыряние этих багов. Подожду когда выпустят рабочий билд.
Поэтому сказанное мной про тормоза относилось к 1241 билду. Если у вас есть возможность протестировать на нём, попробуйте сравнить с последним билдом. Но я сомневаюсь, что в новом билде могли значительно ускорить. Скорее наоборот. Ведь скорость компиляции мало заботит разработчиков МТ, им бы только выжать дополнительные наносекунды в рантайме, чтоб потом делать маркетинговые заявления о быстродействии MQL программ, сравнимом с C++ (правда лишь на абстрактных примерах). А об эффективности оптимизации не заморачиваются, как я понял. Т.е. стоит ли овчинка выделки.
Поискать исходники в кодебазе - попробую, но не факт что удастся найти аналогичный. Это ведь должен быть большой проект. А там в основном небольшие поделки выкладываются в свободный доступ.
Скорее всего у него гигантские функции в виде портянок текста.
На таких портянках оптимизатор вынужден делать много проходов, раз за разом улучшая код. Достаточно уменьшить размеры функций, чтобы скорость оптимизатора резко возросла.
Ну и на последние билды обязательно переходить, так как мы в них постоянно улучшаем и качество и скорость.
Гигантских функций нет. Максимум в 150 строк (или это считается гигантской?). Да и если так рассуждать, то при чём здесь размер функции, если компилятор с таким же успехом будет перебирать кучу маленьких функций? Допустим большую функцию он пробегает 10 раз. Ну разобью я её на 5 маленьких. И каждая из них будет перебираться по 2 раза. Получаем тот же результат. Т.е. важен общий объём кода, так ведь? Но пусть даже результат чуть ускорится от дробления больших функций, что с того? Ведь речь идёт о торможении компиляции в 10 (!) раз.
Понятно ваше желание максимально ускорить выполнение программы, поэтому вы делаете кучу проходов в попытках улучшить что-нибудь. И чем дальше вы будете усложнять язык, тем дольше будут выполняться эти проходы, отнимая время у программиста. И тут закономерно встаёт вопрос об эффективности всего этого. Насколько существенно ускорение программы от вашей оптимизации по сравнению с простоем программиста, ожидающего завершения оптимизации?
Можно конечно пытаться искать какие-то компромиссы, но гораздо эффективнее сделать разные режимы компиляции, о чём я писал выше. Релиз программы со всем оптимизациями нужен только в самом конце. А 99% времени программист тратит на написание и отладку кода, когда ваши оптимизации ему даром не нужны.
Доколе ж это будет продолжаться, что после каждого обновления билда перестают компилироваться коды! А если и компилируются, то начинают работать не так, как прежде (что ещё страшнее). Кому нужен такой язык программирования?
...