Хочется STL подобного - страница 4

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

Есть три тезиса:

1. Основное и самая главное в STL, это вектор. То есть динамический массив. Но вовсе не шаблоны, они принципиально ничего не меняют. А в MQL уже есть динамический массив, поэтому, делать из уже динамического массива подобие STL вектора... простите.

2. Если в голове перепутались указатели и ссылки, может спасти хороший учебник по C++, даже не хороший, а просто обычный. На самом деле никаких сложностей в том, чтобы отличить указатель от ссылки, не существует.

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

 
В связи с тем, что, как выяснилось, можно сделать единный vector для фундаментальных и пользовательских типов, хочу подредактировать первое сообщение и это https://www.mql5.com/ru/forum/315275#comment_11999242. Модераторы, дайте возможность редактировать их на сутки, пожалуйста. Это сообщение можно снести.
 
Vict:
В связи с тем, что, как выяснилось, можно сделать единный vector для фундаментальных и пользовательских типов, хочу подредактировать первое сообщение и это https://www.mql5.com/ru/forum/315275#comment_11999242. Модераторы, дайте возможность редактировать их на сутки, пожалуйста. Это сообщение можно снести.

У Вас нет такой возможности. Просто пишите в теме далее.

 
Vladimir Karputov:

У Вас нет такой возможности. Просто пишите в теме далее.

А вставить текст с сылкой (я её предоставлю) в первом сообщении на актуальный код сможете?

 
Vict:

А вставить текст с сылкой (я её предоставлю) в первом сообщении на актуальный код сможете?

Никаких редакций. Продолжайте писать в теме.

 
Alexey Navoykov:

Ну ок, пожалуй соглашусь, хотя вообще говоря рассматриваемые примеры лишены смысла, т.к. очевидно никто тут не станет объявлять аргумент как  const int&.  Такое может иметь смысл только в C++.

Возможно допустить лишь вариант с  const string&,  хотя тоже сомнительно.

Естественно предложения касались в первую очередь string

void f( const string  ) {} //(1)
void f( const string& ) {} //(2)
string g() { return ""; }
void OnStart()
{
        string s;
        f( s );  //вызывалась бы (2) //приоритет по ссылке
        f( "" ); //вызывалась бы (1) //нельзя по ссылке
        f(g());  //вызывалась бы (1) //нельзя по ссылке
}

Если бы у (2) был бы приоритет над (1) (а не наоборот как сейчас), то тогда можно было бы вызвать и (1) и (2), а не только (1) как сейчас. Сразу же появляется гибкость и дополнительные возможности:

Было:

void f1( const string  s ) { f2( s ); }
void f2( const string& s ) { /*...*/  }
void OnStart()
{
        string s = "ABCDEF";
        f2( s        );
        f1( "ABCDEF" );
}

Стало:

void f(  const string  s ) { f(  s ); }
void f(  const string& s ) { /*...*/  }
void OnStart()
{
        string s = "ABCDEF";
        f(  s        ); //(*)
        f(  "ABCDEF" );
}
Т.е. можно было бы использовать функцию с одним и тем же именем (для выполнения одних и тех же вычислений) в зависимости от контекста. Сейчас же это либо разные имена функций, либо всегда лишнее копирование - даже когда оно и не требуется (*)
 
A100:

Если бы у (2) был бы приоритет над (1) (а не наоборот как сейчас), то тогда можно было бы вызвать и (1) и (2), а не только (1) как сейчас. Сразу же появляется гибкость и дополнительные возможности:


Т.е. можно было бы использовать функцию с одним и тем же именем (для выполнения одних и тех же вычислений) в зависимости от контекста. Сейчас же это либо разные имена функций, либо всегда лишнее копирование - даже когда оно и не требуется (*)
Да, вы правы.  Надо чтоб именно так и работало.  Не так давно было очередное обсуждение этой темы в другой ветке, я там предлагал ввести в MQL оператор &&, который и решает данную проблему в паре с оператором &.   Но действительно можно обойтись и без новых операторов, если поменять приоритеты аргументов.  Правилам C++ это в любом случае не соответствует,  зато хоть станет логичней и гибче.   Надо до разработчиков достучаться с этой идеей.
 

ув.автор "STL-подобного"!

нужна реализация std::deque , гуглил описание deque - сдался, может быть под MQL пойму на кой этот std::deque нужен - нужен тут 

 
Igor Makanu:

ув.автор "STL-подобного"!

нужна реализация std::deque , гуглил описание deque - сдался, может быть под MQL пойму на кой этот std::deque нужен - нужен тут 

ответил в той теме.

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