1. Всё же лучше сразу вести разговор о чём-либо там, где это "что-то-либо" находится, а не думать как бы сделал модератор. А то действительно всё расплылось по двум веткам, и теперь, даже если модератор решит, что обсуждение должно быть там-то, или там-то, то нормально перенести обсуждение с сохранением очерёдности постов и их смысла, является весьма трудоёмким занятием.
2. Обсуждение действий модератора - это не каждый чих... Это если начинается всеобщее и публичное оспаривание его действий, причём действий по наведению порядка или утихомириванию разбушевавшихся. А если у вас есть своё мнение, то кто ж вам его запрещает выразить? Может ваше мнение является весьма рациональным предложением, а вы боитесь его сказать, дабы не попасть под нелюбимое меню модератора? Так сиё чушь :)
Спасибо за пояснение. Я посчитал, что обсуждение лучше вести в отдельной ветке, чтобы не зафлуживать предположительно ценную информацию в основной. Если решите перенести посты, буду обсуждать там, куда перенесете.
Вы, вроде бы, пока не модератор, чтобы определять, в какой ветке что более уместно. А модераторы уже четко обозначили, что обсуждения особенностей нужно вести не в ветке самих особенностей, а в отдельной ветке, т.е. здесь.
В Вашем описании вообще не понятно, как единообразно обращаться к методу класса по ссылке и по значению типа T. Не знаю, о чем идет речь у Вас, но у меня там шла речь именно об этом.
Здесь вот какая ситуация: я понял, что не всё можно подогнать под особенности те, которые участники форума ожидают видеть в той ветке. Здесь идёт обсуждение (и там оно шло, потому и перенёс сюда) достаточно специфичной темы, которую я решил выделить в отдельную ветку. Пусть там будут более общие и понятные большинству особенности, а здесь - классы, хитрые приёмы работы с ними, в том числе макросы (та ещё головоломка для многих).
Спасибо за пояснение. Я посчитал, что обсуждение лучше вести в отдельной ветке, чтобы не зафлуживать предположительно ценную информацию в основной. Если решите перенести посты, буду обсуждать там, куда перенесете.
Пусть теперь уж так всё остаётся. Просто - по возможности - скопируйте от-туда обсуждаемый пример в свой пост, который относится к тому примеру (мне трудно разобраться с чего тут это началось). Ну или, если уже не можете править свой пост, то в личке скажите мне откуда куда что вставить.
Пусть теперь уж так всё остаётся. Просто - по возможности - скопируйте от-туда обсуждаемый пример в свой пост, который относится к тому примеру (мне трудно разобраться с чего тут это началось). Ну или, если уже не можете править свой пост, то в личке скажите мне откуда куда что вставить.
Я уже скопировал сюда код из той ветки пару постов назад поэтому имхо дополнительных действий не требуется.
Апдейт на тему интерфейсов через шаблоны и статики. Точнее не интерфейсов, а скажем так удобно параметризуемых операций над произвольными типами, реализуемых через внешние классы. В данном случае сравнение (Comparer) и приведение типов (Caster)
Учел частично предыдущую критику, класс "интерфейса" (хотя это не интерфейс) не наследуется от класса параметра (такая метода не прижилась...), и без использования dynamic_cast разумеется. Надеюсь, что эта модель будет выглядеть логичнее.
#property strict#define tnm typename#define ttt template<tnm T>
#define ttf template<tnm F>
#define ttr template<tnm R>
#define tft template<tnm T,tnm F>
#define up(P) (CheckPointer(P)!=POINTER_INVALID)
enum ECMP{ EQUAL=0, GREATER=1, LESSER=-1, UNDEF=INT_MAX };
//+------------------------------------------------------------------+//| |//+------------------------------------------------------------------+
ttt class Type
{
private:
T item;
public:
Type(){ ZeroMemory( item ); }
Type *operator= (T par){ item = par; return &this; }
T Get(){ return item; }
ttf intoperator!= ( Type<F>&par )
{
int r = Comparer< Type< T > *, Type< F > * >::Get().Compare( &this, &par );
if( r == UNDEF ) printf("Cannot compare %s to %s!",tnm(T),tnm(F));
else{
printf("%s (%s) to %s (%s) is %s",
Caster<Type<T>*,string>::Get().Cast(&this), tnm(T),
Caster<Type<F>*,string>::Get().Cast(&par), tnm(F), Caster<ECMP,string>::Get().Cast((ECMP)r)); }
return r;
}
};
//+------------------------------------------------------------------+//| |//+------------------------------------------------------------------+
tft class Comparer
{
private:
static Comparer *handle;
public:
Comparer(){ if( handle == NULL ) handle = &this; }
static Comparer *Get(){ return handle ; }
virtual ECMP Compare( T, F ){ return UNDEF; }
};
//---
tft Comparer *Comparer::handle=NULL;
tft class Caster
{
private:
static Caster *handle;
public:
Caster(){ if( handle == NULL ) handle = &this; }
static Caster *Get(){ return handle ; }
virtual F Cast( T ){ F r; ZeroMemory(r); return r; }
};
//---
tft Caster *Caster::handle=NULL;
ttt class ToStrCaster: public Caster<T,string>
{
public:
virtualstring Cast( T ){ return"N/A"; }
};
//+------------------------------------------------------------------+//| |//+------------------------------------------------------------------+class CmpIntToInt: public Comparer<Type<int>*,Type<int>*>
{
public:
virtual ECMP Compare( Type<int>* op1, Type<int>* op2 ){ return ECMP(up(op1)&&up(op2)?(op1.Get()>op2.Get())-(op1.Get()<op2.Get()):UNDEF); }
}
citi;
class CmpDoubleToDouble: public Comparer<Type<double>*,Type<double>*>
{
public:
virtual ECMP Compare( Type<double>* op1, Type<double>* op2 ){
return ECMP(up(op1)&&up(op2)?int(op1.Get()-op2.Get()>DBL_EPSILON)-int(op2.Get()-op1.Get()>DBL_EPSILON):UNDEF); }
}
cdtd;
class CmpStrToStr: public Comparer<Type<string>*,Type<string>*>
{
public:
virtual ECMP Compare( Type<string>* op1, Type<string>* op2 ){
return ECMP(up(op1)&&up(op2)?StringCompare(op1.Get(),op2.Get()):UNDEF); }
}
csts;
//+------------------------------------------------------------------+//| |//+------------------------------------------------------------------+class IntToStrCaster: public ToStrCaster<Type<int>*>
{
public:
virtualstring Cast( Type<int>* par ){ return up(par)?IntegerToString(par.Get()):NULL; }
}
itsc;
class DoubleToStrCaster: public ToStrCaster<Type<double>*>
{
public:
virtualstring Cast( Type<double>* par ){ return up(par)?DoubleToString(par.Get(),6):NULL; }
}
dtsc;
class StringToStrCaster: public ToStrCaster<Type<string>*>
{
public:
virtualstring Cast( Type<string>* par ){ return up(par)?par.Get():NULL; }
}
stsc;
class ECMPToStrCaster: public ToStrCaster<ECMP>
{
public:
virtualstring Cast( ECMP par ){ returnEnumToString(par); }
}
etsc;
//+------------------------------------------------------------------+//| |//+------------------------------------------------------------------+voidOnStart()
{
Type<int> t1=AccountNumber(), t2=AccountLeverage();
Type<double> t3=Ask, t4=Bid;
Type<string> t5=_Symbol;
t1!=t2;
t4!=t3;
t5!=t5;
t1!=t3;
t2!=t5;
}
еще не определился с количеством входных переменных ( input ), устал править выделенный участок, макрос для одной строки не проблема, а вот как размножить его на 10-15 строк не соображу не знаю
насколько реально макрос составить для такого участка кода:
еще не определился с количеством входных переменных ( input ), устал править выделенный участок, макрос для одной строки не проблема, а вот как размножить его на 10-15 строк не соображу не знаю
Только сразу говорю - на мкл не проверял, прогнал лишь через сишный препроцессор для проверки, МКЛ ведь с особенностями, если что допиливайте.
#define ARGS HLP(InDealType_) \
HLP(InVolType_), \
HLP(InVolume_), \
HLP(InPrice_), \
HLP(InVolCoeff_), \
HLP(InClosePips_), \
Mirror
#define _CAT(L, R) L##R
#define CAT(L, R) _CAT(L, R)
#define HLP(ARG) CAT(ARG, INDEX)
#define INDEX 01
EA.AddDealsSettings(ARGS);
#undef INDEX
#define INDEX 02
EA.AddDealsSettings(ARGS);
#undef INDEX
#define INDEX 03
EA.AddDealsSettings(ARGS);
#undef INDEX
насколько реально макрос составить для такого участка кода:
еще не определился с количеством входных переменных ( input ), устал править выделенный участок, макрос для одной строки не проблема, а вот как размножить его на 10-15 строк не соображу не знаю
1. Всё же лучше сразу вести разговор о чём-либо там, где это "что-то-либо" находится, а не думать как бы сделал модератор. А то действительно всё расплылось по двум веткам, и теперь, даже если модератор решит, что обсуждение должно быть там-то, или там-то, то нормально перенести обсуждение с сохранением очерёдности постов и их смысла, является весьма трудоёмким занятием.
2. Обсуждение действий модератора - это не каждый чих... Это если начинается всеобщее и публичное оспаривание его действий, причём действий по наведению порядка или утихомириванию разбушевавшихся. А если у вас есть своё мнение, то кто ж вам его запрещает выразить? Может ваше мнение является весьма рациональным предложением, а вы боитесь его сказать, дабы не попасть под нелюбимое меню модератора? Так сиё чушь :)
Спасибо за пояснение. Я посчитал, что обсуждение лучше вести в отдельной ветке, чтобы не зафлуживать предположительно ценную информацию в основной. Если решите перенести посты, буду обсуждать там, куда перенесете.
Вы, вроде бы, пока не модератор, чтобы определять, в какой ветке что более уместно. А модераторы уже четко обозначили, что обсуждения особенностей нужно вести не в ветке самих особенностей, а в отдельной ветке, т.е. здесь.
В Вашем описании вообще не понятно, как единообразно обращаться к методу класса по ссылке и по значению типа T. Не знаю, о чем идет речь у Вас, но у меня там шла речь именно об этом.
Здесь вот какая ситуация: я понял, что не всё можно подогнать под особенности те, которые участники форума ожидают видеть в той ветке. Здесь идёт обсуждение (и там оно шло, потому и перенёс сюда) достаточно специфичной темы, которую я решил выделить в отдельную ветку. Пусть там будут более общие и понятные большинству особенности, а здесь - классы, хитрые приёмы работы с ними, в том числе макросы (та ещё головоломка для многих).
Спасибо за пояснение. Я посчитал, что обсуждение лучше вести в отдельной ветке, чтобы не зафлуживать предположительно ценную информацию в основной. Если решите перенести посты, буду обсуждать там, куда перенесете.
Пусть теперь уж так всё остаётся. Просто - по возможности - скопируйте от-туда обсуждаемый пример в свой пост, который относится к тому примеру (мне трудно разобраться с чего тут это началось). Ну или, если уже не можете править свой пост, то в личке скажите мне откуда куда что вставить.
Пусть теперь уж так всё остаётся. Просто - по возможности - скопируйте от-туда обсуждаемый пример в свой пост, который относится к тому примеру (мне трудно разобраться с чего тут это началось). Ну или, если уже не можете править свой пост, то в личке скажите мне откуда куда что вставить.
Я уже скопировал сюда код из той ветки пару постов назад поэтому имхо дополнительных действий не требуется.
Я уже скопировал сюда код из той ветки пару постов назад поэтому имхо дополнительных действий не требуется.
Добро.
Апдейт на тему интерфейсов через шаблоны и статики. Точнее не интерфейсов, а скажем так удобно параметризуемых операций над произвольными типами, реализуемых через внешние классы. В данном случае сравнение (Comparer) и приведение типов (Caster)
Учел частично предыдущую критику, класс "интерфейса" (хотя это не интерфейс) не наследуется от класса параметра (такая метода не прижилась...), и без использования dynamic_cast разумеется. Надеюсь, что эта модель будет выглядеть логичнее.
насколько реально макрос составить для такого участка кода:
еще не определился с количеством входных переменных ( input ), устал править выделенный участок, макрос для одной строки не проблема, а вот как размножить его на 10-15 строк не соображу не знаю
насколько реально макрос составить для такого участка кода:
еще не определился с количеством входных переменных ( input ), устал править выделенный участок, макрос для одной строки не проблема, а вот как размножить его на 10-15 строк не соображу не знаю
Только сразу говорю - на мкл не проверял, прогнал лишь через сишный препроцессор для проверки, МКЛ ведь с особенностями, если что допиливайте.
получил выхлоп (gcc -E):
дополнительные аргументы вы/докидывать в ARGS список.
насколько реально макрос составить для такого участка кода:
еще не определился с количеством входных переменных ( input ), устал править выделенный участок, макрос для одной строки не проблема, а вот как размножить его на 10-15 строк не соображу не знаю
Пока только так придумал. Вот если бы разрабы прикрутили переменное число параметров, как в С, то короче можно сделать было бы.
Пока только так придумал. Вот если бы разрабы прикрутили переменное число параметров, как в С, то короче можно сделать было бы.
Что-то я переусложнил )).
Ну и пусть использует первый, самое оптимальное, наверное.
#define TEST(dId)Написать несколько раз TEST не проблема ведь.