Любые вопросы новичков по MQL4 и MQL5, помощь и обсуждение по алгоритмам и кодам - страница 1591

 
Maxim Kuznetsov:

со static в mql всё запущено и чревато ошибками. Код всегда собирается/компилируется целиком, без промежуточных obj и декларация статик просто дань традиции. 

если человек использует static в mql - то он почти 100% из мира C/C++/C# ; или подсматривал и нелепо подражает :-)

а ведь есть ещё и __thread__ :-)

Если писать static в модуле, а не в функциях, то да. Кодер скорее всего не ведает что творит. :) А вот относительно локальных переменных функций и, локальных переменных методов классов, а также полей классов, то даже очень нужная вещь на мой взгляд.

А ошибки могут возникать из-за непонимания концепции static переменных и неправильного их использования, как следствие этого.
 
MakarFX:

после

добавь

не помогло) куда только не ставил)

 
Mihail Matkovskij:

Если писать static в модуле, а не в функциях, то да. Кодер скорее всего не ведает что творит. :) А вот относительно локальных переменных функций и, локальных переменных методов классов, а также полей классов, то даже очень нужная вещь на мой взгляд.

с именованиями вообще всё наглухо плохо..способ разрешения простых конфликтов имён - добавлять фигню m_   a_  к сущностям, потому что компилер не умеет в scope и ругается.

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

какой тут уж static :-)

извините, НАГОРЕЛО

 
законопослушный гражданин:

не помогло) куда только не ставил)

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

Я тебе расписал весь советник очень доступно, даже для начинающих, если не понятно спрашивай.

Если ты хочешь чтобы тебе написали советник, то как "Законопослушный гражданин" обратись сюда

 
Maxim Kuznetsov:

с именованиями вообще всё наглухо плохо..способ разрешения простых конфликтов имён - добавлять фигню m_   a_  к сущностям, потому что компилер не умеет в scope и ругается.

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

какой тут уж static :-)

извините, НАГОРЕЛО

Задачи бывают разные и использовать static переменные только для того чтобы решить конфликт пространства имён, разумеется, не стоит (но это неточно... :)). Но вот, записать сколько создано объектов какого-то класса, можно, например. Также, статические константы, очень удобная вещь. Статические методы и т.п. Можно, конечно же делать и без static. Но всё это зависит от многих факторов. От поставленной задачи и способов её решения. Ну и конечно же от понимания программистом концепции программирования, в первую очередь.

 
Mihail Matkovskij:

Задачи бывают разные и использовать static переменные только для того чтобы решить конфликт пространства имён, разумеется, не стоит (но это неточно... :)). Но вот, например, записать сколько создано объектов какого-то класса, можно, например. Также, статические константы, очень удобная вещь. Статические методы и т.п. Можно, конечно же делать и без static. Но всё это зависит от многих факторов. От поставленной задачи и способов её решения. Ну и конечно же от понимания программистом концепции программирования, в первую очередь.

а теперь возьмите какую-нить библиотеку и #include её к себе..

поимеете кучу конфликтов на ровном месте. Хотя-бы просто потому что как два разумных человека, вы и автор, называли одно и то-же одним и тем-же. В простеньком советнике input double SL - и простыня предупреждений.

Как блин как надо назвать стоп лосс чтобы он гарантированно ни с кем не совпадал (sic!, c именами параметров методов), если он называется стоп-лосс и означает именно это ?

Ооо ! решение - inp_SL...и m_SL и a_SL от видимости... пусть разработчики таскают мета-данные и области определения в именах. 

чё-то ни к место зол...

 
Maxim Kuznetsov:

а теперь возьмите какую-нить библиотеку и #include её к себе..

поимеете кучу конфликтов на ровном месте. Хотя-бы просто потому что как два разумных человека, вы и автор, называли одно и то-же одним и тем-же. В простеньком советнике input double SL - и простыня предупреждений.

Как блин как надо назвать стоп лосс чтобы он гарантированно ни с кем не совпадал (sic!, c именами параметров методов), если он называется стоп-лосс и означает именно это ?

Ооо ! решение - inp_SL...и m_SL и a_SL от видимости... пусть разработчики таскают мета-данные и области определения в именах. 

чё-то ни к место зол...

Я редко использую стронные библиотеки, поскольку меня в них редко всё устраивает. Предпочитаю создавать свои. Но могу использовать стороннюю библиотеку, только в случае если нужно создать то, что уже и так давно много раз придумано до меня. И то, такие сторонние библиотеки часто приходится допиливать (то ошибка внезапно выскочит, то не хватает нужных функций или методов). А если слишком много таких конфликтов как вы описали, то лучше поискать другую библиотеку. Ну или поменять имена с помощью автоматической замены, в самом крайнем случае. Но я бы не стал это делать.

 
MakarFX:

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

Я тебе расписал весь советник очень доступно, даже для начинающих, если не понятно спрашивай.

Если ты хочешь чтобы тебе написали советник, то как "Законопослушный гражданин" обратись сюда

не- не хочу. я хочу разбираться сам.

в справочнике по MQL немного не моим языком написано, вот я и не понимаю некоторых вещей.а советник да, действительно с пояснениями спасибо.

 
Maxim Kuznetsov:

а теперь возьмите какую-нить библиотеку и #include её к себе..

поимеете кучу конфликтов на ровном месте. Хотя-бы просто потому что как два разумных человека, вы и автор, называли одно и то-же одним и тем-же. В простеньком советнике input double SL - и простыня предупреждений.

Как блин как надо назвать стоп лосс чтобы он гарантированно ни с кем не совпадал (sic!, c именами параметров методов), если он называется стоп-лосс и означает именно это ?

Ооо ! решение - inp_SL...и m_SL и a_SL от видимости... пусть разработчики таскают мета-данные и области определения в именах. 

чё-то ни к место зол...

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

Генератор уникальных префиксов в проекте наше все))))

 

Не понимаю, почему все говорят о каких-то конфликтах имен?... Наверное, речь о процедурном программировании... На сколько я знаю, если встречается несколько таких конфликтов, то их легко решить с помощью префиксов. Всего-то делов... Зачем об этом столько писать?... :)

Плюс, уже давно, разработчики добавили такую штуку, как namespace. Не знаю как в 4-й версии, а в 5-й давно есть. Так что, не вижу такой большой проблемы.