Библиотеки: ArrayEx - страница 2

[JeeyCi]

JeeyCi #:

- а ведь надо было только Компаратор переопределить в наследнике от public CObject

int elD::Compare(const CObject *node,const int mode=0)const
{
   elD *that = (elD*)node;

   // долго
   if(this._TM > that._TM || (this._TM == that._TM && this._f < that._f) )
         return 1;

   return 0;
}

однако... при Сортировке из CArrayObj::Sort по 2м полям - вылетаю в StackOverflow, а InsertSort - всё-таки долго (тоже при сортировке по 2м полям)... поэтому тема автора, в принципе, поинтереснее, чем StandardLibrary...

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

p.s. альтернативный insert_sort всё-таки ещё посмотрю... хоть на таком Компараторе и он вряд ли поможет ((

[JeeyCi]

JeeyCi #:

однако... - вылетаю в StackOverflow, а InsertSort - всё-таки долго (тоже при сортировке по 2м полям)...

)) действительно, ещё не перешла на новые рельсы -

Spaghetti code can also describe an anti-pattern in which object-oriented code is written in a procedural style, such as by creating classes whose methods are overly long and messy, or forsaking object oriented concepts like polymorphism. The presence of this form of spaghetti code can significantly reduce the comprehensibility of a system. 

Load/Save вообще не переопределила для использования, а процедурно прочитала файл... и всё-таки в ООП надо как-то поменять мировоззрение и располагать всё в куче (On Heap)... - это, конечно, скорость не увеличит, но стэк будет расходоваться более экономно... 

да и передача по указателю всегда лучше, чем global, - для сопровождаемости

p.s. и всё-равно этот язык - строго типизирован, как и C++... (( template или не-template использовать(?) для класса-контейнера...

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

хотя template_class-контейнера - тоже, наверно, вариант (для уменьшения дублирования кода)?.. но появилась эта возможность только в build_900 (22 октября 2015)... да и template-functions в простом_классе не требуют усложнений до шаблона_класса... имхо (не вижу edge всё сильно усложнять до template_class)

[Aleksey Mavrin]

JeeyCi #:

однако... при Сортировке из CArrayObj::Sort по 2м полям - вылетаю в StackOverflow, а InsertSort - всё-таки долго (тоже при сортировке по 2м полям)... поэтому тема автора, в принципе, поинтереснее, чем StandardLibrary...

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

p.s. альтернативный insert_sort всё-таки ещё посмотрю... хоть на таком Компараторе и он вряд ли поможет ((

у Вас компаратор всего лишь двухранговый , 0 или 1. Таким образом он "сортирует" лишь на две кучи, без изменения положения внутри куч, если это то что надо, ок, но кажется не совсем.

StackOverflow у вас думаю потому что либо этот нюанс, либо ИЛИ  либо ещё какая то петля в коде приводит к зацикливанию алгоритма.

ап: скорее всего из-за ИЛИ, вот это всё условие

if(this._TM > that._TM || (this._TM == that._TM && this._f < that._f) )

постоянно пересортирует, если поля _ТМ и _f как-то неудачно коррелируют 

ап2: правильней вам надо разницу полей привести к инту, а вторичное поле сделать на порядок меньше первого.

double V1=this._TM-that._TM;
double V2=this._f-that._f;
while(V1<1)
        V1*=10;
while(V2<1)
        V2*=10;
V1*=10;
return(V1+V2);// or V1-V2

[JeeyCi]

Aleksey Mavrin #: правильней вам надо разницу полей привести к инту,

интересный hacker-trick, попробую... спасибо!

Aleksey Mavrin # :   а вторичное поле сделать на порядок меньше первого.

у меня _TM -это datetime (можно перевести в unix), а _f это int (1 или 2), возможно, ещё будет _f2 (от 1000 до 10000) - но в любом случае на несколько порядков меньше, чем unix_time... имхо (но если порядки не будут разные, то тоже интересный hacker-trick) - спасибо!

Aleksey Mavrin # :  .либо ещё какая то петля в коде

да нет, наверно, потому что объекты сортировала, а не pointers на них... не доглядела, что CArrayObj- это всё-таки "динамический массив указателей на экземпляры класса CObject ", хоть и пример по линку из #10 на указатели такой же, как и на сами объекты...

p.s. ф-я Group у автора ArrayEx тоже интересная - но чтобы в отсортированном массиве делать Sum с проверкой на принадлежность к группе - придётся проверку  делать 

if (!arr_src[i]=arr_src[i+1]) arr_dest[next]=new Sum_element  // условно

 -- как-то  if'ы на каждом экземпляре класса мне тоже пока кажутся не совсем оптимальными, но более ювелирного алгоритма Group_Sum пока тоже не вижу, даже если подрядить StdLib ??

(я на MQL4! - Dictionaries - CHashMap , CSortedMap  - [IMap] у меня нет)

[JeeyCi]

JeeyCi #:
   

(я на MQL4! - Dictionaries - ... - [IMap] у меня нет)

хотя на GitHub обычно что-то есть - или самостоятельно можно include'ы из mql5 подправить - но не хочется мне пока лезть в дебри template_class... а вот UML всегда в помощь для ООП