Почему поинтер обнуляется ?

@alexbmd · Регистрация: 03.06.2013

Студворк — интернет-сервис помощи студентам

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <iostream>
#include <string>
#include <stdio.h>
#include <string.h>
 
 
int main()
{
 char* p = (char*)malloc(strlen("Thunderbird") + 1);
  strcpy(p, "Thunderbird");
for ( ; *p; ++p) if(*p > 'Z') {continue;} else if (*p < 'A') {continue;} else {*p = *p|0x60;}
 
printf ("str3 = %s ",p);
}

почему for обнуляет вместо того чтобы присвоить ?

@Azazel-San · 14.05.2019, 18:02

Сообщение от alexbmd

почему? если префиксный инкремент две инструкции а пост инкремент три.

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

@TheCalligrapher · 14.05.2019, 18:10

Сообщение от alexbmd

почему? если префиксный инкремент две инструкции а пост инкремент три.

Это откуда вы взяли такую странную информацию??

Для фундаментального типа, т.е. типа, поддерживаемого на уровне компилятора, в контексте, где результат ++ игнорируется, любой вменяемый компилятор всегда сгенерирует соверешенно идентичный - оптимальный - код и для префиксного ++, и для постфиксного ++. Количество инструкций будет совершенно идентичным.

@alexbmd · 14.05.2019, 18:25 **[ТС]**

Сообщение от TheCalligrapher

в контексте, где результат ++ игнорируется

а если результат участвует в дальнейших вычеслениях и оптимизации компилятора отключенны то разница так понимаю будет ?

@TheCalligrapher · 14.05.2019, 18:31

Сообщение от alexbmd

а если результат участвует в дальнейших вычеслениях

Зависит от этих "дальнейших вычислений". Правило тот простое: используйте именно тот оператор, который нужен в данном контексте. А компилятор уже сам разберется, как сгенерировать оптимальный код.

Сообщение от alexbmd

и оптимизации компилятора отключенны то разница так понимаю будет ?

Таки вещи никак не зависят от включенных или выключенных "оптимизаций компилятора".

@Azazel-San · 14.05.2019, 19:02

alexbmd, вы не увидите разницы ни при каких-либо явно включённых оптимизациях, ибо для фундаментальных типов инкремент (+1) выполнит процессор и здесь не может быть никаких отличий.
Например возьмём цикл for (int i = 0; i < 10000; i++), здесь операция i++ хорошо определена и нам точно известен порядок вычисления по отношению к остальным выражениям, до и после i++ и в любом случае все что здесь нам надо это увеличить i на 1 и именно это мы всегда получим в сгенерированном коде, внезависимости от того будет ли это постфиксный или префиксный инкремент.
Более того в некоторых случаях в циклах префиксный инкремент может ввести зависимость от данных в ваш код

@zayats80888 · 14.05.2019, 19:10

Сообщение от Azazel-San

Более того в некоторых случаях в циклах префиксный инкремент может ввести зависимость от данных в ваш код

А можно поподробнее(или ссылку)?

@Azazel-San · 14.05.2019, 19:14

zayats80888, Game Engine Architecture (3rd edition), там есть топик посвящённый этому.

@alexbmd · 14.05.2019, 19:18 **[ТС]**

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

спасибо

Azazel-San, ну вот for плохой пример для этого. тут разницы нету и так и так
for(;;++i) print i
for(;;i++) print i
//результат одинаковый

хотя бы вот
for(;++i; ) print i
for(;i++; ) print i
//тут я думал может получиться разный код (ну только более сложный пример нужен конечно). но нет так нет

просто почемуто именно сишник очень любят префиксный инкремент. хотя для большинства простых задач нужен как раз постфикс.
++i чаще для простых задач только путаницу добовляет/читаемость кода падает. понятно что можно любой код подстроить до правильного результата. ну это имхо конечно

@zayats80888 · 14.05.2019, 19:21

Сообщение от Azazel-San

Game Engine Architecture (3rd edition)

Вы мне предлагаете аж целую книжку купить

Повременю пока. Ну в двух словах, если это возможно, объясните.

Добавлено через 2 минуты

Сообщение от alexbmd

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

Ну вот открыл библиотеку <algorithm> и вижу в арифметике итераторов везде префиксный инкремент/декремент(если явно не требуется постфиксный) Ну и книжка Страуструпа приучила меня к такомуже подходу, а он то уж точно не "сишник"

@Azazel-San · 14.05.2019, 19:55

Сообщение от zayats80888

Ну в двух словах, если это возможно, объясните.

Допустим у нас есть такой код:

C++
1
2
3
4
5
6
7
8
void process_array(int const* container, std::size_t const num_elements) {
   int* begin = &container[0];
   int* end   = &container[num_elements];
   for (int* p = begin; p != end; p++) {
      int element = *p;
      // process element...
   }
}

В примере process_array() мы используем постинкрементный оператор, p++. Это тонкая, но иногда важная оптимизация. Оператор preincrement увеличивает содержимое переменной до того, как ее (теперь измененное) значение используется в выражении. Оператор postincrement увеличивает содержимое переменной после ее использования. Это означает, что написание ++p вводит зависимость данных в ваш код - CPU должен дождаться завершения операции инкремента, прежде чем его значение можно будет использовать в выражении. На глубоко конвейерном процессоре, это приводит к остановке. С другой стороны, с p++ нет зависимости. Значение переменной можно использовать немедленно, а операция приращения может произойти позже или параллельно с ее использованием.
Конечно, в выражении «update» цикла for не должно быть различий между пре- и постинкрементами. Это потому, что любой хороший компилятор распознает, что значение переменной не используется в update_expr. Но в тех случаях, когда используется значение, постинкремент предпочтительнее, поскольку он не приводит к задержке в конвейере CPU.

Сообщение от zayats80888

и вижу в арифметике итераторов везде префиксный инкремент/декремент

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

Добавлено через 11 минут

Сообщение от alexbmd

хотя бы вот
for(;++i; ) print i
for(;i++; ) print i
//тут я думал может получиться разный код

Каким образом?
И как вы определяли разный код здесь или нет?

Сообщение от alexbmd

++i чаще для простых задач только путаницу добовляет/читаемость кода падает. понятно что можно любой код подстроить до правильного результата. ну это имхо конечно

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

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

@zayats80888 · 14.05.2019, 20:00

Сообщение от Azazel-San

Оператор preincrement увеличивает содержимое переменной до того, как ее (теперь измененное) значение используется в выражении.

правильно ли я понял, что в данном случае оптимизация в том, что постинкремент выполняется не в конце итерации а в начале? Т. е. p!=end->p++-><тело цикла, работаем с значением p до инкремента>?

@Azazel-San · 14.05.2019, 20:05

Сообщение от zayats80888

<тело цикла, работаем с значением p до инкремента>

Да, мы работаем с переменной до того, как ее увеличат в выражении и мы можем работать с p как оно есть и только потом сделать инкремент.
У нас нету зависимости от инкремента, и мы можем сделать некие оптимизации в этом контексте.

@alexbmd · 14.05.2019, 20:19 **[ТС]**

Сообщение от Azazel-San

Каким образом?
И как вы определяли разный код здесь или нет?

речь не конкретно про этот код. а в целом. если пре инкремент это 2 инструкции а пост - 3 то на каких то как вы говорите критичных к производительности кусках кода
" дополнительная стоимость копирования итератора может склонить шкалы к предпочтению преинкремента при использовании таких классов в циклах, критичных к производительности"
мы можем увидеть разницу.
раньше я об этом не задумывался но теперь не удевлюсь если разница таки будет пусть и микроскопическая.

Добавлено через 9 минут

Сообщение от zayats80888

p!=end->p++-><тело цикла, работаем с значением p до инкремента>

Azazel San мы в обоих случаях работаем с одинаковым значением.

p=0;
p!=end -> p++ -> print p//0 -> p=1 -> p!=end ->
p!=end -> ++p -> print p//0 -> p=1 -> p!=end ->

вот и Калиграфер говорит
"Третий сегмент из заголовка for выполняется в конце каждой итерации."

ну там понятно разница в инкременте есть, но в теле лупа оно нам не видно

PS: не спора ради а просветления для

@Azazel-San · 14.05.2019, 20:23

Сообщение от zayats80888

тело цикла

Только щас заметил, не в теле цикла.
В теле цикла мы уже будем работать с увеличенным значением.

Добавлено через 1 минуту

Сообщение от alexbmd

Azazel San мы в обоих случаях работаем с одинаковым значением.

В теле цикла да, я почему то, подумал о другом и не заметил что здесь именно о теле цикла речь зашла.

Добавлено через 1 минуту

Не по теме:

Странно, обновил страницу и мне репутацию списали, хм..

@zayats80888 · 14.05.2019, 20:31

Сообщение от Azazel-San

В теле цикла мы уже будем работать с увеличенным значением.

я подумал что то вроде этого, например
p!=end->p++-><тело цикла, работаем с значением p до инкремента>->p!=end->(т.к. p уже прирастили можно не ожидать, а сразу в тело нырять, где-нибудь параллельно опять прирастим)<тело цикла, работаем с увеличенным в прошлый раз значением p>->(если не прирастили, ожидаем) и т.д.

@Azazel-San · 14.05.2019, 20:50

zayats80888, смотрите, вот ключевые фразы:

Сообщение от Azazel-San

Конечно, в выражении «update» цикла for не должно быть различий между пре- и постинкрементами. Это потому, что любой хороший компилятор распознает, что значение переменной не используется в update_expr.

Здесь может быть немного запутанно, что имеет ввиду автор, но вот как иногда описывают цикл for:

Code
1
for (initialization-expression; declaration-or-test-expression; update-expression)

update_expr - это именно так секция где идет обновление счетчика, обычно мы его хотим видеть в последнем блоке цикла, но это не всегда так, в примере выше я тоже его разместил в конце, просто из-за удобства.
И вот если это значение update не используется выхлоп будет одинаковым.

И это:

Сообщение от Azazel-San

Но в тех случаях, когда используется значение, постинкремент предпочтительнее, поскольку он не приводит к задержке в конвейере CPU.

Когда же приходит тот момент использования?
Например в чем-то таком:

C++
1
for(int i = 0; arr[i++];)

@zayats80888 · 14.05.2019, 21:17

Не по теме:

Надеюсь не задолбал еще :)

C++
1
2
3
4
5
6
7
8
9
10
    //это конечно упрощение
    int val{};
    for (int i = 0; i < 10;)
        val += ++i;
 
    // не смотря на одинаковый результат имеет смысл перестроить
    // под постинкремент для оптимизации?
    val = 0;
    for (int i = 1; i < 11;)
        val += i++;

@Azazel-San · 14.05.2019, 23:31

Сообщение от Azazel-San

Например в чем-то таком:

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

Вот, например что-то такое
https://godbolt.org/z/NEYHpe

Сообщение от zayats80888

Надеюсь не задолбал еще

Да, вероятно имеет, результат постинкремента можно использовать и параллельно на другом конвейере инкремент выполнить.

Сообщение от zayats80888

// не смотря на одинаковый результат имеет смысл перестроить
* * // под постинкремент для оптимизации?

Опять же, нужно смотреть конкретный asm-код.

Может, ув. TheCalligrapher, пролил бы свет

@Kuzia domovenok · 15.05.2019, 00:13

Сообщение от zayats80888

// не смотря на одинаковый результат имеет смысл перестроить // под постинкремент для оптимизации?

впервые такое слышу. Обычно считается, что прединкремент оптимальнее постинкремента, хоть и не советуют заморачиваться с такого рода "оптимизацией".

@TheCalligrapher · 15.05.2019, 00:28

Сообщение от zayats80888

// не смотря на одинаковый результат имеет смысл перестроить
* * // под постинкремент для оптимизации?

Нет, разумеется. Никакого смысла в такой оптимизации для инкремента скалярного типа нет.

Новые блоги и статьи Все статьи Все блоги /
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .	сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры. anaschu 12.07.2026 Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .	сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .

@Azazel-San Mental handicap 1246 / 624 / 171 Регистрация: 24.11.2015 Сообщений: 2,429
	14.05.2019, 19:02
	alexbmd, вы не увидите разницы ни при каких-либо явно включённых оптимизациях, ибо для фундаментальных типов инкремент (+1) выполнит процессор и здесь не может быть никаких отличий. Например возьмём цикл `for (int i = 0; i < 10000; i++)`, здесь операция `i++` хорошо определена и нам точно известен порядок вычисления по отношению к остальным выражениям, до и после `i++` и в любом случае все что здесь нам надо это увеличить i на 1 и именно это мы всегда получим в сгенерированном коде, внезависимости от того будет ли это постфиксный или префиксный инкремент. Более того в некоторых случаях в циклах префиксный инкремент может ввести зависимость от данных в ваш код 0

@Azazel-San Mental handicap 1246 / 624 / 171 Регистрация: 24.11.2015 Сообщений: 2,429
	14.05.2019, 19:14
	zayats80888, Game Engine Architecture (3rd edition), там есть топик посвящённый этому. 0

@alexbmd 61 / 5 / 1 Регистрация: 03.06.2013 Сообщений: 355 Записей в блоге: 3
	14.05.2019, 19:18 [ТС]
	просто читал что ранее когда я был молодой, синтактический сахар использовали как раз для того что была разница как прибавлять. потом уже компилятор научился ассемблировать одинаковый код. но я подумал отключив все оптимизации компилятора пост и пре инкремент в какихто особых случаях разница будет. ну нет так нет. доверимся компилятору спасибо Azazel-San, ну вот for плохой пример для этого. тут разницы нету и так и так for(;;++i) print i for(;;i++) print i //результат одинаковый хотя бы вот for(;++i; ) print i for(;i++; ) print i //тут я думал может получиться разный код (ну только более сложный пример нужен конечно). но нет так нет просто почемуто именно сишник очень любят префиксный инкремент. хотя для большинства простых задач нужен как раз постфикс. ++i чаще для простых задач только путаницу добовляет/читаемость кода падает. понятно что можно любой код подстроить до правильного результата. ну это имхо конечно 0