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. Модераторы, дайте возможность редактировать их на сутки, пожалуйста. Это сообщение можно снести.
У Вас нет такой возможности. Просто пишите в теме далее.
Ну ок, пожалуй соглашусь, хотя вообще говоря рассматриваемые примеры лишены смысла, т.к. очевидно никто тут не станет объявлять аргумент как const int&. Такое может иметь смысл только в C++.
Возможно допустить лишь вариант с const string&, хотя тоже сомнительно.
Естественно предложения касались в первую очередь string
void f( conststring ) {} //(1)void f( conststring& ) {} //(2)string g() { return""; }
voidOnStart()
{
string s;
f( s ); //вызывалась бы (2) //приоритет по ссылке
f( "" ); //вызывалась бы (1) //нельзя по ссылке
f(g()); //вызывалась бы (1) //нельзя по ссылке
}
Если бы у (2) был бы приоритет над (1) (а не наоборот как сейчас), то тогда можно было бы вызвать и (1) и (2), а не только (1) как сейчас. Сразу же появляется гибкость и дополнительные возможности:
Было:
void f1( conststring s ) { f2( s ); }
void f2( conststring& s ) { /*...*/ }
voidOnStart()
{
string s = "ABCDEF";
f2( s );
f1( "ABCDEF" );
}
Стало:
void f( conststring s ) { f( s ); }
void f( conststring& s ) { /*...*/ }
voidOnStart()
{
string s = "ABCDEF";
f( s ); //(*)
f( "ABCDEF" );
}
Т.е. можно было бы использовать функцию с одним и тем же именем (для выполнения одних и тех же вычислений) в зависимости от контекста. Сейчас же это либо разные имена функций, либо всегда лишнее копирование - даже когда оно и не требуется (*)
Если бы у (2) был бы приоритет над (1) (а не наоборот как сейчас), то тогда можно было бы вызвать и (1) и (2), а не только (1) как сейчас. Сразу же появляется гибкость и дополнительные возможности:
Т.е. можно было бы использовать функцию с одним и тем же именем (для выполнения одних и тех же вычислений) в зависимости от контекста. Сейчас же это либо разные имена функций, либо всегда лишнее копирование - даже когда оно и не требуется (*)
Да, вы правы. Надо чтоб именно так и работало. Не так давно было очередное обсуждение этой темы в другой ветке, я там предлагал ввести в MQL оператор &&, который и решает данную проблему в паре с оператором &. Но действительно можно обойтись и без новых операторов, если поменять приоритеты аргументов. Правилам C++ это в любом случае не соответствует, зато хоть станет логичней и гибче. Надо до разработчиков достучаться с этой идеей.
Есть три тезиса:
1. Основное и самая главное в STL, это вектор. То есть динамический массив. Но вовсе не шаблоны, они принципиально ничего не меняют. А в MQL уже есть динамический массив, поэтому, делать из уже динамического массива подобие STL вектора... простите.
2. Если в голове перепутались указатели и ссылки, может спасти хороший учебник по C++, даже не хороший, а просто обычный. На самом деле никаких сложностей в том, чтобы отличить указатель от ссылки, не существует.
3. Если кто-то считает себя невероятно каким крутым С++ программистом, на столько, что даже рядом и подходить нельзя, в интернете существуют специализированные сайты и форумы, посвященные исключительно С++, можно сходить туда, и там показать весь блеск своей крутизны.
В связи с тем, что, как выяснилось, можно сделать единный vector для фундаментальных и пользовательских типов, хочу подредактировать первое сообщение и это https://www.mql5.com/ru/forum/315275#comment_11999242. Модераторы, дайте возможность редактировать их на сутки, пожалуйста. Это сообщение можно снести.
У Вас нет такой возможности. Просто пишите в теме далее.
У Вас нет такой возможности. Просто пишите в теме далее.
А вставить текст с сылкой (я её предоставлю) в первом сообщении на актуальный код сможете?
А вставить текст с сылкой (я её предоставлю) в первом сообщении на актуальный код сможете?
Никаких редакций. Продолжайте писать в теме.
Ну ок, пожалуй соглашусь, хотя вообще говоря рассматриваемые примеры лишены смысла, т.к. очевидно никто тут не станет объявлять аргумент как const int&. Такое может иметь смысл только в C++.
Возможно допустить лишь вариант с const string&, хотя тоже сомнительно.
Естественно предложения касались в первую очередь string
Если бы у (2) был бы приоритет над (1) (а не наоборот как сейчас), то тогда можно было бы вызвать и (1) и (2), а не только (1) как сейчас. Сразу же появляется гибкость и дополнительные возможности:
Было:
Стало:
Т.е. можно было бы использовать функцию с одним и тем же именем (для выполнения одних и тех же вычислений) в зависимости от контекста. Сейчас же это либо разные имена функций, либо всегда лишнее копирование - даже когда оно и не требуется (*)Если бы у (2) был бы приоритет над (1) (а не наоборот как сейчас), то тогда можно было бы вызвать и (1) и (2), а не только (1) как сейчас. Сразу же появляется гибкость и дополнительные возможности:
Т.е. можно было бы использовать функцию с одним и тем же именем (для выполнения одних и тех же вычислений) в зависимости от контекста. Сейчас же это либо разные имена функций, либо всегда лишнее копирование - даже когда оно и не требуется (*)ув.автор "STL-подобного"!
нужна реализация std::deque , гуглил описание deque - сдался, может быть под MQL пойму на кой этот std::deque нужен - нужен тут
ув.автор "STL-подобного"!
нужна реализация std::deque , гуглил описание deque - сдался, может быть под MQL пойму на кой этот std::deque нужен - нужен тут
ответил в той теме.