Static как в C++

Мне нужно, чтобы некоторая локальная переменная сохраняла свое значение между вызовами этой функции.
Какой модификатор мне в этом случае надо использовать?

0

Сообщение от Просто Саша Так проще объяснять такое поведение.

Самое простое объяснение любому явлению — такова воля Божья.
Но, согласитесь, простота в ущерб правильности — не всегда лучший подход.

Сообщение от Просто Саша В конце-концов, результат конечный от этого не меняется.

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

Сообщение от Просто Саша Visual Basic это объясняется именно так.

Опять же, я с ВБ не знаком, но наверное такое поведение там сделано потому, что в нем нельзя определять области видимости как в С-подобных языках.
Области там определяются синтаксическими конструкциями (циклы, условия, методы, модули и т.д.), при этом логично иметь возможность объявлять переменную только в определенной области.
Поэтому, наверное, и сделали такое поведение локальным.

1

Сообщение от kolorotur Но, согласитесь, простота в ущерб правильности — не всегда лучший подход.

Соглашусь.

Сообщение от kolorotur Вышеприведенный код скомпилируется, что сразу же отвергает теорию "переменная, объявленная в одной области, остается жить в другой".

Это совершенно другой код. Просто контекст в C# определяется парой фигурных скобок, но не тогда, когда они определяеют составные операторы, как например для оператора for.

Добавлено через 9 минут
И к тому же речь ведь идёт о времени жизни таких переменных, просто в первом случае её существование не позволяет определить другую переменную с таким же именем, а во втором случае позволяет, потому что она находится в другом контексте.
Просто, удобно и красиво. ДА НЕПРАВИЛЬНО, но эта неправильность важна только разработчикам компилятором, но не прикладных программ.

0

Сообщение от Просто Саша Просто контекст в C# определяется парой фигурных скобок, но не тогда, когда они определяеют составные операторы, как например для оператора for.

С чего это?
Контекст — он и есть контекст, в том числе и для оператора for.
Без операторов, просто с пустыми областями этот код будет работать (не работать) точно так же — правила одни и те же.

Сообщение от Просто Саша ДА НЕПРАВИЛЬНО, но эта неправильность важна только разработчикам компилятором, но не прикладных программ.

Это заблуждение.
Время жизни переменной влияет на такой важнейший параметр, как время жизни объекта, на который эта переменная ссылается. Если переменная ссылочного типа.
Используя ваше определение становится практически невозможным отслеживать в какой момент на объект не остается ссылки и производить соответствующий рефакторинг.

0

Сообщение от kolorotur Время жизни переменной влияет на такой важнейший параметр, как время жизни объекта, на который эта переменная ссылается. Если переменная ссылочного типа. Используя ваше определение становится практически невозможным отслеживать в какой момент на объект не остается ссылки и производить соответствующий рефакторинг.

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

0

Сообщение от Просто Саша А здесь ничего отслеживать не надо, поскольку Вам не удастся создать эти ссылки

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

0

Сообщение от kolorotur Речь не про возможность создания ссылки, а про предложенное вами объяснение, что переменная, объявленная в цикле, продолжает жить за пределами цикла.

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

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

0

Сообщение от Просто Саша Ну она же мешает объявить другу переменную.

Мешает, да. Но не по указанной вами причине

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

Верно.

Сообщение от Просто Саша В Visual Basic это объясняется так. Поэтому я и заимствовал это объяснение оттуда.

Логику создателей ВБ понять можно, вашу тоже — проще наложить уже знакомое объяснение на что-то новое.
Но представлять таким образом время жизни переменных в шарпе — плохая идея, потому что может привести к неправильному подходу и повлиять на корректность кода.

Сообщение от Просто Саша В конце концов должен быть какой-то критерий существования или несуществования переменной с тем или иным именем.

Конечно есть! Все критерии описаны в спеках языка, ссылку на которые я давал несколькими сообщениями выше.

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

Здесь вы путаете время выполнения и программный текст (код).
Время жизни переменной — это свойство переменной во время выполнения программы.
Область видимости и возможность объявления — это синтаксис, свойство текста программы.
Они немного разные вещи.

Я выше уже говорил, что майкрософтовский компилятор по факту выделяет память подо все локальные сразу при входе в метод. Но не его поведение является причиной наличия такого правила (было странно, если бы это было так), а наличие такого правила позволяет компилятору выполнять некоторые оптимизации.
А причина самого правила проста: устранение целого ряда проблем с неподдерживаемым кодом, который наблюдается в других языках, где это разрешено. Время жизни тут вообще никаким боком.

Сообщение от Просто Саша Ну здесь как минимум, все таки что-то от нее остается. Ну во всяком случае не так примитвно, как будто её никода не было.

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

Опять же, для компилятора нет никаких проблем или технических ограничений обозвать внутреннюю переменную x1, а внешнюю — x2. Причина не в жизни переменных, а в спецификации языка, прямо запрещающей создание одинаковых локальных в пересекающихся областях.
Вон, в С++ такого правила нет и компилятор может вообще использовать ту же самую переменную что во внешней, что во внутренней области. А может и не использовать и каждый раз увеличивать/уменьшать указатель на стеке.

0

Кстати, все это можно не раз обсуждать, но жизнь была бы значительно проще

Сообщение от kolorotur Конечно есть! Все критерии описаны в спеках языка, ссылку на которые я давал несколькими сообщениями выше.

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

Сообщение от kolorotur Время жизни переменной — это свойство переменной во время выполнения программы

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

Сообщение от kolorotur Область видимости и возможность объявления — это синтаксис, свойство текста программы.

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

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

0

Сообщение от Просто Саша Помимо спеков должен быть ещё и код, который позволяет это подтвердить

Подтвердить то, что переменная больше не живет?

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

Значит по вашему же определению переменная, объявленная в цикле, уже не живет вне цикла — потому что ей там нельзя воспользоваться.

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

Верно: свойство текста.

Сообщение от Просто Саша Осталось только выяснить, что означает переменная живет или не живет.

Вы уже объяснили:

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

Если переменной нельзя пользоваться вне цикла, то она уже не живет — по определению.

0

Сообщение от kolorotur Подтвердить то, что переменная больше не живет?

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

Сообщение от kolorotur Значит по вашему же определению переменная, объявленная в цикле, уже не живет вне цикла — потому что ей там нельзя воспользоваться.

Да именно так и происходит, например в C++, но не в C#. Тот код, который я привел выше, вот этот
выполните его в C++ и убедитесь сами, что это так.

Сообщение от kolorotur Верно: свойство текста.

Это даже не понял.

И еще, можно пользоваться и нельзя пользоваться - здесь это не антитезы.
Например, статическими локальными переменными в C++ можно пользоваться только внутри функций, в которых они определены, но живут они с начала программы и до ее конца.

Добавлено через 5 минут
Поэтому, период выполнения чего-то, откуда данная переменная не видна, отнюдь не относится к ее времени жизни.

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

А вот в C# - время жизни переменной x - вся функция, в которой все это происходит, ну по крайней мере пара фигурных скобок, обрамляющих этот цикл, а область действия все та же самая область цикла.

Вроде все логично.

0

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

Во всех языках программирования таким подтверждением является проверка спецификации языка, в которой говорится в какой момент переменная считается дохлой.
Если под временем жизни вы подразумеваете наличие какого-то значения в каком-то участке памяти, то это как правило дается на откуп компилятору и к языку как таковому уже отношения не имеет.

Сообщение от Просто Саша Ну если Вы знаете другой способ, буду благодарен, если поделитесь.

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

Сообщение от Просто Саша но не в C#.

Почему нет?
Ну а раз она не существует, то она уже дохлая.

А новую переменную с таким именем вы не создадите потому, что это запрещают правила языка, а не потому, что она уже где-то существует. Ошибка выше явно указывает на то, что она не существует

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

Сообщение от Просто Саша А вот в C# - время жизни переменной x - вся функция, в которой все это происходит

Если смотреть на то, как это реализовано компилятором — да, это так.
Но спецификация языка не накладывает такого обязательства.

0

Сообщение от Просто Саша Ответ только один - ЗНАЧИТ ОНА НЕ УМИРАЕТ, А ПРОДОЛЖАЕТ ЖИТЬ

нифига. Все чуть круче: все переменные в итоговом коде обьявляютсся в начале метода, из-за этого и будет конфликт далее. Из-за єтого и нельзя в циклах/условиях обьявлять переменые с именами, встречающиеся выше.

0

Сообщение от kolorotur Во всех языках программирования таким подтверждением является проверка спецификации языка, в которой говорится в какой момент переменная считается дохлой.

Да, но спецификации должны легко проверяться, а не просто декларироваться.

Сообщение от kolorotur for (int i = 0; i < 5; i++)//еще i * * { * * * * int x = i; //x в другой области * * } x = 12;

Это просто попытка обратиться к переменной из области, которая не является областью видимости переменной x.

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

Сообщение от kolorotur Если смотреть на то, как это реализовано компилятором — да, это так. Но спецификация языка не накладывает такого обязательства.

Ну этот случай надо хотя бы как минимум обговорить.
В Ваших спеках действительно говорится, что переменная не существует после выхода из цикла, а вот то, что внешняя к циклу переменная не позволяет определять переменную с таким же самым именем, не говорится ничего.
ХОТЯ МОЖЕТ БЫТЬ Я ПРОСТО ЕЩЁ НЕ ДОШЕЛ ДО ЭТОГО МЕСТА И МОЖЕТ БЫТЬ ПРАВИЛЬНЫЙ ОТВЕТ Я ПОЛУЧУ ТАМ, ГДЕ РЕЧЬ ПОЙДЕТ О СКРЫТИЕ ИМЕН.

0

Сообщение от Просто Саша Да, но спецификации должны легко проверяться, а не просто декларироваться.

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

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

Раздел 7.6.2.1:

7.6.2.1 Invariant meaning in blocks For each occurrence of a given identifier as a full simple-name (without a type argument list) in an expression or declarator, within the local variable declaration space (§‎3.3) immediately enclosing that occurrence, every other occurrence of the same identifier as a full simple-name in an expression or declarator must refer to the same entity. This rule ensures that the meaning of a name is always the same within a given block, switch block, for-, foreach- or using-statement, or anonymous function. The example C# 1 2 3 4 5 6 7 8 9 10 11 12 13 class Test {     double x;     void F(bool b)     {         x = 1.0;         if (b)         {             int x;             x = 1;         }     } } results in a compile-time error because x refers to different entities within the outer block (the extent of which includes the nested block in the if statement). In contrast, the example C# 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 class Test {     double x;     void F(bool b)     {         if (b)         {             x = 1.0;         }         else         {             int x;             x = 1;         }     } } is permitted because the name x is never used in the outer block.

Мной заодно выделена причина наличия этого правила

Сообщение от Просто Саша МОЖЕТ БЫТЬ ПРАВИЛЬНЫЙ ОТВЕТ Я ПОЛУЧУ ТАМ, ГДЕ РЕЧЬ ПОЙДЕТ О СКРЫТИЕ ИМЕН.

Не, сокрытие — это немного о другом, больше связано с полиморфизмом и проблемами хрупкого базового класса.

0

Просто Саша, еще раз -- все переменные метода, где бы ты их не написал, в итоговой сборке будут в начале метода.

Далее, если бы ти посмотрел на ошибки, то ругается не на ниже обьявленую переменую, а во внутренем контексте. Т.е. Контекст должен иметь свои уникальные переменые, по отношению к внешнему (не путать с соседним).

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

p.s. и зачем строчить капсом?

Миниатюры

 

0

Просто Саша, вот еще по поводу жизни переменной, из спека:

The lifetime of a local variable is the portion of program execution during which storage is guaranteed to be reserved for it. This lifetime extends at least from entry into the block, for-statement, switch-statement, usingstatement, foreach-statement, or specific-catch-clause with which it is associated, until execution of that block, for-statement, switch-statement, using-statement, foreach-statement, or specific-catch-clause ends in any way. (Entering an enclosed block or calling a method suspends, but does not end, execution of the current block, forstatement, switch-statement, using-statement, foreach-statement, or specific-catch-clause.) If the local variable is captured by an anonymous function (§‎7.15.5.1), its lifetime extends at least until the delegate or expression tree created from the anonymous function, along with any other objects that come to reference the captured variable, are eligible for garbage collection.

То есть согласно спеку место хранения локальной переменной в блоке живо как минимум до окончания этого блока.
Освобождать память или нет после окончания блока — прерогатива компилятора. Ну мы уже знаем, что МС-овский компилятор не освобождает.

0

Сообщение от kolorotur То есть согласно спеку место хранения локальной переменной в блоке живо как минимум до окончания этого блока. Освобождать память или нет после окончания блока — прерогатива компилятора. Ну мы уже знаем, что МС-овский компилятор не освобождает.

Да я с Вами полностью согласен и не спорю в этом отношении. Но, как черт возьми, описать эту ситуацию, когда внешняя по отношению к циклу или аналогичной конструкции локальная переменная не позволяет определить внутри цикла переменную с таким же самым именем, я не знаю. Причем описание должно быть простым, как в C++.

0

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

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

0