Предложение - кастинг структур от базовых к производным

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

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

Никаких проблем в таком кастинге нет. Т.к. структуры передаются через стек, то компилятору заранее известно, в каком месте такой кастинг возможен, а в каком - нет (значит просто сгенерировать там ошибку выполнения). 

Вот пример использования:

template<typename T>
struct TComparable
{ 
 protected: TComparable() { }
 public:    int CompareTo(const TComparable & obj) const { return ((T)this)._CompareTo((T)obj); } // Сейчас тут выдаётся ошибка:  cannot cast 'TComparable<A>' to 'A'
};  

template<typename T>
int Compare(const TComparable<T> & a, const TComparable<T> & b)  { return a.CompareTo(b); }


struct A : TComparable<A>
{ 
  double a;
  A(double value) { a=value; }
  int _CompareTo(const A & obj) const { return a>obj.a ? 1 : a<obj.a ? -1 : 0; }
};

void OnInit()
{
  A a=10, b=20;
  
  int result= Compare(a, b);
}


Всё чётко и удобно.   А без этого приходится пользоваться полностью обезличенными шаблонами:

template<typename T>
int Compare(const T & a, const T & b) { return a.Compare(b); }

и потом перебирать код по косточкам, выискивая место, откуда был по ошибке вызван такой шаблон с типом int, например.  Ибо Метаэдитор в этом поиске не товарищ.


К слову, раньше в MQL всё это было возможно, т.к. структуры могли каститься вообще как угодно.  Но потом обрезали все возможности, хотя требовалось запретить только кастинг неродственных структур.

 
Alexey Navoykov:

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

Не согласен.

Во-первых, вобще кастинг от базового класса к производному - это не вполне безопасная операция.

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

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

 
Пока структуры нельзя хранить и возвращать по ссылке, а нужно постоянно создавать копии, себе дороже с ними заморачиваться.
 
Ilya Malev:
Пока структуры нельзя хранить и возвращать по ссылке, а нужно постоянно создавать копии, себе дороже с ними заморачиваться.

разработчики обычно пишут, что используйте классы вместо структур

 
Georgiy Merts:

Не согласен.

Во-первых, вобще кастинг от базового класса к производному - это не вполне безопасная операция.

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

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

Кому надо?   Вы в курсе, что в C# структуры поддерживают интерфейсы?

 
Sergey Dzyublik:
StructToCharArray, CharArrayToStruct
Вы чего-то недопоняли видимо в моём посте.
 
Igor Makanu:

разработчики обычно пишут, что используйте классы вместо структур

Ну вот уже так и делаем. Но помечтать-то никто не запрещает? :)

 
Alexey Navoykov:

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

Или вы против полиморфизма в принципе?

Кому надо?   Вы в курсе, что в C# структуры поддерживают интерфейсы?

Я не против полиморфизма, и написал, что если уж так надо - то чем не устраивают классы ?

А вот насчет "в С# структуры поддерживают интерфейсы" - тут я против. Структура тем и отличается от класса, что это, по идее, "голые данные". Без всяких там дополнительных функций. А если "поддерживают интерфейсы" - это это уже нельзя назвать структурой.

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

 

Georgiy Merts:

Структура тем и отличается от класса, что это, по идее, "голые данные".

в плюсах структура вообще ничем от класса не отличается
 
TheXpert:
в плюсах структура вообще ничем от класса не отличается

Да я не против.

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

1234
Новый комментарий
Причина обращения: