Краудсорсовый GUI. Открытое бета-тестирование. - страница 48

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

Петр, ты ко мне можешь относиться как угодно, это твое право, но послушай совета чуть более опытного товарища.

#include <GUI_DRIVE.mqh>
#include "..\Files\CORES.mqh"
#include "..\Files\Internal_API.mqh"

Первым в коде подключается файл GUI_DRIVE.mqh. Перед ним ничего не объявлено. 

Если его компилировать самостоятельно то он выдаст ошибку отсутствия G_CORE, и это логично так как массив в этом файле не объявляется!

Вывод? Ну тут вывод элементарный: данный массив нужно объявить именно в этом файле. В конечном итоге именно этот файл и работает с этим массивом, ведь этот файл и есть "движок"! Поэтому объявление в нем самого массива является правильным, по контексту использования.

В следующем файле, CORES.mqh , производится заполнение самого массива описанием элементов формы.

Конечно при компиляции самого советника с этими файлами, если массив будет объявлен в первом файле, проблем компиляции не будет так как при компиляции второго файла массив уже будет виден контексту программы.

Но мы говорим о том, что каждый файл должен компилироваться без ошибок. Поскольку во втором файле массив G_CORE заполняется элементами то вполне естественно мы нарвемся на ошибку при компиляции этого файла если не объявим массив.

И вот тут используем, как сказал Александр, заглушку.

Петр, ты на дефайнах "собаку съел" так что поймешь сразу в чем фишка.

В файле GUI_DRIVE объявляешь глобальный массив ядра элементов G_CORE, после этого файл должен компилироваться без ошибок.

Далее в этом файле добавляешь дефайн 

#define __DRIVE__

Переходим к файлу Cores. Прежде чем объявить массив используй препроцессор компиляции

#ifndef __DRIVE__
int G_CORE[][prop_limit];
#endif

А потом заполняешь уже сам массив. Конечно тебе придется немного изменить способ заполнения массива, сделать это без объявления.

Я думаю ты уловил суть: если компилируется файл CORES, то дефайна __DRIVE__ нет и компилируется код объявления массива и далее все отрабатывает штатно.

Если файл компилируется в составе советника, тогда после компиляции первого подключенного файла объявляется дефайн и во втором файле объявление массива не происходит так как компилятор "вырежет" этот кусок кода.

Очень надеюсь что пояснил внятно.

Повторю еще раз: каждый файл должен компилироваться без ошибок. Если есть зависимости, то нужно правильно предусмотреть их расположение и добавить при необходимости процессоры перекомпиляции.

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

И еще не забывай в каждом файле добавлять свойство:

#property strict

Это свойство дает более жесткую проверку кода.

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

Короче, это столь несущественно, что тратить на это время я не буду. Это полная ерунда. Придирка.
 
Да, с помощью манипуляций с препроцессором можно сделать так, чтобы каждый файл компилировался по отдельности без ошибок. 

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

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

"Опытные" товарищи, похоже, боятся его строгого голоса и считают всегда и во всем правым. Вот и пытаются приспособится, даже если смыла в этом нет.

У меня в коде языка разметки были тысячи предупреждений, потому что перед константами нужно было ставить (sring). Представляю, на что был бы похож код, если бы перед каждым числом ставил приведение к типу. Зато, не было бы предупреждений.
 
Реter Konow:
Да, с помощью манипуляций с препроцессором можно сделать так, чтобы каждый файл компилировался по отдельности без ошибок. 

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

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

"Опытные" товарищи, похоже, боятся его строгого голоса и считают всегда и во всем правым. Вот и пытаются приспособится, даже если смыла в этом нет.

У меня в коде языка разметки были тысячи предупреждений, потому что перед константами нужно было ставить (sring). Представляю, на что был бы похож код, если бы перед каждым числом ставил приведение к типу. Зато, не было бы предупреждений.

Тут некоторые товарищи пишут делают отдельный софт который немного изменяет интерфейс самого метаедитора - для удобства использования лишь!

Этот стандарт все равно что использовать клавиатуру - вместо того чтобы набирать буквы по азбуке морза через пищялку. Заглушки ничего кроме постоянного перелистования между файлами при компиляции не чего не меняет. Но заглушка это 2 строчки кода. А сколько времени потратим на это перелистование для того чтобы просто нажать одну кнопку. И сколько раз будем так листать 7 и что становиться рациональнее дабы не тратить жизнь на набивания букв через пищалку

Заметь сейчас речь не идет ни о объектах ни о классах а просто о экономии времени. Своем времени.. Причем стандарт их написания можешь сам придумать
 
Я уж не говорю про кодирование на русском, которое по умолчанию дискриминируется англоязычной средой разработки. Тоже приспосабливаться и оставить своему мозгу жалкие 30% производительности, в то время, как на русском могу использовать все 100%?

Вот вам и цена "профессионализма".
 
Реter Konow:
Я уж не говорю про кодирование на русском, которое по умолчанию дискриминируется англоязычной средой разработки. Тоже приспосабливаться и оставить своему мозгу жалкие 30% производительности, в то время, как на русском могу использовать все 100%?

Вот вам и цена "профессионализма".

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

Но если функция ожидает целое число в таком порядке: Примем (ширина, высота). 

А в место этого мы случайно перепутали и написали 

Примем (высота, ширина) - то сам копилятор говорит о том что у нас тут перепутано. Работает ли это у Вас - тут тоже речь ни о языке и ни объектах. А просто о том чтобы потом не выискивать эту ошибку самому

 
Alexandr Andreev:

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

Но если функция ожидает целое число в таком порядке: Примем (ширина, высота). 

А в место этого мы случайно перепутали и написали 

Примем (высота, ширина) - то сам копилятор говорит о том что у нас тут перепутано. Работает ли это у Вас - тут тоже речь ни о языке и ни объектах. А просто о том чтобы потом не выискивать эту ошибку самому

Эта ветка тестирования готовых решених и доведения их до пользователей.

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

Не собираюсь обсуждать отвлеченные вопросы. Подключили собранную панель, нашли баги, сообщили? Огромное спасибо! Изображаете умников и придираетесь к тому, чего не понимаете - до свидания.
 
Господа умники, вам здесь не место.

С теми, кто не запускал редактор и не подключал панель, но "учительствует" разговор короткий.

Остальные, - добро пожаловать!
 
Алексей Барбашин:

Петр, ты ко мне можешь относиться как угодно, это твое право, но послушай совета чуть более опытного товарища.

.......

И еще не забывай в каждом файле добавлять свойство:

#property strict

Это свойство дает более жесткую проверку кода.

это под пятёрку сделано - там всегда strict!

хотя в целом согласен: куча предупреждений при компиляции не повышает доверия к коду.

 
Igor Zakharov:

это под пятёрку сделано - там всегда strict!

хотя в целом согласен: куча предупреждений при компиляции не повышает доверия к коду.

Предупреждения уберу. Временно.
1...414243444546474849505152535455...59
Новый комментарий
Причина обращения: