Используете ли вы ООП в программировании на MQL4 и MQL5? - страница 8
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вы, наверное, не заметили static. static переменные доступны только в том модуле, в котором были объявлены.
Вы, наверное, не заметили static. static переменные доступны только в том модуле, в котором были объявлены.
Static и модули тут друг другу не мешают. Любая переменная доступна только в том модуле, в котором объявлена. В данном случае - как я понял, на глобальном уровне.
А проблема этого static в том, что представь (давай на "ты"), что в своих модулях такую же переменную объявили все трое. При сливании кодов - эта переменная будет размещена в ОДНОЙ области памяти.
Static - это хороший инструмент, но использовать его надо с осторожностью.
Это неправда. В каждом модуле будет свое объявление static переменной (возможно даже разных типов) и каждый модуль будет оперировать своей собственной, модификация которой не будет влиять на другие из других модулей. Вася пишет 1.c, Маша 2.c, никаких конфликтов там не будет.
Это если мы говорим о члене класса, причем, классы - называются по-разному. Но из представленного кода это не следует.
Видно, что объявлена глобальная перменная static-типа, значит, она будет занимать одно и то же место, хотя объявляться может в разных местах несколько раз.
И даже если это локальная переменная, объявленная в разных модулях - она также будет занимать одну и ту же область памяти.
Очередной раз убеждаюсь в необходимости венгерской нотации, и всемерного избегания глобальных переменных... Скажем, в моей Лиге ТС только одна глобальная переменная CExpert eMainExpert; все остальные - только локальные или члены классов. Есть достаточно много static-членов класса, чаще всего это константы.
Это если мы говорим о члене класса, причем, классы - называются по-разному. Но из представленного кода это не следует.
Видно, что объявлена глобальная перменная static-типа, значит, она будет занимать одно и то же место, хотя объявляться может в разных местах несколько раз.
И даже если это локальная переменная, объявленная в разных модулях - она также будет занимать одну и ту же область памяти.
Очередной раз убеждаюсь в необходимости венгерской нотации, и всемерного избегания глобальных переменных... Скажем, в моей Лиге ТС только одна глобальная переменная CExpert eMainExpert; все остальные - только локальные или члены классов. Есть достаточно много static-членов класса, чаще всего это константы.
Нет, ну не веришь мне, посмотри в сети. Ещё раз - static глобальные переменные из разных модулей не будут пересекаться. Если по умному - то у них внутреннее связывание
Linkage
A name that denotes object, reference, function, type, template, namespace, or value, may have linkage. If a name has linkage, it refers to the same entity as the same name introduced by a declaration in another scope. If a variable, function, or another entity with the same name is declared in several scopes, but does not have sufficient linkage, then several instances of the entity are generated.
The following linkages are recognized:
- internal linkage. The name can be referred to from all scopes in the current translation unit.
Any of the following names declared at namespace scope have internal linkage:Я считаю, глобальные переменные нужно хотя бы именовать так, чтобы в коде было понятно, что это глобальная переменная, а не локальная. Я обычно использую префикс из двойного подчёркивания: int __time;
Хотя все такие переменные обычно лишь для служебного пользования (например, использую как временный буфер в различных конструкциях из макросов)
Советую посмотреть на себя в зеркало и задать такой вопрос: "кто я такой" и быть чуть-чуть поскромнее и не показывать свою безграмотность.
Наоборот, наследование создает кучу проблем с поддержкой кода, да и ситуация когда можно так сгруппировать функции чтобы была общая наследуемая часть - редкая. Да и читаемость кода сразу падает на порядок, цепочку наследования нужно держать в голове либо постоянно освежать в памяти чтобы не забыть. Выглядит как бесполезная вещь.
Ограничение доступа тоже миф, и это скорее несет вред чем пользу так как становится невозможно передавать переменные из одного класса в другой.
Был тут аргумент что бывает когда программист не трезв и может взять "не те" переменные, ну дык он может с таким же успехом попортить код в других местах.
Кому как?! Без плана даже трезвый архитектор не построит дом; что-нибудь да забудет?! Есть даже писатели, которые начинают писать свои романы без плана и эти романы не скончаемые и всегда просят продолжения в своем повествовании. Все предельно ограничено во времени и месте. Спросите множество людей о произошедшей ситуации и каждый ее будет описывать и дополнять по своему. Так что тут, все дело в психике и в отдельности - в сформированном характере человека. Кому как вздумается - пусть так и пишет. Его право.
ООП использую лишь в том случае, когда в системе программирования, например в MQL5, встроен уже готовый класс объектов и его удобно использовать в тексте своей пгм.
Я сам классы объектов не создаю. Потому что не хотел бы тратить время на выяснение, как это делать. Кроме того, я привык думать в парадигме (умное слово) процедурного программирования.
Кроме того, программирование очень сильно отвлекает от трейдинга. Хочу отвлекаться от трейдинга минимальным образом.
1. Как раз наследование для того и нужно, чтобы не держать в голове цепочку наследования.
2. И потом - как раз и ограничить доступ, чтобы не влезть и не испортить ничего.
Запросил интерфейс, в нем одни чисто виртуальные функции, ничего испортить нельзя.
1. Невозможно понять наследный класс без того чтобы знать что откуда взялось. Создается головная боль на пустом месте
2. Баги интерфейса добавляются к багам кода плюс код становится нечитаемым. Дайте такой код людям и увидите что все будут плеваться и чертыхаться.