Просьба добавить спецификатор constexpr

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

Вот для этого:

так сейчас:

#define TEXT "Много букв"
#define TEXT_LEN StringLen(TEXT)

,а так станет:

constexpr string text="Много букв";
constexpr int textLen=StringLen(text);

В первом примере эффективнее:

#define TEXT_LEN 10

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

 
Какой-то бессмысленный пример использования вы привели.  Компилятор, скорее всего, и сам оптимизирует данное выражение, если значение text постоянно. Можно дополнительно указать ему const.
 
Alexey Navoykov:
Какой-то бессмысленный пример использования вы привели.  Компилятор, скорее всего, и сам оптимизирует данное выражение, если значение text постоянно. Можно дополнительно указать ему const.
Тут основной момент в вызове StringLen. В примере с препроцессором, каждое вхождение TEXT_LEN ведет подствновку функции. В случае с constexpr  компилятор на стадии компиляции высчитает это значение и далее уже его подставит вместо вызова переменной, проверив заодно на согласование типов данных.
 
Vladimir Simakov:
Тут основной момент в вызове StringLen.

не так уж дорого чтобы переносить на время компиляции. кстати далеко не факт что это не делается автоматом

const string s = "12345";
const int s_size = StringLen(s);

void OnStart()
{
   Print("s = \"", s, "\", size = ", s_size);
}
 
Vladimir Simakov:
Тут основной момент в вызове StringLen. В примере с препроцессором, каждое вхождение TEXT_LEN ведет подствновку функции. В случае с constexpr  компилятор на стадии компиляции высчитает это значение и далее уже его подставит вместо вызова переменной, проверив заодно на согласование типов данных.
Ещё раз, что мешает просто объявить:
const int len = StringLen(txt);
Ну а для большей надёжности добавить ещё static, чтобы быть уверенным, что выражение вычисляется однократно
 
Alexey Navoykov:
Ещё раз, что мешает просто объявить:
const int len = StringLen(txt);
Ну а для большей надёжности добавить ещё static, чтобы быть уверенным, что выражение вычисляется однократно
Да ничего не мешает, просто при объявлении const это все таки переменая и обращение к ней будет по адресу памяти.
 
Vladimir Simakov:
Да ничего не мешает, просто при объявлении const это все таки переменая и обращение к ней будет по адресу памяти.

Да не факт. Компилятор, полагаю, не совсем глупый )  Думаю он всё оптимизирует сам на стадии компиляции.

Вам следовало привести более наглядный пример использования, когда применение constexpr действительно необходимо, например так:

constexpr string text="Много букв";
constexpr int textLen=StringLen(text);
int array[textLen];
 
Alexey Navoykov:

Да не факт. Компилятор, полагаю, не совсем глупый )

разработчики много где сделали оптимизацию компилятора, думаю, что даже типовые конструкции которые используют юзеры и те учли, вот не давно разбирали https://www.mql5.com/ru/forum/312873

дык даже в МТ4 типовой вызов iCustom() с одинаковыми параметрами тоже оптимизирован - за один  вызов индикатора будут получены все данные


#define и все константы всегда на этапе компиляции вычисляются, кто то из админов писал

циклы тоже оптимизированы - тоже писали



по сабжу.... ну вроде штука нужная, но зачем? MQL уже не станет C++, много не соответствий и добавление новых Сиподобных конструкций все равно не позволит портировать С++ коды в 2 клика в MQL, а добавив что то из С++ в MQL всегда вызывает много "почему"

оптимизация iCustom
оптимизация iCustom
  • 2019.05.07
  • www.mql5.com
Поделитесь опытом, кто как выходил из ситуации...
 
Igor Makanu:

разработчики много где сделали оптимизацию компилятора, думаю, что даже типовые конструкции которые используют юзеры и те учли, вот не давно разбирали https://www.mql5.com/ru/forum/312873

дык даже в МТ4 типовой вызов iCustom() с одинаковыми параметрами тоже оптимизирован - за один  вызов индикатора будут получены все данные


#define и все константы всегда на этапе компиляции вычисляются, кто то из админов писал

циклы тоже оптимизированы - тоже писали



по сабжу.... ну вроде штука нужная, но зачем? MQL уже не станет C++, много не соответствий и добавление новых Сиподобных конструкций все равно не позволит портировать С++ коды в 2 клика в MQL, а добавив что то из С++ в MQL всегда вызывает много "почему"

Так оптимизатор - это то ли сделал, то-ли нет. Дизассемблировать код что-ли для проверки каждый раз? А с constexpr я прямо ему говорю об этом.
 
Что касается того, что mql не c++, так то да, но уж очень похож. Убери запрет на указатели примитивных типов и, по крупному, наверное, только множественное наследование останется.
 
Vladimir Simakov:
Что касается того, что mql не c++, так то да, но уж очень похож. Убери запрет на указатели примитивных типов и, по крупному, наверное, только множественное наследование останется.

по крупному динамические многомерные массивы нужны, только начинаешь разбирать готовые мат.пакеты на С++ сразу упираешься в отсутствие динамических многомерных массивов

с указателями тож беда... но это объясняют безопасностью языка

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