Poznáváme C# a Microsoft.NET 16. díl – události

Diskuze čtenářů k článku

avatar
24. 11. 2007 13:02

Programovou oflline verzi seriálu naleznete ke stažení na http://poznavame-c-msnet.wz.cz/

Souhlasím  |  Nesouhlasím  |  Odpovědět
Martin  |  25. 03. 2005 13:05

pouzivat tohle mi prijde vcelku nevhodne:
if (identifikátor_události != null)
identifikátor_události (seznam_případných_parametrů);

Predpokladejme, ze dneska dost aplikaci beha multithreadove, co potom, kdyz mezi vyhodnocenim podminky a zavolanim udalosti nejaky jiny objekt odebere metodu ze seznamu? Pak bude identifikator_udalosti == null a aplikace zdechne? a co v opacnem pripade? zprava se neposle? Neni na to nejake lepsi reseni?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Azazel  |  25. 03. 2005 20:09

pokud chcete, aby váš kód byl thread-safe ("vláknově bezpečný"), tek nemůžete použít popsaný postup:

if (Zmeneno != null)
{
Zmeneno();
}

místo toho použijte něco takového:

ZmenaStavuHandler temp = Zmeneno;
if (temp != null)
{
temp();
}

To že jsou události v C# dělány takto je trochu škoda, protože by asi nebylo nic snazšího, kdyby zavolání "prázdné" události prostě nic neudělalo ... ale tak to bohužel není :/

Souhlasím  |  Nesouhlasím  |  Odpovědět
Azazel  |  25. 03. 2005 20:12

možná trochu kecám :)

ještě to promyslim a pak sem napíšu jak je to doopravdy :)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Azazel  |  25. 03. 2005 21:01

Nedalo mi to a experimentálně jsem si své tvrzení ověřil :)
a opravdu je správné.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Azazel  |  25. 03. 2005 21:11

Sice je to trošku schizofrení povídat si sám se sebou, ale jak jsem tak pročítal net, tak jsem narazil na to, že popsané řešení nemusí fungovat - resp. kód může být zoptimalizován kompilátorem do původní (chybné) podoby :/

podrobnosti o této problematice viz:
http://blogs.msdn.com/jaybaz_ms/archive/2004/03/19/92787.aspx
http://blogs.msdn.com/jaybaz_ms/archive/2004/06/17/158636.aspx
http://blogs.msdn.com/jaybaz_ms/archive/2004/09/16/230681.aspx

Souhlasím  |  Nesouhlasím  |  Odpovědět
Benjamin  |  26. 03. 2005 11:08

Me to zas tak spatne nepripada. Pokud chce mit clovek jistotu bezpeci, staci proste vyvolani udalosti vzdycky obalit zachycenim vyjimky. Aby vyvolani udalosti proste nic neudelalo bych nepovazoval za stastne reseni. Delegat obecne muze neco vracet a neni jasne, co by mel vracet prazdny delegat.

Souhlasím  |  Nesouhlasím  |  Odpovědět
mikeson  |  29. 03. 2005 10:47

Neslo by to takhle?

lock (this)
{
if (Zmeneno != null)
{
Zmeneno();
}
}

Souhlasím  |  Nesouhlasím  |  Odpovědět
Azazel  |  31. 03. 2005 17:12

problém to řeší - podobně jako zachytávání výjímky, ale není to úplně to pravé :)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Benjamin  |  03. 04. 2005 18:35

Kdyz to neni to prave - jak by si tedy resil tu navratovou hodnotu prazdnych delegatu?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Libor  |  04. 10. 2006 09:25

A proč to nemůže být takhle?
try
{
//vyvolani udalosti
Zmeneno();
}
catch (NullReferenceException e) {
}
Při multithreadovém zpracování stejně nikdo nezaručí, že se objekt zaregistruje právě včas před vyvoláním události...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Zasílat názory e-mailem: Zasílat názory Můj názor