Прощаи робот-да здравствует маразм - страница 10
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Sr. Pansa! Porqué no usa el botón SRC para poner su código? Así mejor o Ud. tiene alguna duda?
Buena suerte!
хочу спросить где вы берете SRC?
панса
Привет,борилунад!
хочу спросить где вы берете SRC?
панса
Когда отвечаете, посмотрите чуть-чуть наверх и слева от видео увидите кнопку SRC! Нажмите её и откроется периметр для вставки кода! Удачи!
Кстати, очень точно и "красноречиво" указано место SRC Константином!
Я так понимаю, что после знакомства со статическими анализаторами у некоторых будет истерика.
Но только после этого наступает понимание, что должен (именно должен) делать компилятор. Сейчас 2014 год, а обычные компиляторы по уровню контроля качества отстают лет на 10 минимум и концентрируются лишь на оптимизациях.
Для информации: интеловый С++ компилер еще не отошел от своих болячек - постоянно выдает internal compiler error на наших проектах. То есть, не пережевывает больших проектов и выдает свои собственные ошибки. Да и мифы про его экстраординарные оптимизирующие свойства уже устарели - все остальные подтянули свой уровень оптимизации здорово.
На таком опасном и самоубийственном языке как С++, дается столько ключей и отключей компиляции для того, чтобы во всем уверенные программисты могли скомпилировать тонны старинного и скопированного неизвестно откуда кода без нервных судорог :)
Компилятор в первую очередь должен компилировать, а не анализировать, причём, компилировать он должен, весьма желательно, с хорошим качеством, а для этого, как правило, от него также требуется гибкость и настраиваемость.
Статический анализатор кода и другие подобные инструменты разумно выполнять в виде отдельных утилит, от которых при такой организации можно добиться более высокого качества выполнения их функций по сравнению с реализацией их функциональности в компиляторе.
Разумно иметь понимание, что статический анализ кода и прочие подобные полезные действия помогают обнаружить лишь часть ошибок, - тех, что связаны как с невнимательностью, так и с низкой квалификацией программиста. Ошибки дизайна, логические ошибки, ошибки типа "забыли реализовать" и прочие подобные ошибки ни статическим анализатором, ни прочими подобными инструментами не обнаруживаются. Что как раз заметно и по MT4.
В своё время и Microsoft'овский компилятор легче "ложился" из-за внутренних ошибок. Более новые версии работают устойчивее, в том числе и у Intel'а. Что же касается оптимизации, то обычно не нужно чего-то экстраординарного, - достаточно просто хорошей, добротной оптимизации, а у Intel'а она выполнена на основе глубокого понимания архитектуры и механизмов работы собственных процессоров. Странно было бы предполагать, что у Intel'а она окажется хуже, чем у других.
Ключи компиляции в первую очередь нужны для гибкой настройки компилятора под требования (частей) проекта, а опции для облегчения компиляции старинного кода - просто дополнительный бонус.
Если язык C++ настолько опасен и самоубийственен, то - зачем тогда ранний MQL4, базировавшийся на C, был "усовершенствован" до MQL4++ и MQL5, базирующихся именно на C++?
simpleton:
Разумно иметь понимание, что статический анализ кода и прочие подобные полезные действия помогают обнаружить лишь часть ошибок, - тех, что связаны как с невнимательностью, так и с низкой квалификацией программиста. Ошибки дизайна, логические ошибки, ошибки типа "забыли реализовать" и прочие подобные ошибки ни статическим анализатором, ни прочими подобными инструментами не обнаруживаются. Что как раз заметно и по MT4.
Тестовые среды широко используются в программных продуктах для функциональной верификации програмных дезайнов чипов, где требования к качеству кода очень высокие. Более того, функциональная оболочка это неотъемлемая часть разработки любого кода для проектирования чипов. При написании же обычных софтверных проектов многие программисты даже не имеют представления о подобных функциональных тестах, это связано с тем что написание подобных тестов с нуля может занять больше времени чем написание непосредственно когда проекта и оправдано лишь когда есть требование написания высококачественного кода либо планируется много версий одного и того же проекта. С другой стороны грамотно написанная тестовая среда значительно экономит время отладки и проверки кода.
Статический анализ тоже используется, но лишь как очень поверхностая и первичная проверка синтаксиса.
Simpleton, какой бред.
Когда подниметесь на уровень тотального контроля качества, только тогда это поймете. А пока остаетесь на уровне восприятия отдельного самолюбивого программиста, будете и дальше придумывать "разумно меня не контролировать, пусть контроль будет отдельными никогда не запускаемыми утилитами".
В отличие от С++, MQL абсолютно не опасен (если нет выхода в dll) за счет отказа от сырых ссылок, да и вообще - это managed язык.
В отличие от С++, MQL абсолютно не опасен
Глюки именно компилятора С++ явление весьма редкое.
Глюки компилятора MQL теперь явление постоянное (internal compiler error для MQL я видел гораааздо чаще чем для VS).
Глюки исполнения MQL кода тоже теперь явление периодическое.
С глюками боремся, но параллельно мы многое добавляем и улучшаем.
В пятницу как раз будет релиз MT4 с явными улучшениями в скорости исполнения и тестирования.