поэтому мое мнение по НС и той ветке в частности остается пока тем же - делать надо те продукты, что имеют спрос и хотя бы несколько вопрошающих.
Но пока что ветка про НС в виде академического интереса. Программисты решают архитектуру сети, но при этом вообще не интересуются - а что вообще должна решать эта НС и кому она будет нужна?
Пусть лучше сделать примитив и получить фидбек от юзверей на расширение функционала, чем сейчас наворачивать архитектуру, тестить и в конце второго года иметь никому неизветсное приложение без фидбека.
Вопрос больше не в архитектуре сети, а в том, как и во что все это (или хотя бы одну сеть) обернуть, чтобы этим можно было на практике пользоваться. Какие методы и свойства должны быть у класса, чтобы было легко и удобно пользоваться. Что интересно никто не поднимал эти вопрос, все больше пошли в тему произвольного конструирования сети - еще дальше в дебри от направления практического применения.
Если, как описано в топике, ориентация на совершенствование классов MQL5, создание библиотек компонентов и RAD интерфейса. Для начала, полезно было бы реализовать возможность определения свойств и динамическое распознавание типов объектов RTTI. Думаю что эта возможность, даже при отсутствии в MQL5 перегрузки операторов, могла бы значительно повысить уровень инкапсуляции и упростить определения классов объектов, за счет переноса большинства однотипных и многоаргументных методов, соотвесчтвенно в скрытые вызовы get/set свойств и стандартные методы с одним параметром типа вызывающий объект - sender. Например это могло быть, что то наподобие:
class CMyObject: public CObject
{
protected:
double data[];
public:
void ReadData(CObject *sender)
{
if(sender != NULL)
switch(sender.GetType())
{
case CArray: // read data from array
CArray *arr = sender;
...
break;
case CFile: // read data from file
CFile *fil = sender;
...
break;
case CMyObject: // read data from object
CMyObject *obj = sender;
...
break;
default:
Print("CMyObject::ReadData invalid class ",
sender.TypeName());
break;
}
}
int DataSize
{
get { return (ArraySize(data)); }
set { ArrayResize(data, value); }
}
};
К сожалению, в текущей реализации, даже элементарное определение имени класса объекта, требует ухищьрений и выглядит коряво...
class CMyObject: public CObject
{
public:
template<typename T>
string GetTypeName(T *myobject_typ) { return(typename(T)); }
string TypeName() { return(GetTypeName(GetPointer(this))); }
};
Сделал. Насчет "подумать". Можно не по таймеру сделать, а по движению мышкой "вниз-верх-вниз-верх" раза два три, по аналогии с 7 виндой где если потрясти окошко, показывается рабочей стол.
Мне кажется, не самая хорошая идея - менять масштаб графика автоматически.
Всегда есть кнопки + и - (и левая рука), и можно, например, скролл переключить на масштабирование, если тянется стоп (для тех, кто левой рукой делает что-то другое).
поэтому мое мнение по НС и той ветке в частности остается пока тем же - делать надо те продукты, что имеют спрос и хотя бы несколько вопрошающих.
Но пока что ветка про НС в виде академического интереса. Программисты решают архитектуру сети, но при этом вообще не интересуются - а что вообще должна решать эта НС и кому она будет нужна?
Пусть лучше сделать примитив и получить фидбек от юзверей на расширение функционала, чем сейчас наворачивать архитектуру, тестить и в конце второго года иметь никому неизветсное приложение без фидбека.
К сожалению, в текущей реализации, даже элементарное определение имени класса объекта, требует ухищьрений и выглядит коряво...
Сделал. Насчет "подумать". Можно не по таймеру сделать, а по движению мышкой "вниз-верх-вниз-верх" раза два три, по аналогии с 7 виндой где если потрясти окошко, показывается рабочей стол.
Мне кажется, не самая хорошая идея - менять масштаб графика автоматически.
Всегда есть кнопки + и - (и левая рука), и можно, например, скролл переключить на масштабирование, если тянется стоп (для тех, кто левой рукой делает что-то другое).