Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Active 09. 02. 2014, 14:09:51
-
Dobry den,
ani nevim, jak nazvat toto tema, jedna se pouze a obycejny dotaz. Nevite, zda existuje pro C# neco podobneho, jako mam tady pro python? http://pythontutor.com/visualize.html. Moc diky :)
-
mas na mysli kolekce? jinak samozrejme v typovem jazyku nedas do stejne kolekce dve ruzne tridy (pretypovani neresim)
-
Keci, dáš, ale oba objekty musí mít stejného předka, přičemž kontejner musí obsahovat pointery na předka. V C# se pointery standardně nepoužívají, takže asi reference.
-
Hej, ty python programátoři musej bejt ale lamy když potřebujou pro výuku takovou vizualizační sračku. Úžasný jak padá úroveň programátorů (vo těch tragédech který to učej na školách ani nemluvím, to nejsou programátoři, to sou cvičený opice a lepiči). Jinak, stejnou kravinu fakt pro C# nenajdeš. BUde ti muset stačit debugování. Pokud ses urazil, máš to blbý. Sem dneska nasranej.
-
RAII: takze kdyz pak ten objekt z kolekce vytahnes, bude puvodniho typu? nebude... proto pisu, ze neresim pretypovani
-
Hej, ty python programátoři musej bejt ale lamy když potřebujou pro výuku takovou vizualizační sračku. Úžasný jak padá úroveň programátorů (vo těch tragédech který to učej na školách ani nemluvím, to nejsou programátoři, to sou cvičený opice a lepiči). Jinak, stejnou kravinu fakt pro C# nenajdeš. BUde ti muset stačit debugování. Pokud ses urazil, máš to blbý. Sem dneska nasranej.
Co to sem píše za slečinku, co se naučila programovat s debuggerem? :-D To my praví programátoři jsme dříve maximálně sem tam použili něco jako dnešní trace. Ale debugger (tak jak to známe dnes) nebyl. A pak úroveň programátorů spadla, když přišly symbolické debuggery.
No ale připouštím, že u analogových počítačů jsme občas použili osciloskop.
-
RAII: takze kdyz pak ten objekt z kolekce vytahnes, bude puvodniho typu? nebude... proto pisu, ze neresim pretypovani
Staticky/compiletime to vypada, ze vytahnes to, na co je kolekce typovana. Dynamicky/v runtime se ti vrati to, co jsi do ni dal.
-
Kdo nedebugoval numerické výpočty v shaderech podle barvy pixelů je houby drsňák. 8)
-
RAII: takze kdyz pak ten objekt z kolekce vytahnes, bude puvodniho typu? nebude... proto pisu, ze neresim pretypovani
Staticky/compiletime to vypada, ze vytahnes to, na co je kolekce typovana. Dynamicky/v runtime se ti vrati to, co jsi do ni dal.
ano, vrati to, co jsem do ni dal, jenze jelikoz do ni muzu dat pouze objekt typu te kolekce, tak se musi potomci pretypovat, tudiz nasledujici kod bude delat to, co je napsane v komentarich
List<Rodic> kolekce = new List<Rodic>();
kolekce.add(new Potomek()); // objekt se pretypuje na Rodic, do kolekce se ulozi typ Rodic, ne Potomek
kolekce[0]; // vrati typ Rodic
-
No s obrazkama a sipeckama o nicem nevim.
Ale stacit by melo pustit program na debuggeru, krokovat a koukat do okna "Locals" tam by meli byt videt vsechny lokalni promenny a jejich hodnoty. Pripadne si jeste muzes rucne zadat co sledujes (okno "watch"). Nebo klasika v podobne najeti mysi nad promenou a prohlizeni jeji hodnoty (ve visual studiu si je jde i pripnout, takze ty nahledy na hodnotu zustavaji otevreny)
-
Hej, ty python programátoři musej bejt ale lamy když potřebujou pro výuku takovou vizualizační sračku. Úžasný jak padá úroveň programátorů (vo těch tragédech který to učej na školách ani nemluvím, to nejsou programátoři, to sou cvičený opice a lepiči). Jinak, stejnou kravinu fakt pro C# nenajdeš. BUde ti muset stačit debugování. Pokud ses urazil, máš to blbý. Sem dneska nasranej.
Co to sem píše za slečinku, co se naučila programovat s debuggerem? :-D To my praví programátoři jsme dříve maximálně sem tam použili něco jako dnešní trace. Ale debugger (tak jak to známe dnes) nebyl. A pak úroveň programátorů spadla, když přišly symbolické debuggery.
No ale připouštím, že u analogových počítačů jsme občas použili osciloskop.
Pche, LGP-30 měl osciloskop zabudovaný přímo v čelním panelu, Mel Kaye by mohl vyprávět... :-D
Jinak pro C# by se měl nechat použít Baltík, ne?
-
RAII: takze kdyz pak ten objekt z kolekce vytahnes, bude puvodniho typu? nebude... proto pisu, ze neresim pretypovani
Staticky/compiletime to vypada, ze vytahnes to, na co je kolekce typovana. Dynamicky/v runtime se ti vrati to, co jsi do ni dal.
ano, vrati to, co jsem do ni dal, jenze jelikoz do ni muzu dat pouze objekt typu te kolekce, tak se musi potomci pretypovat, tudiz nasledujici kod bude delat to, co je napsane v komentarich
List<Rodic> kolekce = new List<Rodic>();
kolekce.add(new Potomek()); // objekt se pretypuje na Rodic, do kolekce se ulozi typ Rodic, ne Potomek
kolekce[0]; // vrati typ Rodic
No objekt je furt stejnýho typu, přece "přetypováním" - tj. tím že něj dokazuje proměnná nějakýho typu, neztratí část svých vlastností, akorát nejsou "vidět". Co může být různé je jenom typ té proměnné která na ten objekt (správně instanci třídy - to čeho je ten objekt instance se tím jakého typu je proměnná která na něj ukazuje nezmění). A kompilátor může požadovat abys občas explicitně napsal že víš že ta instance je ve skutečnosti třídy typu potomka typu proměnné která na ni v deném místě kódu odkazuje.
-
kdo neprogramoval analogovy pocitac pomoci kabliku je prd drsnak :-)
-
Heh, u analogového počítače se ani nedalo mluvit o programování ... jinak... já se s debugerem neučil programovat (no, nevím ani k čemu by mi byl). Ten používám až v praxi na zjišťování zdroje nestandardního chování programu.
-
ano, vrati to, co jsem do ni dal, jenze jelikoz do ni muzu dat pouze objekt typu te kolekce, tak se musi potomci pretypovat, tudiz nasledujici kod bude delat to, co je napsane v komentarich
List<Rodic> kolekce = new List<Rodic>();
kolekce.add(new Potomek()); // objekt se pretypuje na Rodic, do kolekce se ulozi typ Rodic, ne Potomek
kolekce[0]; // vrati typ Rodic
Bude to pořád potomek, bude dělat věci jako potomek, i když se v kolekci tváří jako rodič. Když v potomkovi přepíšeš metodu a pak ji po vytažení z kolekce zavoláš, bude volat metodu potomka, ne rodiče.
-
Bude to pořád potomek, bude dělat věci jako potomek, i když se v kolekci tváří jako rodič. Když v potomkovi přepíšeš metodu a pak ji po vytažení z kolekce zavoláš, bude volat metodu potomka, ne rodiče.
Jen pokud je virtuální, jinak ne:
http://msdn.microsoft.com/en-us/library/aa645767%28v=vs.71%29.aspx
Takže se to nechová stejně jako potomek.
-
ano, vrati to, co jsem do ni dal, jenze jelikoz do ni muzu dat pouze objekt typu te kolekce, tak se musi potomci pretypovat, tudiz nasledujici kod bude delat to, co je napsane v komentarich
List<Rodic> kolekce = new List<Rodic>();
kolekce.add(new Potomek()); // objekt se pretypuje na Rodic, do kolekce se ulozi typ Rodic, ne Potomek
kolekce[0]; // vrati typ Rodic
Bude to pořád potomek, bude dělat věci jako potomek, i když se v kolekci tváří jako rodič. Když v potomkovi přepíšeš metodu a pak ji po vytažení z kolekce zavoláš, bude volat metodu potomka, ne rodiče.
zalezi na situaci... nicmene nejde o to, jak se bude chovat, ale jakeho bude typu
tim, ze bude typu Rodic nemuzu zavolat metody, ktere ma pouze potomek... to stejne, kdyz se napriklad "pretypuje" na interface, ktery pouziva (taky budu moci zavolat pouze metody, ktere ma dane rozhrani)
tim se ale vzdalujeme od toho, co jsem mel na mysli -> a to, ze v kolekci budou mit vsechny objekty stejny typ, protoze je c# typovy jazyk -> neni mozne ulozit dva uplne rozdilne objekty do stejne kolekce bez pretypovani (ano, kdyz vytvorim List<object>, tak tam narvu vsechno mozne, ale ztratim puvodni typ a schopnosti, aniz by byla nutna dalsi konverze)
-
ano, vrati to, co jsem do ni dal, jenze jelikoz do ni muzu dat pouze objekt typu te kolekce, tak se musi potomci pretypovat, tudiz nasledujici kod bude delat to, co je napsane v komentarich
List<Rodic> kolekce = new List<Rodic>();
kolekce.add(new Potomek()); // objekt se pretypuje na Rodic, do kolekce se ulozi typ Rodic, ne Potomek
kolekce[0]; // vrati typ Rodic
Bude to pořád potomek, bude dělat věci jako potomek, i když se v kolekci tváří jako rodič. Když v potomkovi přepíšeš metodu a pak ji po vytažení z kolekce zavoláš, bude volat metodu potomka, ne rodiče.
zalezi na situaci... nicmene nejde o to, jak se bude chovat, ale jakeho bude typu
tim, ze bude typu Rodic nemuzu zavolat metody, ktere ma pouze potomek... to stejne, kdyz se napriklad "pretypuje" na interface, ktery pouziva (taky budu moci zavolat pouze metody, ktere ma dane rozhrani)
tim se ale vzdalujeme od toho, co jsem mel na mysli -> a to, ze v kolekci budou mit vsechny objekty stejny typ, protoze je c# typovy jazyk -> neni mozne ulozit dva uplne rozdilne objekty do stejne kolekce bez pretypovani (ano, kdyz vytvorim List<object>, tak tam narvu vsechno mozne, ale ztratim puvodni typ a schopnosti, aniz by byla nutna dalsi konverze)
Nikoliv stejný typ, ale stejné rozhraní, to je rozdíl. Pokud s tím máte problém, tak ty objekty nepatří to jednoho seznamu.
-
Bud pretypuje na spolocneho predka:
new List<object>() { "text", 2 };
Alebo pouzije dynamic:
new List<dynamic>() { "text", 2 };
u dynamic sa typova informacia nestraca ale na druhej strane stracam typovu kontrolu.
-
Kdo nedebugoval numerické výpočty v shaderech podle barvy pixelů je houby drsňák. 8)
juhu, jsem drsnak!