Особенности инициализации переменных в C#

← →
icelex © (2011-10-19 11:14) [40]

> И. Павел © (19.10.11 09:12) [38]

нет там ничего про раздвоение
просто в цикле компилятор может быть уверен, что переменная инициализирована, т.к. использование переменной идет уже после инициализации
за пределами цикла нельзя быть уверенным, что переменная инициализирована внутри цикла
псмотри, например, на такой код
string s; int x=0; if (x==0) { s = "test"; } Console.WriteLine(s);
у тебя возникнет та же ошибка

но стоит изменить его на
string s; int x=0; if (x==0) { s = "test"; } else { s="test2"; } Console.WriteLine(s);

как все встает на свои места

← →
oxffff © (2011-10-19 12:14) [41]

http://ru.wikipedia.org/wiki/%D0%93%D1%80%D0%B0%D1%84_%D0%BF%D0%BE%D1%82%D0%BE%D0%BA%D0%B0_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F

← →
И. Павел © (2011-10-20 14:53) [42]

> [40] icelex © (19.10.11 11:14)

Спасибо. В принципе, по логике все понятно: можно считать, что переменная является локальной для того блока, в котором она инициализируется (если только на компилятор не нападет редкое прозрение, как в примере с if/else из [40]). Видимо, это сделали для того, чтобы GC мог удалить ненужные объекты, не дожидаясь того, когда закончится вся функция, в которой они объявлены. В Delphi и C++ это все, конечно, реализовано, проще. В JAVA, по моему, тоже.

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

← →
И. Павел © (2011-10-20 14:54) [43]

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

Т.е. такое приложение даже никогда не скомпилируется, и программисту можно не заботиться обо всех этих хитростях?

← →
oxffff © (2011-10-20 15:06) [44]

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

Если переменная доступна по имени и она является rvalue, значит ее значение тоже доступно.

← →
И. Павел © (2011-10-20 15:11) [45]

> rvalue

"rvalue" т.е. значение переменной "читают" (т.е. она стоит справа или передается как параметр в функцию и т.д.). А если пишут - то это уже может быть вторая переменная, т.к. раз в нее пишут, то ее старое значение, в принципе, и не нужно? Я правильно понял?

← →
oxffff © (2011-10-20 15:19) [46]

> И. Павел © (20.10.11 15:11) [45]

http://www.rsdn.ru/article/cpp/lvalue.xml

← →
И. Павел © (2011-10-20 15:26) [47]

> [46] oxffff © (20.10.11 15:19)

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

← →
oxffff © (2011-10-20 15:33) [48]

> И. Павел © (20.10.11 15:26) [47]

В чем запутался?
Если переменная вышла из области видимости, значит не доступна она ни как lvalue, ни как rvalue. То есть ее больше нет.
Место для это переменной может быть удалено сразу, позже, reuse для других целей.

← →
И. Павел © (2011-10-20 15:39) [49]

> [48] oxffff © (20.10.11 15:33)

Ясно, спасибо. Просто в книге начали отделать термен "область видимости переменной" от "области видимости значения переменной", вот я и подумал, что эти две вещи могут иметь разные области видимости. Запутался, проще говоря. Думаю, просто сменю книгу на Троелсена.

← →
И. Павел © (2011-10-20 15:39) [50]

> отделать

отделять

← →
icelex © (2011-10-20 16:01) [51]

> И. Павел © (20.10.11 15:39) [49]
> Думаю, просто сменю книгу на Троелсена.

у Троелсена этого нет, это основы. Но и нет запуток, которые можно разбирать только тогда, когда есть база.

← →
Inovet © (2011-10-20 16:14) [52]

int a;
{
a = 1;
int b = 2;
}
// b уже нет
// a == 1

или по-другому

int a = 1;
{
int a = 2;
}
// второй a == 2 уже нет
// a == 1

← →
И. Павел © (2011-10-20 16:20) [53]

> // второй a == 2 уже нет

Его и изначально не будет, в C# нельзя создавать во вложенных блоках переменные, одноименные переменным родительских блоков. Но суть ясна, спасибо.

Т.е., подытожив, я ведь могу сказать, что компилятор и не позволит мне обратиться к переменной, значение которой уже вышло из области видимости/пропало?

← →
Юрий Зотов © (2011-10-20 17:04) [54]

> Kerk

Ты неправ, Юпитер. В коде сабжа искомая точка с запятой будет распознана компилятором именно как пустой оператор (потому что концом оператора цикла будет распознана закрывающая фигурная скобка). Синтаксис здесь примерно такой:
пустой_оператор ::= ; оператор_for ::= for заголовок_цикла оператор оператор ::= блок_операторов | простой_оператор простой_оператор ::= оператор_for | пустой_оператор | и т.д. блок_операторов ::= { пусто | список_операторов } список_операторов ::= оператор | оператор ; список_операторов
Отсюда и видно, что точка с запятой ПОСЛЕ закрывающей фигурной скобки будет расценена, как пустой оператор, СЛЕДУЮЩИЙ ЗА блоком. И никакие терминаторы-сепараторы тут ни при чем.

← →
George © (2011-10-20 17:54) [55]

За оффтоп мож и потрут, но так и тянет в название темы вставить "национальной" :)

← →
Юрий Зотов © (2011-10-20 18:25) [56]

> Kerk

Кстати о терминаторах-сепараторах. В классическом Паскале точка с запятой - это действительно statement separator - то есть, РАЗДЕЛИТЕЛЬ ПРЕДЛОЖЕНИЙ. Поэтому он может ставиться только МЕЖДУ предложениями, а вот на такую конструкция компилятор классического Паскаля уже ругнется:
begin a := 3 ; end
поскольку end - это не предложение, а закрывающая скобка (то есть, ПЕРЕД end точка с запятой стоять не может никогда - точно так же, как и в естественных языках).

Но в Delphi от строгости классического Паскаля несколько ушли и та же самая конструкция в Delphi проходит без проблем. Вообще говоря, в Delphi точка с запятой скорее используется так же, как в C, чем как в Паскале. То есть, именно как терминатор и как пустой оператор.

← →
Kerk © (2011-10-20 18:36) [57]

> Юрий Зотов © (20.10.11 18:25) [56]
> Вообще говоря, в Delphi точка с запятой скорее используется
> так же, как в C, чем как в Паскале. То есть, именно как
> терминатор и как пустой оператор.

Различия все еще остаются. Например:

if (a == 1)
b = 2;
else
b = 3;

В C-подобных языках и

if a = 1 then
b := 2
else
b := 3;

в паскале-подобных.

Не знаю насколько заметно оно выделится, так что уточню, что речь о ";" перед else.

← →
Kerk © (2011-10-20 18:49) [58]

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

← →
_Юрий (2011-10-20 19:26) [59]

> Т.е., подытожив, я ведь могу сказать, что компилятор и не
> позволит мне обратиться к переменной, значение которой уже
> вышло из области видимости/пропало?
>
>

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

← →
DiamondShark © (2011-10-20 19:34) [60]

> Юрий Зотов © (20.10.11 18:25) [56]
> > KerkКстати о терминаторах-сепараторах. В классическом
> Паскале точка с запятой - это действительно statement separator
> - то есть, РАЗДЕЛИТЕЛЬ ПРЕДЛОЖЕНИЙ. Поэтому он может ставиться
> только МЕЖДУ предложениями, а вот на такую конструкция компилятор
> классического Паскаля уже ругнется:begin a := 3 ; endпоскольку
> end - это не предложение, а закрывающая скобка (то есть,
> ПЕРЕД end точка с запятой стоять не может никогда - точно
> так же, как и в естественных языках).

Открываем книжку К.Йенсен, Н.Вирт "Pascal User Manual and Report", рус. пер. Д.Б.Подшивалова, М. "Финансы и статистика", 1989.
Самый классический Паскаль из всех паскалей. Смотрим Синтаксические диаграмы:

30. Составной оператор == "begin" Последовательность операторов "end"
31. Последовательность операторов == Оператор {";" Оператор}
32. Оператор == [Метка ":"] (Простой оператор | Сложный оператор)
33. Простой оператор == Пустой оператор | Оператор присваивания | Оператор процедуры | Оператор перехода
...
37. Пустой оператор ==

конструкция:
begin a := 3 ; end

Даёт дерево разбора:

Составной оператор "begin" Последовательность операторов Оператор Простой оператор Оператор присваивания "a := 3" ";" Оператор Простой оператор Пустой оператор "end"

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

← →
Sha © (2011-10-20 19:35) [61]

> Юрий Зотов © (20.10.11 18:25) [56]
> а вот на такую конструкция компилятор классического Паскаля уже ругнется:> begin > a := 3 ; > end

А как же тогда вписать пустой оператор между присваиванием и end"ом?

← →
Inovet © (2011-10-20 19:39) [62]

> [32] Pavia © (18.10.11 23:59)
> Первая причина компьютере есть несколько ядер и они могут
> работать параллельно. Это значит что переменная "i" может
> быть изменена во время выполнения.

Может ты имел ввиду изменения значения переменной всякими потусторонними силами аппаратуры? Для вступления в сговр с тёмными придумано заклинание
volatile

← →
DiamondShark © (2011-10-20 19:56) [63]

> Но в Delphi от строгости классического Паскаля несколько
> ушли

Ни от какой "строгости" (формальная грамматика либо "строгая", либо она не формальная) никто никуда не уходил. Продукция "Пустой оператор" как была с самого начала, так и есть.

Конечно, её наличие приводит к тому, что синтаксически корректными становятся весьма экзотические конструкции:

if 1=2 then else write("kuku")

begin ;;;;;;;; end

Но без неё не была бы синтаксически корректной, минимальная программа:

program P;
begin
end.

или, например, пустой цикл:

repeat until false

← →
Marser © (2011-10-21 03:11) [64]

> stas © (18.10.11 16:54) [9]
>
> Объявляйте так:string s="";

string.Empty тогда уж :-)

← →
jack128_ (2011-10-21 19:21) [65]

> string.Empty тогда уж :-)

а чем смысл?? чем string.Empty очевиднее "" ??

> jack128_ (21.10.11 19:21) [65]
>
>
> > string.Empty тогда уж :-)
>
> а чем смысл?? чем string.Empty очевиднее "" ??

Как минимуму, читается лучше.
У одного реального гуру в С++ коде видел константу и на -1.

← →
jack128_ (2011-10-27 11:15) [67]

>
> Как минимуму, читается лучше.

э-э-э. Ну видимо у нас совсем разные представления о читабельности.

> видел константу и на -1.

Я такие завожу. Для default-значения очень удобно. Мало ли потом default поменяется?

← →
Бездомный (2011-10-27 11:52) [69]

> Мало ли потом default поменяется?

Часто менялся?

> Часто менялся?

Бывало.
В принципе, это достаточно, чтобы константу объявить.

> Ega23 © (27.10.11 11:19) [68]
> Я такие завожу. Для default-значения очень удобно. Мало ли потом default поменяется?

Вряд ли значению String.Empty грозят какие-либо изменения. :)

> euru © (27.10.11 14:42) [71]

Так же в 95 году думали те, кто писал 1 вместо SizeOf(Char) :)

Но вообще, до фанатизма и правда не стоит доводить.

> Вряд ли значению String.Empty грозят какие-либо изменения.
> :)

String.Emty - не грозит, да.

> У одного реального гуру в С++ коде видел константу и на -1.

А вот тут вполне может и того.

> Так же в 95 году думали те, кто писал 1 вместо SizeOf(Char)
> :)

Они даже 1 не писали. :)

← →
Компромисс (2011-10-27 19:04) [75]

Marser © (27.10.11 02:55) [66]

> У одного реального гуру в С++ коде видел константу и на
> -1.

Я, конечно, не гуру, но искренне считаю всех, кто не следует данному правилу, не слишком хорошими программистами.
Есть как минимум 3 достоинства у данного подхода:
1) читабельность/документируемость
Ср. variable = -1; и variable = NOT_FOUND;
2) безопасность. Если вдруг выяснится, что -1 не подходит и надо исправить всюду на -2, то придется проверять все случаи использования -1, чтобы понять, относится ли данное использование к NOT_FOUND или это вообще из другой оперы.
Например,
variable1 = -1;
variable2 = -1;
Вполне возможно, что одна из них должна остаться -1
3) явные зависимости - среда легко покажет, в каких местах используется NOT_FOUND
3)

Особенности инициализации переменных в C# Найти похожие ветки