std::vector<T>::iterator, оптимальное названия макроса по разыменовыванию итераторов в MQL (детали в первом посте) - страница 2

 
TheXpert:
Но само решение все равно интересно ) будет код макроса и контейнера?

Если удасться довести проект до логического конца - то весьма вероятно, что код будет предоставлен.
Проблема в том, что не смотря на всю банальность в реальности требуется достаточно много времени на его реализацию, а особенно тестирование.
Вот и получается, что вещь весьма полезная, а стимула то особого и нет, так как на MQL фактически не пишу и пользоваться не буду...

Пока что в планах:

- vector<Type, Allocator> (без менеджера инвалидации итераторов, без allocator_traits обертки);
- allocator<Type> (на динамическом массиве);
- iterators (просто кастомный RandomAccessIterator, без иерархии базовых типов итераторов);
- algorithms (хотя бы top30 - top50 функций);
- lambda functions support.

 
Sergey Dzyublik:

...на MQL фактически не пишу и пользоваться не буду...

Пока что в планах:

Странный случай. Вам, получается, заняться больше нечем?  Тут многим вынужденно приходится юзать этот MQL, изобретая адские костыли и проклиная всё это последними словами.  А вы просто так занимаетесь этим садо-мазо?   Да уж, месье знает толк в извращениях...
 
Alexey Navoykov:
Странный случай. Вам, получается, заняться больше нечем?  Тут многим вынужденно приходится юзать этот MQL, изобретая адские костыли и проклиная всё это последними словами.  А вы просто так занимаетесь этим садо-мазо?   Да уж, месье знает толк в извращениях...

А кто вас заставляет?

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

 
Alexey Navoykov:
Странный случай. Вам, получается, заняться больше нечем?  Тут многим вынужденно приходится юзать этот MQL, изобретая адские костыли и проклиная всё это последними словами.  А вы просто так занимаетесь этим садо-мазо?   Да уж, месье знает толк в извращениях...

Всегда есть альтернатива. И языку, и форуму. Или костыли, разбавленные проклинаниями - тоже некая странная разновидность филии?

 
Artyom Trishkin:

Всегда есть альтернатива. И языку, и форуму. Или костыли, разбавленные проклинаниями - тоже некая странная разновидность филии?

Люди доброе пытаются сделать. А вот поделка от СБ:

#include <Generic\ArrayList.mqh>

struct STest{
   int a;
   int b;
};


void OnStart(){
   CArrayList<STest> test;
}

Попробуйте скомпилировать)))

Кстати, все это можно решить:

template<typename T>
interface ICollection
  {
//--- methods of filling data 
   template<typename T1>
   bool      Add(T1 value);
   
   template<typename T1>
   bool      Add(const T1 &value);

...
Правда не тестировал толком.

А про r-value ссылки даже заикаться страшно)))

 
Vladimir Simakov:

Люди доброе пытаются сделать. А вот поделка от СБ:

Попробуйте скомпилировать)))

Кстати, все это можно решить:

Правда не тестировал толком.

А про r-value ссылки даже заикаться страшно)))

Кто ж против доброго? Тем более сделать. Тем более для сообщества.

Я не о Сергее говорил, и не ему отвечал.

 
Vladimir Simakov:

А про r-value ссылки даже заикаться страшно)))

В смысле про move семантику? Конечно, можно даже не мечтать.

 
Vladimir Simakov:

Кстати, все это можно решить:

Правда не тестировал толком.

Будет ошибка неоднозначности в некоторых случаях.  Да и замаетесь лазить по коду, если случайно передадите неправильный аргумент в шаблонный метод.  Без поддержки SFINAE, шаблоны - тот ещё гемор.

 
Alexey Navoykov:

Будет ошибка неоднозначности в некоторых случаях.  Да и замаетесь лазить по коду, если случайно передадите неправильный аргумент в шаблонный метод.  Без поддержки SFINAE, шаблоны - тот ещё гемор.

Не будет. При компиляции шаблонного класса с параметром типа структуры метод Add(T1 value) скомпилирован не будет, а если параметром является примитивный тип, то наоборот, не будет скомпилирован Add(const T1 &value). При этом типобезопастность сохраняется. Если отсутствует возможность неявного приведения T1 к T, то будет ошибка компиляции. Вот простой пример.

struct STest{
   int a;
   int b;
   STest():a(0),b(0){}
};

struct _STest{
   double c;
   double d;
   _STest():c(0.0),d(0.0){}
};

struct __STest:public STest{
   double c;
   double d;
   __STest():c(0.0),d(0.0){}
};

template<typename T>
class CTest
  {
  T   val;
public:
   template<typename T1>
   void Set(T1 x) {val=x;}
   template<typename T1>
   void Set(const T1 &x) {val=x;}
  };

void OnStart(){
   CTest<int> test;
   CTest<STest> _test;
   int a=9;
   test.Set(a);
   test.Set(5);
   STest b;
   _STest c;
   __STest d;
   _test.Set(b);
   _test.Set(c);  //'x' - parameter conversion not allowed      test.mq5        29      31
                  //in template 'void CTest<STest>::Set(const T1&)' specified with [T1=_STest]  test.mq5        29      9
   _test.Set(d);
}
 
Vladimir Simakov:

Не будет. При компиляции шаблонного класса с параметром типа структуры метод Add(T1 value) скомпилирован не будет, а если параметром является примитивный тип, то наоборот, не будет скомпилирован Add(const T1 &value). При этом типобезопастность сохраняется. Если отсутствует возможность неявного приведения T1 к T, то будет ошибка компиляции. Вот простой пример.

Попробуйте передать const int.

А насчёт ошибки компиляции - так вы обратите внимание, в каком месте она возникает. И как вы собираетесь искать первоисточник ошибки.  Здесь то у вас всё очевидно, т.к. весь код перед глазами. А если ваш проект содержит кучу файлов, и данный метод вызывается из сотен мест в программе?  Причём он мог быть вызван не напрямую, а опосредовано, из других шаблонов. Т.е. чтобы добраться до сути, придётся разматывать весь клубок шаблонных переходов.  Я в своё время хлебнул горя с этим в MQL.   Теперь напрямую шаблонные методы практически не вызываю.  Только посредством обёртки из макроса, выполняющего предварительные проверки наподобие Sfinae.