Чому оператори присвоєння повертають значення?

Це дозволено:

int a, b, c;
a = b = c = 16;

string s = null;
while ((s = "Hello") != null) ;

Наскільки я розумію, присвоєння s = ”Hello”;повинно викликати “Hello”присвоєння s, але операція не повинна повертати жодного значення. Якби це було правдою, то ((s = "Hello") != null)помилка мала б, оскількиnull порівнювали б із нічим.

Які міркування дозволяють операторам присвоєння повертати значення?

Наскільки я розумію, завдання s = "Привіт"; повинно спричинити призначення привіт лише s, але операція не повинна повертати жодне значення.

Ваше розуміння на 100% невірно. Чи можете ви пояснити, чому ви вважаєте цю помилкову річ?

Які міркування дозволяють операторам присвоєння повертати значення?

По-перше, заяви про призначення не приносять значення. Призначення вираз виробляє значення. Вираз призначення - це юридична заява; у C # є лише кілька виразів, які є юридичними твердженнями: очікування виразів, побудова екземпляра, приріст, декремент, виклики та призначення виразів можуть використовуватися там, де очікується заява.

У C # є лише один вид вираження, який не створює якогось значення, а саме викликання чогось, що набирається як повернення порожнечі. (Або, що еквівалентно, очікування завдання без пов'язаного значення результату.) Кожен інший вид вираження створює значення чи змінну, або посилання, доступ до властивостей чи доступ до події тощо.

Зауважте, що всі вирази, які є законними як заяви, корисні для їх побічних ефектів . Це ключове розуміння тут, і я думаю, що, можливо, причиною вашої інтуїції є те, що завдання повинні бути висловлюваннями, а не виразами. В ідеалі, у нас було б рівно один побічний ефект на висловлювання, а жодних побічних ефектів у виразі. Це є трохи дивним , що пліч здійснення код можуть бути використані в контексті вираження взагалі.

Міркування, що дозволяють використовувати цю функцію, полягає в тому, що (1) це часто зручно і (2) є ідіоматичним на мовах, подібних С.

Можна зауважити, що питання задається: чому це ідіоматика на мовах подібних С?

На жаль, Денніс Річі більше не доступний для запиту, але я здогадуюсь, що присвоєння майже завжди залишає після себе значення, яке було щойно призначене в реєстрі. C - це дуже близька до машини мова. Це здається правдоподібним і відповідно до дизайну C, що існує мовна функція, яка в основному означає "продовжувати використовувати значення, яке я щойно призначив". Написати генератор коду для цієї функції дуже просто; ви просто продовжуєте використовувати реєстр, який зберігав призначене значення.

Ви не дали відповіді? Це вмикати саме ті конструкції, про які ви згадали.

Поширений випадок, коли використовується ця властивість оператора призначення - це зчитування рядків з файлу ...

string line;
while ((line = streamReader.ReadLine()) != null)
    // ...

Моє улюблене використання виразів призначення - для ліниво ініціалізованих властивостей.

private string _name;
public string Name
{
    get { return _name ?? (_name = ExpensiveNameGeneratorMethod()); }
}

Для одного, це дозволяє ланцюгові завдання, як у вашому прикладі:

a = b = c = 16;

Для іншого він дозволяє призначити і перевірити результат в одному виразі:

while ((s = foo.getSomeString()) != null) { /* ... */ }

І те й інше, можливо, сумнівні причини, але, безумовно, є люди, які люблять ці конструкції.

Окрім вищезгаданих причин (ланцюжок присвоєння, встановлення та тестування в циклі while, тощо), щоб правильно використовувати usingоператор, вам потрібна ця функція:

using (Font font3 = new Font("Arial", 10.0f))
{
    // Use font3.
}

MSDN відмовляє оголошувати об’єкт одноразового використання за межами використовуючого оператора, оскільки він залишатиметься в обсягах навіть після його вилучення (див. Статтю MSDN, яку я пов’язував).

Я хотів би детальніше зупинитися на конкретному питанні Еріка Ліпперта у своїй відповіді та поставити прожектор на певний випадок, який взагалі ніхто не торкався. Ерік сказав:

[...] призначення майже завжди залишає після себе значення, яке було щойно призначене в регістрі.

Я хочу сказати, що призначення завжди залишатиме після себе значення, яке ми намагалися присвоїти лівому операнду. Не просто «майже завжди». Але я не знаю, тому що я не знайшов цього питання, коментуваного в документації. Теоретично це може бути дуже ефективно реалізована процедура «залишити позаду» і не переоцінювати лівий операнд, але чи ефективна вона?

"Ефективний" так для всіх прикладів, побудованих на даний момент у відповідях цієї теми. Але ефективні у випадку властивостей та індексаторів, які використовують аксесуари для отримання та встановлення? Зовсім ні. Розглянемо цей код:

class Test
{
    public bool MyProperty { get { return true; } set { ; } }
}

Тут ми маємо властивість, яка навіть не є обгорткою для приватної змінної. Кожного разу, коли він буде покликаний, він повернеться правдою, коли намагається встановити свою цінність, він нічого не робить. Таким чином, кожного разу, коли ця властивість оцінюється, він є правдою. Подивимося, що відбувається:

Test test = new Test();

if ((test.MyProperty = false) == true)
    Console.WriteLine("Please print this text.");

else
    Console.WriteLine("Unexpected!!");

Вгадайте, що це друкує? Це друкує Unexpected!!. Як виявляється, встановлений аксесуар справді називається, що нічого не робить. Але після цього аксесуар отримати взагалі ніколи не викликається. Призначення просто залишає після себе falseзначення, яке ми намагалися привласнити нашій власності. І це falseзначення - це те, що якщо оператор if оцінює.

Я закінчу справжнім прикладом світу, який змусив мене дослідити цю проблему. Я зробив індексатор, який був зручною обгорткою для колекції ( List<string>), яку мій клас мав як приватну змінну.

Параметр, надісланий індексатору, являв собою рядок, який повинен розглядатися як значення в моїй колекції. Access access просто поверне значення true або false, якщо це значення існувало у списку чи ні. Таким чином, отримати аксесуар був ще одним способом використання List<T>.Containsметоду.

Якщо встановлений аксесуар набору індексатора був вказаний рядком як аргументом, а правильний операнд - bool true, він додасть цей параметр до списку. Але якби той самий параметр був надісланий аксесуару, а правий операнд - bool false, він замість цього видалить елемент зі списку. Таким чином, встановлений аксесуар використовувався як зручна альтернатива як List<T>.Addі List<T>.Remove.

Я думав, що у мене є акуратний і компактний "API", який обгортає список за власною логікою, реалізованою як шлюз. За допомогою індексатора я міг зробити багато речей за допомогою декількох наборів клавіш. Наприклад, як я можу спробувати додати значення до свого списку та переконатися, що він там є? Я вважав, що це єдиний необхідний рядок коду:

if (myObject["stringValue"] = true)
    ; // Set operation succeeded..!

Але, як показав мій попередній приклад, отримати аксесуар, який повинен бачити, чи є в списку значення справді, навіть не називався. trueЗначення завжди було залишено позаду ефективно знищуючи будь-яку логіку я здійснив в моєму ОТРИМАТИ аксессор.

Якщо призначення не поверне значення, рядок a = b = c = 16також не працюватиме.

Також вміти писати такі речі while ((s = readLine()) != null)Іноді може бути корисним іноді.

Отже, причина, за якою дозволити призначенню повернути призначене значення, полягає в тому, щоб ви могли робити це.

Я думаю, ви нерозумієте, як аналізатор буде інтерпретувати цей синтаксис. Присвоєння буде оцінено спочатку , а результат буде порівняно з NULL, тобто твердження еквівалентно:

s = "Hello"; //s now contains the value "Hello"
(s != null) //returns true.

Як зазначали інші, результатом присвоєння є присвоєне значення. Мені важко уявити, яку перевагу матимеш

((s = "Hello") != null)

і

s = "Hello";
s != null;

не бути рівнозначним ...

Я думаю, що головна причина - це (навмисна) схожість із C ++ та C. Змушення оператора призначення (та багатьох інших мовних конструкцій) поводитись так, як їх колеги C ++ просто слідують принципу найменшого здивування, і будь-який програміст, що приходить від іншого кучерявого, мова дужок може використовувати їх, не витрачаючи багато думок. Бути легко підібрати програмістів на C ++ було однією з головних цілей дизайну для C #.

З двох причин, які ви включаєте у свою посаду
1), щоб ви могли зробити це a = b = c = 16
2), щоб ви могли перевірити, чи доручення вдалося if ((s = openSomeHandle()) != null)

Той факт, що 'a ++' або 'printf ("foo") "може бути корисним або як автономний вислів, або як частина більшого виразу, означає, що C повинен передбачати можливість того, що результати вираження можуть бути, а можуть і не бути б / в. Враховуючи це, існує загальне уявлення про те, що вирази, які можуть корисно "повернути" значення, можуть це зробити. Ланцюг присвоєння може бути трохи "цікавим" в C, а ще цікавіше в C ++, якщо всі розглянуті змінні не мають точно одного типу. Таких звичаїв, мабуть, найкраще уникати.

Ще один чудовий приклад використання, я використовую це постійно:

var x = _myVariable ?? (_myVariable = GetVariable());
//for example: when used inside a loop, "GetVariable" will be called only once

Додатковою перевагою, яку я не бачу у наведених тут відповідях, є те, що синтаксис присвоєння базується на арифметиці.

Тепер x = y = b = c = 2 + 3означає щось інше в арифметиці, ніж мова в стилі С; в арифметиці його твердження ми констатуємо, що x дорівнює y і т. д., а мовою стилю С це інструкція, яка робить x рівним y і т.д. після її виконання.

Це означає, що між арифметикою та кодом все ще достатньо співвідношення, щоб не було сенсу забороняти те, що є природним у арифметиці, якщо немає вагомих причин. (Інша річ, яку мови С-стилю взяли за використання символу рівності, - це використання == для порівняння рівності. Хоча, тому що право-більш == повертає значення, такий тип ланцюга був би неможливим.)

Мені подобається використовувати повернене значення призначення, коли мені потрібно оновити купу матеріалів і повернути, чи не відбулися зміни:

bool hasChanged = false;

hasChanged |= thing.Property != (thing.Property = "Value");
hasChanged |= thing.AnotherProperty != (thing.AnotherProperty = 42);
hasChanged |= thing.OneMore != (thing.OneMore = "They get it");

return hasChanged;

Будьте обережні, хоча. Ви можете подумати, що можете скоротити це до цього:

return thing.Property != (thing.Property = "Value") ||
    thing.AnotherProperty != (thing.AnotherProperty = 42) ||
    thing.OneMore != (thing.OneMore = "They get it");

Але це фактично перестане оцінювати або твердження після того, як воно знайде перше правдиве. У цьому випадку це означає, що він припиняє присвоювати наступні значення, як тільки присвоює перше значення, яке є іншим.

Дивіться https://dotnetfiddle.net/e05Rh8, щоб пограти з цим