Вопросы от начинающих MQL5 MT5 MetaTrader 5 - страница 192

Новый комментарий
 

Начал осваивать ООП и не могу преодолеть следующую преграду. В качестве примера следующий скрипт:

CSum result;
void OnStart()
  {
//---
  }
//+----------------------------------------+
class CSum
  {
public:
   int               Calculate(int A,int B);
  };
//---
int CSum::Calculate(int A,int B)
  {
   return(A+B);
  }

Без строки "CSum result;" компилятор не выдаёт ошибку. А с ней появляется ошибка:

Подскажите что неправильно. Вроде бы правильно объявил объект класса.

 
paladin800:

Начал осваивать ООП и не могу преодолеть следующую преграду. В качестве примера следующий скрипт:

Без строки "CSum result;" компилятор не выдаёт ошибку. А с ней появляется ошибка:

Подскажите что неправильно. Вроде бы правильно объявил объект класса.

Переменная типа CSum (result) - объявляется раньше, чем делается описание CSum, а значит, компилятору еще не известен этот тип. Вставьте CSum в самое начало файла.
 
Lone_Irbis:
А вот подскажите еще, насколько можно/стоит эксплойтить систему глобальных переменных? Можно ли таким образом перегрузить что-нибудь или упереться в какой-то лимит? Вот допустим две сотни с небольшим переменных (из которых около половины превращаются input и обратно в зависимости от того, какой кусок кода требует тестирования) и где-то десятка полтора небольших массивов на глобальном уровне - это много или мало? ^^' А если их станет раза в два-три больше в процессе допиливания системы? И если не стоит так увлекаться, есть ли какой-то более простой способ наладить обмен данными между десятком разных подсистем, многие из которых требуют результаты работы друг-друга?
Нет, не стоит. Глобальные переменные используются для других целей. Используйте классы для описания подсистем. А от использования массивов и глобальных переменных лучше вообще стоит отказаться.
 
C-4:
Переменная типа CSum (result) - объявляется раньше, чем делается описание CSum, а значит, компилятору еще не известен этот тип. Вставьте CSum в самое начало файла.
Спс, заработало. Я поместил класс в конце кода по аналогии с размещением функций. Не ожидал, что для класса такая очерёдность будет иметь значение.
 
paladin800:
Спс, заработало. Я поместил класс в конце кода по аналогии с размещением функций. Не ожидал, что для класса такая очерёдность будет иметь значение.
Да, к сожалению очередность имеет значение. Самый трудный случай, когда два класса одновременно используют друг друга. Тогда какой бы класс мы не вставили первым, второй класс будет неизвестен компилятору и он будет выдавать ошибку. В этом случае без декларации класса не обойтись. В вашем же случае, лучше выделить CSum в отдельный файл например Sum.mqh и включать его дерективой #include "Sum.mqh".
 
C-4:
Нет, не стоит. Глобальные переменные используются для других целей. Используйте классы для описания подсистем. А от использования массивов и глобальных переменных лучше вообще стоит отказаться.
Что с классами стило бы разобраться, я конечно понимаю... но по-прежнему как-то лень, учитывая что без них привычнее и вроде как работает в любом случае. Но просто любопытно, в чем их преимущество? При условии, что заведомо известно, что код пишется одним автором исключительно для себя и никому никогда не пригодится за пределами конкретной программы? Как-то всегда казалось, что с классами есть смысл заморачиваться только если пишешь для кого-то/с кем-то/на продажу, а для себя в качестве хобби разницы особой не будет. Помимо эстетики и общей "так положенности", есть какой-то практический смысл лезть во все эти классы-структуры? Быстродействие? Еще что-то?
 
Lone_Irbis:
Что с классами стило бы разобраться, я конечно понимаю... но по-прежнему как-то лень, учитывая что без них привычнее и вроде как работает в любом случае. Но просто любопытно, в чем их преимущество? При условии, что заведомо известно, что код пишется одним автором исключительно для себя и никому никогда не пригодится за пределами конкретной программы? Как-то всегда казалось, что с классами есть смысл заморачиваться только если пишешь для кого-то/с кем-то/на продажу, а для себя в качестве хобби разницы особой не будет. Помимо эстетики и общей "так положенности", есть какой-то практический смысл лезть во все эти классы-структуры? Быстродействие? Еще что-то?

Как раз-таки наоборот. Когда пишешь на заказ, часто заказчик требует исходники. И тут придётся из классов выдёргивать функции и вставлять их в исходный код. Лучше всё же заказчику передавать работу одним файлом, а не тянуть вслед за ним гору своих библиотек, в которых находятся огромное множество не используемых функций в передаваемой заказчику работе. Т.е., на заказ лучше пользоваться структурным программированием.

Для себя же любимого лучше пользовать ООП - там всё своё, и не нужно заморачиваться при передаче исходника.

 
artmedia70:

Как раз-таки наоборот. Когда пишешь на заказ, часто заказчик требует исходники. И тут придётся из классов выдёргивать функции и вставлять их в исходный код. Лучше всё же заказчику передавать работу одним файлом, а не тянуть вслед за ним гору своих библиотек, в которых находятся огромное множество не используемых функций в передаваемой заказчику работе. Т.е., на заказ лучше пользоваться структурным программированием.

Для себя же любимого лучше пользовать ООП - там всё своё, и не нужно заморачиваться при передаче исходника.

Хм... Ну, возможно, и так :) То есть принцип, конечно, соблазнительно выглядит... в теории. Особенно учитывая, что единого файла у меня и без всяких структур и классов не получается. Дело в том, что я пишу в основном из интереса, проверяя свои собственные случайные теории и изобретая бесконечные велосипеды. Параллельно изучая только то, что начинает требоваться для реализации задумки. Происходит все это в рамках одного учебно-экспериментального эксперта - изначально простейшего мартина, а ныне уже скорее многофункционального скальпера в зародыше (и уже сейчас теоретически прибыльного). Так вот, в какой-то момент робот стал банально слишком большим. >.> Когда большая часть времени стала уходить тупо на прокручивание колеса мыши в поисках нужного куска кода, пришла мне в голову "гениальная" идея порубить его на отдельные файлы (13 подключаемых кусков на данный момент), просто сгрупировав функции по их общему концепту. Ну типа парсер новостей сюда, обработку уровней туда, еще один с контроллерами лосей, статистика отдельно и т.д. Но на большее моего энтузиазма разбираться с ООП на тот момент не хватило...

То есть беда моя, видимо, в том, что я просто хватаюсь за каждую пришедшую в голову идею, и допиливаю ее поверх уже существующего робота в довольно... хаотичной последовательности. Результат получается довольно странным и изобилующим всякими переключателями разных режимов и их сочетаний, многие из которых заброшены недоделанными. Картину дополняют стотыщпиццот глобальных переменных, которые приходится снимать из input'ов просто чтобы не отнимали так много времени, отпечатываясь в начале в визуализаторе тестера. Плюс, естественно, горы мусора и рудиментов заброшенных или переделанных задумок. 

И тут, казалось бы, самое время разгрести всю эту груду хлама и пораспихать все по классам (а сначала прочитать до конца хоть одну статью по ООП, не заснув в процессе)... но вот как-то смущает объем предстоящей работы и, гм, ее соотношение к потенциальному смыслу все это затевать. То есть заключить все в классы - вроде не такая объемная задача... Но будет ли смысл, если, к примеру, просто тупо сгрузить все подряд в public, игнорируя все эти private/protected за ненадобностью? Чем это лучше, чем просто иметь папку с горсткой .mph, по десятку обычных функций на каждый, если так или иначе они все сводятся в одном и только одном роботе?

 
Lone_Irbis:

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

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

Таким образом вы наведёте-таки порядок у себя.

 
К сожалению даже формально изучив ООП Вам не удастся построить ООП-программу. Здесь скорее требуется вникнуть в философию этого подхода, а это уже следующий после получения формальных знаний уровень. Вот и получается, а надо ли это Вам? Но если  задаете вопросы как лучше сделать, значит чувствуете что выбранный Вами путь не оптимален. В любом случае выбор за Вами.
1...185186187188189190191192193194195196197198199...1541
Новый комментарий
Причина обращения: