Столкнулся с интересным поведением отладчика студии. Код:



Ставим точку отладки на if и, как только мы в нее попадаем, дальше начинаем выполнять пошагово выражения с помощью F10.
В данном случае ожидаемо следующее поведение:

- 0
- 1
- 4

вместо этого отладчик проходит по точкам остановки как:

- 0
- 1
- 2
- 3
- 4

Не смотря на это, код все равно работает правильно и n = 3 мы не получаем. В точке 4 n будет равно 2.
Но когда ты сидишь под отладчиком и пытаешься понять что на самом происходит, то это реально сбивает с толку.
Сборка DEBUG, поэтому никакого инлайна тут нет, как и прочих выкрутасов оптимизирующего компилятора.

Чтобы вернуть нормальное поведение F10, достаточно вытащить из if выражение
std::optional<std::string> strValue = "somestring", чтобы if стал работать по классической схеме.

Не призываю к дебатам, просто наблюдение, которым решил поделиться с общественностью.
Ну и будет здорово, если кто-то сможет проверить и подтвердить/опровергнуть мои выводы, чтобы не было сомнений, что это глюк исключительно у моей IDE.
--------------------------------------------------------------
o(O_O)o

kealon(Ruslan),

kealon(Ruslan),

почитай про if init и поймешь что ты не прав.
переменная доступна во всем теле if-а, включая else

если бы было так как утверждаешь ты, то в конце мы бы получали n = 3, а не n = 2

PetroNotC Sharp,

да, скорее всего, просто я минут 30 вдуплял что я сделал не так, а оказалось проблема вовсе не у меня

kealon(Ruslan),

я склонен согласиться с kealon(Ruslan), что данное поведение это сайд-эффект от вызова деструктора strValue, единственное что я бы исправил - поведение, которое к ниму приводит.

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

Порядок вызовов при коде дополненным скобками таков:
1. if
2. n = 2
3. else (нафига !?)
4. скобка, закрывающая if-else -блок (на скриншоте)

отладчик VS действительно позволяет заглянуть в точку, которая находится в конце области видимости ограниченной { }, но до вызова следующей инструкции. В нашем случае - return n, только почему то решает ее показать не в том блоке, который реально отработал , а просто в конце всей if - else конструкции.

Таким образом, если мы хотим убрать "лишние" { } из простых выражений, в которых они необязательны, то это приведет к тому, что отладчик прицепляется к последней ; блока if - else, что и приводит к эффекту, как-будто else блок отрабатывает вместе c if, хотя и ни одна инструкция из него по факту не срабатывает.

На мой взгляд правильнее было бы закончить на } того блока, который реально отработал, но если скобки в нем отсутствуют, то проигнорировать эту точку, а сразу переходить к следующей инструкции Если разработчику надо он переформатирует код так, чтобы появилась возможность попасть на } интересующего его блока, вместо того, чтобы получить визуально неадекватное поведение пошаговой отладки

Если заменить код if на


то никакого сайд-эффекта уже не наблюдается и поток вычислений ведет себя привычным образом, то есть сразу прыгает на return после else, вместо скобки. Видимо из-за того, что в данном случае strValue становится const char*, у которого нет деструктора в привычном понимании данного термина