има ли изискване при присвояване, ако нещата се оклепат, лявата страна да запази предишната си стойност?

щото само така мога да си обясня следните конструкции, които срещам напоследък:

var обикновено е указател или клас

var = something; // обикновено 0, NULL, или нещо подобно
var = foo()

или

var = something; // обикновено 0, NULL, или нещо подобно
foo(&var)

като във втория случай става дума за чисто out параметър, айде второро мога да приема че има резон, но за първото не виждам никакъв смисъл, освен ако няма някакво такова изискване в стандарта.

Не виждам връзка със някакъв стандарт тук, по-скоро въпрос на защитна практика.

В първия случай първоначалната инициализация може да е необходима, защото ако foo() хвърли exception var няма да е инициализирана.

Във втория случай foo също може да хвърли exception и var да остане неинициализирана.

Два хубави примера на защитно програмиране. Добър стил. По добре от нищо във всеки случай.

добра практика друг път, това е точно да си търсиш белята

добрата практика е ако не разчиташ на стойността в случай на exception.

нали се сещаш, че exceptiona може да бъде хвърлен и по време, а във втория случай и след присвояването, в такъв случай ще имаме наполовина омазана променлива, за която си мислиме, че в нея има коректна стойност.

Ако присвояваш на нещо с предефиниран оператор= никой не ти гарантира, че не може да се хвърли екс. по средата и съответно 'половината' от обекта да е присвоен.

Не съм сигурен синхронни и асинхронни екс. дали се 'засягат' от стандарта, мисля че не. Но би трябвало за ПОД типове да е сигурно, че няма да ти се хвърли екс. То иначе посмъртно не можеш да напишеш нещо exc. safe...

Машина за отделяне на кожа и сланина от парени свине

Най-малкото спестява мислене на този, който го пише.

Мъж вървял по улицата и ръсел пясък. Спрял го полицай:
- К`во праиш ти, бе?
- Пясък ръсим!
- Това виждам, ами защо?
- Против крокодили!
- Ами тука няма крокодили!?
- Е ка че има бе? Нали ръсим.

Като бех малък и биех всичко живо на шах, всички беха убедени че е щото 'уча ходове'. Ся ако ти си мислиш, че за да ти отговори разбирач на въпроса трябва да 'чете стандарти' си в същата позиция.

Не се връзвай ако всички правят дадено нещо - хората са доста инертни и стадни. За пример ще ти дам, че никога не тръгвам на светофар с групата след първия засилил се на червено (ако минавам на червено знам кога и сам).

System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_

и аз така си го представях

следователно от гледна точка на защитното програмиране е безсмислено

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

аз си имам мнение за добрия стил и в доста случаи той влиза в противоречие със стандартите или с това което са казали гурутота.

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


та ако съм разбрал правилно приказката ти за крокодилите и тя е конкретна, а не обща, това са глупости.

Нещо някой не е разбрал. Да видим кой?

Нали &amp каза че var е поинтер. (това или клас не го разбрах, да поясни)

Тогава във първия случай ако се throw-не exception НЕ е възможно пристояване на частично инициализирана променлива, защото няма да има присвояване въобще. Значи първоначалното инициализиране с NULL и последваща проверка за NULL е една винаги работеща идея.

Във втория случай var пак е поинтер. Тогава може да се получи каша благодарение на програмиста. Може и да не се получи ако се следва защитния стил, а именно присвояването да е на края малко преди returna-а (важи и за случай 1 при оператор). Така няма да се получи наполовина инициализирани структури. Тоест и случай 2 е добра идея.

Ако някой още мисли да ми противоречи моля да ми покаже малко код, защото така на сухо всеки може да дрънка каквото му хрумне. И също так искам да видя по-доброто решение.

Думата ми беше по-скоро по принцип за защитното програмиране. Много булшити се пишат в опит да се защитим от несъществуващи заплахи.

Единственото от стандартите което ти трябва да знаеш е реда на изпълнение на присвояването. Останалото е обикновена логика.

За втория пример в много случаи инициализацията има смисъл, например като викаш някоя чужда лошо документирана /и/или проектирана/ функция и не си сигурен /или именно щото много добре знаеш/ тя какви ги върши . Иначе нормалното поведение е да се връща код за успех, който да се проверява преди употреба на така напълнената променлива.

>> има ли изискване при присвояване, ако нещата се оклепат, лявата страна да запази предишната си стойност?

Разбира се. Но само случай на 'истинско' (атомарно) присвояване, каквото си дал в примера. Присвояването се извършва от дясно на ляво и ако гръмне нещо във функцията променливата ще си остане със старата стойност. Така както си го написал ( на два съседни реда и неоградено от try ) няма смисъл, но ако е така бива:

....

var = NULL;

....

try

{

 ....

 var = foo();

 ....

}

....

catch(...)

{

 ....

}

....

delete var;