Ошибки, баги, вопросы - страница 2532

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

работает все, но массивы которые будут индикаторными буферами должны быть описаны с модификатором public   

Да, понятное дело.

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

Благодарю, вопрос выяснен.

 
Если вопрос выяснен, может поможете мне? Для вас, мамонтов программирования, это как былинка...
 
Georgiy Merts:

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

по ютуб много видео смотрю, попадался канал толкового программиста, запомнилась фраза: "код должен, прежде всего, выполнять свою задачу!"....

у Вас же не работа в большом проекте? не командная работа? - Вы же знаете зачем этот член класса обьявлен и думаю сможете уж как нибудь без компилятора проконтролировать доступ к нему? ;)

 

@Ilyas,обновился билд мт4 


код который работал нормально после компиляции и запуска выдает ошибки


 
Igor Makanu:

по ютуб много видео смотрю, попадался канал толкового программиста, запомнилась фраза: "код должен, прежде всего, выполнять свою задачу!"....

у Вас же не работа в большом проекте? не командная работа? - Вы же знаете зачем этот член класса обьявлен и думаю сможете уж как нибудь без компилятора проконтролировать доступ к нему? ;)

Вообще-то доступ к членам класса лучше реализовывать через методы, а что бы меньше разыменовываний в run-time было, использовать inline с get методами.
 
Igor Makanu:

по ютуб много видео смотрю, попадался канал толкового программиста, запомнилась фраза: "код должен, прежде всего, выполнять свою задачу!"....

у Вас же не работа в большом проекте? не командная работа? - Вы же знаете зачем этот член класса обьявлен и думаю сможете уж как нибудь без компилятора проконтролировать доступ к нему? ;)

НУ НЕТ.

Код должен прежде всего - быть прозрачным и понятным, легким для поддержки. И тогда, если он не выполняет свою задачу - это будет сразу видно.

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

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

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

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

 
Vladimir Simakov:
Вообще-то доступ к членам класса лучше реализовывать через методы, а что бы меньше разыменовываний в run-time было, использовать inline с get методами.

Вот-вот. И я обычно к этом склоняюсь. У меня вобще очень редко используются паблик члены класса, везде доступ только inline-методами. Только в особых случаях, как вот с этими индикаторными массивами приходится использовать паблики...  

 
Влад:
Если вопрос выяснен, может поможете мне? Для вас, мамонтов программирования, это как былинка...

В твоем случае надо организовать цикл while(), а не for().

Проверять на какой-то признак окончания мигания.

А вот насчет того, что "мигает с переменной частотой" - что-то странно... Сходу я ошибок не вижу, должно мигать довольно часто.

Правда, я сомневаюсь в том, что это разумно - создавать и удалять графические объекты, вместо того, чтобы делать их невидимыми. Но, вроде сделать объект невидимым нельзя... Так что остается лишь удалять.

 
Georgiy Merts:

Не, безусловно, если у тебя память, как у Петера Конова - можно и не заморачиваться над разделением доступа, лупить все переменные глобальными - и пользоваться всем, чем нужно, когда хочется.

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

я обычно длинные имена функций и переменных использую, поэтому и могу прочитать, что писал ранее:

void CGrid::Scenario_01(int ordernumber)//------ Сценарий ReOpenBUY & ReOpenSELL
  {
   int set         = Order[ordernumber].StateOrderNumberSetting;
   double pr       = Order[ordernumber].StateOrderStartPrice;
   double vol      = Order[ordernumber].StateOrderLot;
   double volcoeff = dealssettings[set].volcoeff;
   double profit,openprice;
   Order[ordernumber].GetCloseOrderInfo(profit,openprice);
   double l=CalcLot(dealssettings[set].volratio,vol,volcoeff,profit);
   deal=new Cdeal(set,dealssettings[set].dealtype,l,pr,dealssettings[set].closepips,magic);
   Order.Delete(ordernumber); 
   Order.AddValue(deal);
  }
другой вопрос, что я не придерживаюсь идеально стиля ООП - не оборачиваю все в классы, использую в одной программе и процедурный стиль и ООП одновременно, мне так удобнее и быстрее программу из готовых блоков формировать, чего не хватает дописываю или модифицирую готовое под задачу
 
Vladimir Simakov:
а что бы меньше разыменовываний в run-time было, использовать inline с get методами.
inline - это пережиток, на мой взгляд.  Компилятор и сам всё прекрасно инлайнит, так что загромождать код нет необходимости. Все эти низкоуровневые примочки можно оставить в прошлом.  А в MQL данный спецификатор вообще пустышка, добавлен чисто для совместимости (не знаю только зачем, если можно было и самому объявить такой макрос)
1...252525262527252825292530253125322533253425352536253725382539...3519
Новый комментарий
Причина обращения: