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

Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий
Vladimir Simakov
5980
Vladimir Simakov  

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

так сейчас:

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

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

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

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

#define TEXT_LEN 10

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

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

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

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

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

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

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

constexpr string text="Много букв";
constexpr int textLen=StringLen(text);
int array[textLen];
Igor Makanu
9498
Igor Makanu  
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
Поделитесь опытом, кто как выходил из ситуации...
Vladimir Simakov
5980
Vladimir Simakov  
Igor Makanu:

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

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


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

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



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

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

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

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

12
Авторизуйтесь или зарегистрируйтесь, чтобы добавить комментарий