Programování v C#

• přiřazení do proměnné vytvoří objekt na garbage-collectované haldě s daty, jejich délkou a overheadem (obsahuje ref. count a datový typ)
• odkaz (reference) na tento objekt se uloží do lokální paměti na místo vyhrazené dané proměnné
• při provádění operací pomocí přetížených operátorů se kontrolují datové typy proměnných (uvnitř objektů na haldě) a podle toho se provede vhodná operace

• ukládá se rovnou hodnota, nevytváří se žádný objekt ani reference – proměnné se vytvářejí rovnou na místě (v lokální paměti)
• objekty se taky ukládají do lokální paměti
• pointery se chovají dost podobně – obsahují adresu proměnné
• halda
  • na haldě se objekty alokují pomocí klíčového slova new
  • alokátor si udržuje overhead
  • dealokace se provádí explicitně pomocí delete
• rozdíl mezi třídou a strukturou je ten, že obsah struktury je defaultně public
• ochranu přístupu (public/private) kontroluje překladač, jinak se nikam neukládá

• .NET
  • běhové prostředí (runtime), mj. alokátor proměti
  • standardní knihovny
• v dotnetu může (kromě C#) běžet víc jazyků – např. Visual Basic .NET, F#, …
• jsou věci, které platí pro C#, a věci, které platí pro .NET

• pointery – jsou ošklivé, nebudeme se o nich bavit
• hodnotové typy – alokované na místě (s výjimkami)
  • enums
  • structures
    • simple types (Int32, Int64, Double, Boolean, Char, …)
    • nullables
    • user defined structures (struct)
• referenční typy – alokované na spravované (managed) haldě
  • classes (e.g. strings)
  • interfaces
  • arrays
  • delegates

• syncblock – kvůli práci s více vlákny (u jednovláknových programů zbytečný), má 8 B
• pointer na typ (zjednodušeně řečeno)
  • třída System.Type, má instance na GC haldě
  • každý datový typ odpovídá jedné instanci třídy
• na referenčních proměnných jde volat .GetType()

pokud klíčové slovo existuje, používáme ho

• např. record class C {}
• při běhu se takové třídy/struktury chovají klasicky
• umožní nám to psát méně boilerplate kódu, protože nám C# překladač vytvoří nějaké chytré metody (např. lepší ToString)
• místo record class se dá napsat jenom record

• auto-implemented props
  • automaticky se vytvoří backing field
  • props bez setteru jsou readonly
  • getter a setter můžou mít různou viditelnost (celku se nastaví nějaká viditelnost, u getteru nebo setteru se pak napíše jiná viditelnost)

• můžu definovat property vycházející z nějakého fieldu
• C# 10 umožňuje u record class automaticky vygenerovat vlastnosti tímto způsobem
  • u record class (v C# 11) jsou vlastnosti immutable (mají get, init)
  • u record struct jsou vlastnosti mutable (mají get, set)
  • u readonly record struct jsou vlastnosti immutable (mají get, init)

lze přetěžovat porovnání, takže někdy může být problém porovnávat s nullem → může se hodit použít operátor is nebo is not

• null = neplatná reference
• null se dá běžně používat u referenčních typů
• proměnná jakoby odkazuje na adresu 0 (což je ale v operačním systému neplatné mapování)

• v ReCodExu je vypnutá, ve Visual Studiu je obvykle zapnutá
• když do zdrojáku napíšu #nullable enable, tak se zapne nová sémantika
• jakmile se zapne, referenční typy nejsou nullable, je potřeba to zapínat otazníkem u každé proměnné
• pak se můžu spolehnout na invariant, že daná proměnná nikdy nebude null
• pokud do non-nullable referenční proměnné přiřadím null, tak to vypíše warning
  • statická analýza neumí říct stoprocentně správně, jestli je přiřazení nullu v danou chvíli špatně, takže nevrací error, ale jenom warning

• Python – duck typing
  • ke kachní poště nepotřebujme kachnu, ale něco, co je kachně dostatečně podobné v těch důležitých vlastnostech
  • implicitně kódem sděluju, co potřebuju od dané proměnné
  • můžu danému kódu přiřadit cokoliv, co dané vlastnosti splňuje (kontroluje se to až za runtimu)
  • duck typing funguje i v C++ u generických typů (ale nejčastěji se objevuje v dynamicky typovaných jazycích)
• C#
  • definuju si kontrakt
    • někdo ho implemenuje (slibuje, že má minimálně metody předepsané kontraktem)
    • někdo ho využívá (slib, že používá maximálně metody z kontraktu)
    • lze to vynucovat více způsoby, ale nejtypičtější jsou interfacy
  • interface – referenční typ
    • konvence psát na začátek názvu I
    • dovnitř se píšou metody / method-like věci (třeba props), nesmí tam být fields
    • jeden řádek může být např. public int m(int a, int b);
    • dříve muselo být všechno public, dneska je dobré tam to public explicitně psát (i když defaultně je pořád všechno public)
    • názvy parametrů metod v interfacu slouží k dokumentaci
    • nemůže existovat instance interfacu, pouze proměnná s typem interfacu (ta může být nullable)
    • class Kachna : IPostovniZvire {…}
    • IPostovniZvire zvire1 = new Kachna();
    • třída může implementovat víc interfaců
  • přístup CLR k implementaci metod
    • synovská třída dědí implementaci metody u rodiče
    • každý interface u třídy vytvoří jakoby tabulku metod, ta se zaplní reálnými implementacemi (respektive ukazateli na implementace)
    • obecně může nastat, že rodič interface neimplementuje, ale syn ano
    • tabulky jsou uloženy v instanci třídy Type (v overheadu daného objektu na haldě)
    • typ proměnné rozhoduje, jakou metodu volám
      • je to důležité při zakrývání metod pomocí new
      • pokud je to interfacová metoda, tak záleží na tom, kam ukazuje tabulka, což vyplývá z toho, která třída implementuje interface
    • pokud chci s nějakým objektem (typicky z interfacu nebo taky u syna rodičovské třídy) zacházet speciálně podle konkrétní třídy, jejíž je instancí, můžu použít operátor is a pak ho castnout
      • klasický zápis: if (a is B) {B b = (b)a; …}
      • zkrácený zápis: if (a is B b) {…}
      • pokud C dědí od B, přičemž B dědí od A, pak instanci třídy C lze takto castnout do B i C (a samozřejmě i do A) – tzn. pro všechny tyto typy vrací operátor is hodnotu true

• zdrojáky .cpp, jeden po druhém je překládáme, vznikají object fily .obj (nebo .o), tam je přímo strojový kód
  • ty se linkerem zpracují do jednoho .exe souboru
• strojový kód typicky cílí na konkrétní platformu
• kdybych chtěl, aby program běžel na jiné platformě, vezmu zdrojový kód a celý ho znova přeložím
• 64bitové Windows podporují 32bitové programy
• uživatelé musí vědět, jakou verzi programu si mají vybrat
• knihovny
  • překladač programu používá hlavičkové soubory knihoven

• Apple 6502 → Motorola 68000 (32bit) → IBM PowerPC (32bit) → Intel x86 (32bit) → Intel x64 (64bit) → Apple M1/M2 (ARM64, 64bit)
• vymysleli fat binary (universal executable) – jeden spustitelný soubor, v něm je více verzí programu najednou
• řeší to problém zpětné kompatibility, ne dopředné

• soubory .cs
• .csproj, předává se build systému dotnetu, ten pustí C# compiler csc.exe (dnes css.dll)
• vypadne z toho executable, uvnitř je CIL kód (common intermediate language)
• ke spuštění programu potřebujeme CLR (common language runtime), obvykle je tam JIT (just-in-time) překladač, ten zajišťuje překlad a spuštění pro konkrétní platformu
• CLR … virtual machine (VM)
• CIL kód … managed/řízený kód
• dotnet executable soubor … assembly
• Java to má podobně
  • Java intermediate language = Java bytecode
• všechny programovací jazyky dotnetu se překládají do CIL kódu
• optimalizace dělá až JIT
  • ale má na to omezený čas, aby se program spustil dostatečně rychle
• JIT používá překlad po metodách
• ale dá se použít AOT (ahead of time) překlad – takže pak v .exe souboru je nejen assembly (ten se použije pro nepodporované platformy), ale taky přímo strojový kód, který tak může být efektivnější
  • některé věci tam nefungují
• knihovna se překládá velmi podobně
  • .csproj + .cs soubory
  • csc přeloží na .dll soubor
  • rozdíl mezi .exe a .dll není skoro žádný, akorát .exe má entry point (dneska může být i executable .dll s entry pointem, takže podle přípony to není poznat)
• v .exe/.dll souboru je vždy CIL kód a metadata
• když v programu používám knihovnu, odkazuju se při překladu přímo na její .dll soubor (metadata uvnitř)
• v metadatech musí být v zásadě celá hlavička metody (včetně názvů parametrů – kvůli dokumentaci a explicitnímu přiřazení)
• od dotnetu 5
  • a.exe soubor … Windows loader
    • spustí správný soubor clr.dll
    • jeho pomocí spoustí a.dll soubor
  • nástroj dotnet
    • obsahuje SDK toolchain
    • provádí nalezení správného souboru clr.dll a spuštění a.dll souboru (to je užitečné hlavně mimo Windows)
    • stačí napsat dotnet a.dll
    • dotnet a.exe nefunguje, protože exe soubor se nedá spustit jako dotnetí
• pomocí nástroje ildasm.exe se můžeme podívat dovnitř metadat a CIL kódu
• ILSpy je dekompiler, který zkouší obnovit původní kód
• kromě dll a exe souboru se k programu obvykle generuje i .pdb soubor s informacemi k debugování (typicky názvy lokálních proměnných)
  • ten pak používá i ILSpy, pokud je k dispozici

• class A
• class B : A
• dědění (kopírování dat) probíhá až v JIT
• v B je všechno, co bylo v A, kromě konstruktoru
  • instanční
    • fields
    • methods
  • statické
    • fields
    • methods
• instanční metoda má implicitní parametr this, který je typu dané třídy
• u rodiče se někdy hodí klíčové slovo abstract, to zakazuje vytváření instancí dané třídy
• třída může implementovat libovolné množství interfaců
• každá třída má právě jednoho předka (pokud jsme žádného nedefinovali, tak je to Object)
• typy v C# (kromě pointerů) tvoří strom
• konstruktory se nedědí
  • konstruktor můžu chápat jako instanční metodu
  • volání rodičovského konstruktoru zajišťuje klíčové slovo base
    • public B(params1):base(params2) {
    • není to optional, rodičovský konstruktor se volá pokaždé (defaultně bez parametrů)
  • konstruktor předka se vždy volá před konstruktorem potomka
• a is B vs. a.GetType() == typeof(B)
  • první varianta se ptá, jestli to, co je v a, je přiřaditelné do typu B
  • druhá varianta se ptá, jestli typy přesně odpovídají
  • druhá varianta je mírně rychlejší
• is za runtimu vyhodnocuje, zda instance splňuje nějakou podmínku
  • a is PODMINKA-NA-INSTANCI
  • a is null
  • skládání podmínek se provádí pomocí „slovních“ operátorů and, or, not
  • pro nullable typ Person? můžu provést kontrolu pomocí is not null nebo is Person person
  • operátor . vs. null-forgiving operátor ?.
    • a.Length vs. a?.Length
    • obdobně a[index] vs. a?[index]
    • typ výsledku se liší v nullabilitě (pokud by a.Length bylo typu X, a?.Length bude typu X?)
  • příklad použití ke zpřehlednění kódu
    • zadání: nemá platit, že x je menší než 4
    • implementace 1: x >= 4
    • implementace 2: !(x < 4)
    • implementace 3: x is not < 4
    • skládání: x is not null and not < 4
      • pokud by x byla vlastnost (property), tak se getter zavolá pouze jednou (pro klasické boolovské výrazy by se volal dvakrát: x != null && x >= 4)
  • dá se použít syntaktická zkratka person is { FirstName: "Vít", LastName: "Kološ" }
  • občas se místo not null používá is {}, ale není to moc praktické
  • dá se to složit na person is Employee { Salary: > 500, LastName: "Kološ" } employee
  • zároveň můžu rovnou přiřadit do proměnné person is Employee { Salary: > 500, Salary: var salary, LastName: "Kološ" } employee

• readonly int x1; – ukládá se u každé instance, což se nám nehodí
• static readonly int x2;
  • je uložený pouze jednou, ale pracuje se s ním jako s proměnnou (ve strojovém kódu se vykonává load z paměti…)
• const int x3 = 5;
  • je to konstanta pro celou třídu, nezabírá to místo, hodnota je uložena přímo v metadatech, překladač optimalizuje počítání s konstantami (takže předem provede některé výpočty; této optimalizaci se říká constant folding)
  • do takové konstanty lze uložit jen základní hodnotové typy a stringy – pokud nám to nestačí, tak musíme použít static readonly
  • pokud konstanty používáme v knihovnách, tak se může stát, že vydáme novou verzi knihovny, někdo si ji stáhne, ale přitom bude mít starou verzi programu, v níž bude „zakompilovaná“ stará konstanta ze staré verze knihovny

• metoda bez parametrů, volá ji automaticky CLR
• zavolá se před prvním použitím toho typu jako takového
• není úplně jasné, kdy přesně se zavolá
• pokud se daný typ používá a je možné, že jeho class constructor ještě nebyl zavolán, provede se kontrola tohoto zavolání a následně se případně zavolá
  • může nastat situace, že by se tato kontrola prováděla při každém volání funkce, kterou je ale potřeba volat mnohokrát – v takovém případě může být vhodné této kontrole zabránit např. vytvořením zbytečné (prázdné) instance objektu daného typu někdy na začátku programu
• class konstruktor se generuje automaticky, ale dá se napsat ručně – název metody odpovídá názvu třídy, použije se klíčové slovo static, viditelnost se neuvádí

• dovnitř se automaticky generují inicializace fieldů u objektu
• kód ve složených závorkách za this() se provede až po volání tohoto konstruktoru
• nejdřív se inicializují fieldy a volají se funkce potřebné k jejich inicializaci → pak se volá this() nebo base() → pak se provádí kód ve složených závorkách
• tohle je vlastnost C#, ne CLR
• když zkusíme během inicializace fieldů přistoupit k neinicializovanému fieldu, tak tam bude nula (tzn. 0, null nebo false)

• typické použití k uvedení jména argumentu při vyhození ArgumentException
• nameof(x) je ekvivalentní se zápisem "x", ale když proměnnou x přejmenuju, tak na "x" snadno zapomenu

např. int speed = 300_000;

• enum Season { Spring, Summer, Autumn, Winter }
• hodnotový typ
• předává se jako int (nebo jiný základní typ)
• s proměnnými můžu provádět aritmetické operace, ale musím hlídat, jestli se nedostanu mimo definované hodnoty (pak se s proměnnou zachází jako s klasickým číslem)
• metoda ToString defaultně vrací název dané hodnoty v enumu (pro nedefinovanou hodnotu vrátí číslo)
• lze ručně nastavit hodnoty, pokud danou hodnotu nenastavím, tak se vezme předchozí hodnota a zvýší se o jedna
  • hodnoty můžou být i stejné – pak se tyto hodnoty při porovnání rovnají, ToString vypíše tu, která je v seznamu uvedena jako první
  • někdy se enum používá jako bitová maska – takže jako hodnoty přiřadíme mocniny dvojky, s označením [Flags] tento přístup podporuje i ToString (vypíše seznam „zvolených hodnot“)
• existuje hodně pomalá metoda Enum.Parse, která pro zadaný název hodnoty v enumu dokáže najít číslo (funguje i pro Flags)
  • používá koncept reflection

má to smysl jen ve výjimečných situacích (pokud má něco krkolomný název)

• je vhodné řešení pomocí struktur (takže budu mít např. Row.Value)
• není až tak rozumné použít enum

• public static int a = 1;
• public static int b = 2;
• [Benchmark]
• public int Add() { return a + b; }
• pozor, je potřeba, aby benchmarkovací funce vracela výsledek operací, které měřím, aby JIT nezahodil operace jako takové
• pozor, kdybych používal private nebo readonly hodnoty, tak by to JIT mohl optimalizovat do konstant, takže by operace neprováděl
  • běžně se provádí constant-folding, tzn. sčítání konstant 1+2 se přeloží jako 3, tudíž by něco podobného mohlo nastat i tady

• JIT dělá tuhle optimalizaci za nás (method inlining) – ale jen tam, kde to dává smysl
• kdybychom funkce moc inlinovali, tak by procesor musel pro instrukce sahat do nižší úrovně cache, takže by se program řádově zpomalil
• když má CIL kód méně než 20 bajtů, tak je to kandidát pro inlinování
• např. rekurzivní funkce nebo metody na instancích s určitým interfacem se nedají inlinovat
• pokud chci ručně ovlivnit inlining, tak můžu použít System.Runtime.CompilerServices a jeho atributy [MethodImpl(…)], kde parametr může být MethodImplOptions.AggressiveInlining nebo taky MethodImplOptions.NoInlining (další varianty se týkají třeba optimalizace)
  • tohle jsou mikrooptimalizace – ty nemáme dělat, pokud k tomu nemáme opravdu pádný důvod

synovská třída pak má dvě metody s daným názvem – jednu svoji a jednu od rodiče

• má implementaci v A
• pomocí override definujeme implementaci v B
• opět se podle typu výrazu rozhoduje první krok – bude se volat metoda A.f(), ale na úrovni CIL kóu se použije virtuální volání (callvirt)
• na úrovni CIL kódu není poznat, která implementace se bude volat – to se rozhoduje za runtimu
• každý typ s virtuálními metodami má tabulku virtuálních metod (VMT), ta se při dědění kopíruje (a prodlužuje), u overridnutých virtuálních metod se změní odkaz na implementaci
• takže to, která implementace se reálně zavolá, závisí na třídě, jejíž instanci jsme vytvořili (nehledě na typ)

• bez warningů by mohlo dojít k tomu, že by se – po zakrytí metody – kód v jiné části programu začal chovat divně a nevěděli bychom proč
• ale error to není, protože se může stát, že se v knihovně objeví metoda, která tam původně nebyla → najednou zakrýváme metodu → museli bychom opravovat kód

nesmíme vyrábět instance třídy s abstraktní metodou, takže třída musí být abstraktní

• callvirt → call [… VMT[…]]
• výkonostně to vychází podobně
• ale nevirtuální volání se dá inlinovat (virtuální ne), takže u častého volání krátkých metod může být vhodné používat nevirtuální metody, aby JIT mohl optimalizovat inlinováním
• je vhodné defaultně používat nevirtuální metody (a virtuální jen tehdy, kdy to dává smysl)

• všechny metody jsou automaticky virtuální
• proč je to špatně
  • když píšeme metody v třídě A, které se navzájem volají, tak obvykle spoléháme na to, jakým způsobem tyto metody ovlivňují vnitřní stav
  • takže nahrazení nějaké z metod může tu třídu rozbít

• každý typ má tabulku virtuálních metod (VMT)
  • ta obsahuje odkazy na implementace virtuálních metod
• každý typ, který implementuje interface (a jeho potomci), má tabulku pro každý interface
  • ta obsahuje odkazy na metody odpovídající metodám z interfacu

• vynucení kontraktu – interface ho vynucuje hned
• veřejný kontrakt – abstraktní metody můžou být protected
• slib rozšiřitelnosti – u virtuální metody je to opt-out (pomocí sealed), u interfaců opt-in (musím znova říct, že implementuju interface)
• data – u interfaců nelze (kvůli vícenásobné dědičnosti)
• vícenásobná dědičnost – nelze u abstraktních metod

• řešením by bylo použít protected metodu a tu volat z public metody, ale to se obvykle nedělá
• lepší je použít base.m()
• base je jako this, ale přímý předek
• pokud metodu voláme jako base.m(), tak se metoda volá nevirtuálně
• takže base.m() volá metodu m() přímého předka (nehledě na to, jestli je virtuální)

• metoda Eat třídy Apple bude virtuální
• GoldenApple je potomek Apple, přepisuje virtuální metodu Eat

• b.dll jsme překládali vůči starší verzi a.dll
• takže i zlatá jablka budeme jíst nevirtuálně?
• C# překladač dělá trik, že i nevirtuální metody volá virtuálně – tedy se rozhodnutí přesouvá na JIT
• tedy i nevirtuální metody mají v CIL kódu instrukci callvirt
• fungování virtuálních a nevirtuálních metod to nijak nemění, jen to řeší poměrně častý problém, který nastává při nezávislém vývoji knihoven a kompilaci na nich závislých programů

value … kontextové klíčové slovo (je klíčovým slovem pouze v setteru vlastnosti)

• void f() => return x;
• ale nepoužívat uvnitř metod – to jsou lambda funkce, což je poměrně složitý koncept

• int X { get { return x; } }
• int X { get => x; } }
• int X => x;

• Length vs. GetLength()
• problém s Count a Count()
  • lepší by bylo Count a GetCount()

když v interfacu požaduju jen getter, můžu v jeho implementaci přidat i setter

změna fieldu na vlastnost mění rozhraní knihovny (a je potřeba opravit/překompilovat programy, které ji používají)

• spočítám jen jednou, budu cachovat
• potřebuju uložit „neplatnout hodnotu“ (abych věděl, že ještě nemám spočítáno)
  • mohl bych použít null, ale typ double podporuje i hodnotu not a number (NaN), která by tady byla vhodnější (protože nullabilita fieldu zvětšuje velikost celé struktury)
  • při porovnávání NaN je třeba myslet na to, že existuje víc variant NaN (takže je lepší použít metodu double.IsNaN)
• u vlastností X, Y je potřeba přidat settery, které budou kromě nastavení hodnoty backing fieldu invalidovat délku
  • pokud jsem X, Y definoval jako auto-implemented properties, je potřeba přidat backing fieldy

• můžu overridovat getter i setter nebo jen jeden z nich
• ale když mám virtuální vlastnost s getterem, tak v jejím overridu nemůžu přidat setter

pokud je výchozí hodnota nějaký field, tak pak pozdější změna hodnoty fieldu neovlivní hodnotu té vlastnosti

• vlastnost by neměla mít side-effects (i kdyby byla rychlá)
• je vhodnější, aby to byla metoda

• public – přístup není omezen
• private – přístup je omezen na kód v daném typu
  • C# podporuje vnořené typy – takže kód ve vnořeném typu má taky přístup k private položkám typu, v němž je vnořen
• protected – přístup je omezen na daný typ a typy, které z něj dědí
• internal – přístup je omezen na aktuální sestavení
• protected internal – přístup je omezen na aktuální sestavení nebo odvozené typy
• private protected – přístup je omezen na aktuální sestavení a odvozené typy
• file – přístup je omezen na aktuální zdroják (v C# 11)

• int a = 5; se dá rozdělit na int a; a a = 5;
• int a; … deklarace proměnné
• lokální proměnná vzniká v místě deklarace
• nadřazené složené závorky odpovídají životnosti proměnné
• takže třeba ve while cyklu se proměnná s daným názvem vytváří v každé iteraci
  • na začátku cyklu ALLOC → SUB SP,4
  • na konci cyklu FREE → ADD SP,4
• JIT může udělat optimalizaci, že alokaci a dealokaci vystrčí mimo cyklus
  • někdy taky dané místo na zásobníku recykluje pro různé proměnné
• pokud lokální proměnnou nepotřebuju sdílet mezi různými iteracemi cyklu, nedává smysl se to snažit mikrooptimalizovat vystrčením deklarace mimo cyklus

• některé jazyky umožňují uvnitř bloku deklarovat již deklarovanou proměnnou, která bude nezávislá na té deklarované výše – v C# to nejde
• nelze redeklarovat parametr funkce
• nelze redeklarovat proměnnou deklarovanou výše ve vnějším bloku
• nelze redeklarovat proměnnou deklarovanou výše ve vnitřním bloku

• situace, kdy inicializuju v podmíněném bloku – je potřeba nějak zajistit default inicializaci (ideálně s komentářem, pokud se ta hodnota nikdy nepoužívá; taky je vhodné rozumně umístit vyhození výjimky)
• příklad s if (x is int a) – chová se jako deklarace uvnitř podmíněného bloku

• hodnota (u hodnotových typů)
  • velikost odpovídá velikosti datového typu
  • u struktur lze použít new, které nic nealokuje, ale zavolá konstruktor
• reference (u referenčních typů)
  • je tam uložená adresa, takže velikost odpovídá velikosti adres
  • adresa vede na GC haldu
  • adresa ukazuje na celý objekt
  • explicitní alokace pomocí new
  • tu adresu nelze zjistit (zčásti proto, že GC objekty na haldě někdy přesouvá, proto se adresa může měnit)

pozor: v Javě jsou dva různé typy, int (hodnotový) a Integer (referenční) – v C# je to ten samý typ System.Int32

můžu volat ToString()

• nejde to, unboxing konverzi nelze kombinovat s truncation konverzí
• vyhodí to runtime exception
• musíme napsat obě konverze: (int)(long)o

• pointer = adresa
• int* a, b; – hvězdička se váže k typu, ne k identifikátoru (takže se nepíše int *a, *b;)
• a = &c;
• *a = d;
• Console.Write(*a);
• žádná omezení – podobně jako v C++
  • může ukazovat kamkoliv
• hodí se to k low-level programování nebo komunikaci s nějakými nativními funkcemi
• pointery nesleduje garbage collector

• tracking reference
• GC je sleduje
• můžou ukazovat pouze na data – na GC haldu, statické fieldy nebo lokální proměnné
• tracking reference = adresa, nelze ji zjistit
• automatická dereference
• může to vést doprostřed objektu, ale musí to ukazovat na celý field

• sjednocení všech funkcí dotnetu a C++
• to nejhorší z obou světů
• tracking reference se deklarují int%
• obecné tracking reference jsou pořád příliš nebezpečné na to, aby se s nimi dobře programovalo

• tracking referenci typicky předáváme jako argument funkce
• věc, na kterou tracking reference ukazuje může být
  • static
  • lokální proměnná
  • GC halda
    • garbage collector objekt nesebere, dokud na něj směřuje tracking reference

výjimečným případem, kdy to smysl dává, je třeba zvětšení pole – vyrobím nové pole, položky překopíruju a do tracking reference přiřadím nové pole

• uvnitř funkce s výstupními parametry se s nimi zachází jako s neinicializovanými (dá se z nich číst až po prvním zápisu)
• před standardním ukončením funkce s výstupními parametry se do každého z nich musí alespoň jednou zapsat
• pokud funkce skončí výjimkou, tak se do výstupních parametrů zapsat nemusí, ale to není problém, protože catch blok nemůže spoléhat na inicializaci v try bloku
• pokud proměnnou deklaruju nad try/catch, v try bloku ji inicializuji a v catch bloku vyhodím výjimku dál (pomocí throw;), tak pod try/catch můžu proměnnou považovat za inicializovanou
• pokud napíšu if (int.Parse(s, out int x)), tak se proměnná deklaruje před ifem

• když mě výstupní hodnota nebo návratová hodnota funkce nezajímá, tak použiju podtržítko jako název lokální proměnné
• pozor, pokud je někde v kontextu funkce proměnná/funkce s identifikátorem _, tak se vypne discard syntaxe a používá se jako standardní identifikátor proměnné

• zakončuje příkaz, což je jeden nebo více výrazů
• výraz a = 1 má hodnotu 1
• a = b = c = 123;
• středník říká, že se má zahodit hodnota výrazu
• pokud volám funkci, která není voidová, tak je vhodné její návratovou hodnotu zahodit pomocí přiřazení do discardu (z dokumentačních důvodů)

• při volání funkce se dá volat i hodnotově bez klíčového slova
• in má smysl u výkonnostních optimalizací hodnotových typů (typicky u počítačových her)

v případě I i1 = new A();, kde I je interface, tedy funguje i1.ToString();

• kdybychom měli dva structy, kde by jeden dědil od druhého a jeden by byl větší, tak by nefungovalo přiřazení jednoho do typu druhého (protože by neseděla velikost)
• proto je dědičnost structů zakázána

• alokuje se na GC haldě
• kdyby se délka měnila, pro GC by to bylo moc komplikované
• podobně i u jiných objektů se velikost po alokaci nemění

v poli můžou být přímo hodnoty u hodnotových typů nebo adresy u referenčních typů

pozor, u objektů s indexerem tohle nefunguje

ale obvykle není dobrý nápad to používat

• zubatá (jagged)
  • pole polí
    • int[][] a = new int[2][];
    • a[0] = new int[3];
    • a[1] = new int[4];
    • int x = a[0][1];
  • jako v Javě
  • nevýhoda: každé pole má svůj vlastní overhead
• obdélníková (rectangular)
  • mezi hranaté závorky napíšu jednu nebo více čárek
  • int[,] a = new int[2, 3];
  • int x = a[0, 1];
  • jako v C/C++
  • v dotnetu je s nimi problém kvůli Visual Basicu .NET
    • Visual Basic umožňuje začínat od libovolného indexu
    • to by snížilo efektivitu
  • v dotnetu
    • jednodimenzionální pole jsou striktně indexovaná od nuly
    • vícedimenzionální pole umožňují začínat od libovolného indexu
      • VB.NET je používá i pro jednodimenzionální pole
      • ale jsou pomalejší – i v C#
• závěr
  • jagged jsou obecně rychlejší (cca 2×)
    • ale pokud už s každou naindexovanou položkou pole budu provádět nějaký výpočet, tak tam nebude velký rozdíl v rychlosti
  • obdélníková jsou paměťově úspornější (v určitých situacích), lépe se zapisují

po inicializaci pole jsou všechny hodnoty nastaveny na default

• nedá se z nich vytéct ven
• JIT se snaží range check optimalizovat – typicky u cyklů

• metoda na struktuře má implicitní parametr – tracking referenci na strukturu
• když budu mít metodu MultiplyBy, která upravuje hodnoty ve struktuře, tak points[0].MultiplyBy(3) se bude chovat různě v případě pole a listu – opět viz problém s tracking referencemi a indexery
• proto dává smysl, aby struktury byly immutable
• mutable struktury jsou divné

• tedy by se takhle dal implementovat List – indexer by vracel tracking referenci
• C# to takhle nedělá, getter indexeru vrací hodnotu a setter modifikuje hodnotu

• když se vytváří pole struktur (nebo se definuje lokální proměnná daného typu), tak se to tváří, jako by se volal implicitní bezparametrický konstruktor struktury (ale ve skutečnosti se nevolá – jen se nuluje paměť)
• od C# 9 můžou mít fieldy výchozí hodnotu
  • jsou tam dva bezparametrické konstruktory – jeden implicitní, druhý můj
  • výchozí hodnoty se přiřazují jen když volám explicitně konstruktor (ten svůj)

takže není potřeba volat konstruktor

• goto skocSem;
• label – skocSem:

• nesmí se skákat mimo funkce
• nesmí se skákat do složených závorek

• break z vnořeného cyklu
• skočení zpátky před cyklus
• stavový automat
  • alternativa: příkaz switch

• každá větev musí končit příkazem break/return/goto
• větev může mít několik case labelů
• JIT ho může optimalizovat – tedy bývá efektivnější než kaskáda ifů
• pomocí goto se dá skočit na konkrétní case (z vnitřku switche)

• int result = x switch { > 10 and < 20 => 1000, int b => b + 10, null => -1 };
• místo case se píšou šipky
• místo default se píše _ =>
• není tam žádná magie, přeloží se to do rozumné kaskády ifů a goto

• a is X {Prop1: …, Prop2: …}
• a is {…}
• a is X(…, …)
• int result = p switch { Person("Petr", var lastName) => lastName.Length, Person(var firstName, "Vesely") => firstName.Length, _ => 0 };
  • Person musí mít metodu Deconstruct
  • všechny parametry jsou výstupní
  • Person(string x, string y) se mapuje na Deconstruct(out string x, out string y)
  • pokud vhodná metoda Deconstruct neexistuje, tak se to nepřeloží
  • používá se ducktyping
  • u record tříd se Deconstruct generuje automaticky
  • metod Deconstruct může být víc
  • dekonstruktor by neměl být výpočetně náročný
  • další použití dekonstruktoru je u tuples – ale ty jsou složitější, takže budou v letním semestru
• a is [< 2, > 1, .. int[] restArray, int x]
  • takové pole musí mj. mít aspoň 3 prvky
  • do restArray se uloží kopie (ta se alokuje na GC haldě), to pole může být i prázdné
  • pozor na konkrétní kolekci – obecně u IEnumerable nemusíme být schopní efektivně najít poslední prvek
• novinka v C# 12
  • inicializace kolekcí pomocí hranatých závorek
  • dají se tam vkládat kopie polí

• Messsage
• StackTrace – popis toho, kde výjimka vznikla

je vhodné používat rozumnou hierarchii typů, aby uživatelé typů mohli výjimky filtrovat

• ale to pak může vést k problémům se StackTracem
• takže je lepší napsat throw new …

pokud je bezparametrický, tak to je to samé, jako by tam byl typ Exception (v C# 1 to znamenalo něco jiného)

• můžu vyhodit jinou výjimku
• můžu opět vyhodit tu samou (existující) výjimku – pomocí throw;

• pokud chybové stránky řešíme vyhazováním výjimek, tak to vede k větší náchylnosti na DDoS
• ale výjimky nám poskytují informaci o chybě
• tedy dává smysl vracet „silně typovanou“ strukturu ViewOrError
  • ta má jeden field typu object, kde obsahuje View nebo Error
  • implementujeme vlastnosti, které vrátí správný View (u Erroru speciální chybovou stránku) a Error (u normálního View vrátí null)

• některé se chápou jako bug
  • OutOfRangeEx.
  • NullReferenceEx.
• některé se chápou jako špatné použití funkce
  • ArgOutOfRangeEx.
  • ArgNullEx.
• někdy je vhodné definovat vlastní výjimky – jako potomky ApplicationException

• před úpravou platí invarianty o datech ve struktuře (např. platnost ID)
• po úpravě také
• během úprav invarianty neplatí
• co když se vyhodí výjimka během úprav?
  • výsledkem jsou vadná data v datové struktuře
• typický příklad
  • do nákupního košíku přidám knížku, pak jí nastavím ID a počet
  • pokud selže parsování ID, v seznamu se objeví knížka s nulovým ID a počtem, což porušuje invariant
• někdy dává smysl přístup defenzivního programování – zabránit tomu, aby situace vůbec mohla nastat (nejdřív vytvořím knížku, až pak ji přidám do seznamu)
• dalším řešením je zrušit akce, které jsme provedli
  • pomocí catch bloku – tady dává smysl zachytávat úplně všechny výjimky, zrušit provedené akce (UNDO) a pokračovat v šíření výjimky
    • rethrow – pomocí throw;
    • pozor, catch (Exception ex) v kombinaci s throw ex; není ekvivalentní, protože se přepíše stack trace
      • může to dávat smysl, pokud je to server a stack trace by byl vidět na internetu
• finally blok
  • provádí se až po catch bloku (nebo po try bloku)
  • u streamu typicky používáme buffer, ten se splachuje pomocí Flush – to se hodí mít ve finally bloku
  • když vypisujeme XML, vypisujeme např. řádky tabulky a nějaký řádek selže, tak chceme uzavřít tabulku – taky ve finally bloku
  • zavírání souborů
    • soubory jsou cenné zdroje
    • file lock (aplikace mají výhradní přístup k souboru)
  • tedy zavírání souborů bychom chtěli dělat ve finally blocku
  • každá věc, kterou bychom měli včas zavírat, by měla implementovat rozhraní IDisposable (má metodu Dispose)
  • protože se try & finally s Dispose používá často, tak můžeme používat using blok, což je syntaktická zkratka
    • using (var f1 = new FileStream("...")) { ... }
  • alternativa místo using = nullable objekt a klasický try + finally (tohle umožňuje použít i catch blok)
  • jak řešit několik usingů?
    • napsat je pod sebe bez středníků a složených závorek – jako vnořené bloky (poslední z nich už má klasicky složené závorky)
    • using jako deklarace – Dispose se zavolá na konci složených závorek (tzn. tam, kde končí životnost proměnné)
      • pozor, tohle často svádí k tomu, že se objekt disposuje pozdě
      • using var f1 = new FileStream("...");

• platí pouze ve zdrojáku (pomocí global using v celém projektu)
• using System; … namespace
• using C = Console; … alias pro určitý typ
  • často vede k menší čitelnosti kódu
  • v C# 12 lze i pro generické typy (dřív ne)
  • může to vést k tomu, že vytvoříme dva aliasy pro tu samou třídu – čímž ztrácíme silnou typovanost

• to obvykle v C# neděláme
• tedy stačí implementovat IDisposable pomocí jednoduché metody Dispose
• v metodě Dipose je potřeba detekovat, že už Dispose bylo jednou zavoláno – nemá se provést nic
• je potřeba počítat s tím, že po zavolání Dispose bude někdo chtít k objektu přistupovat – v takovém případě vracet ObjectDisposedException (asi detekovat pomocí bool fieldu)

• to dává smysl, pokud je třída vlastníkem toho zdroje
• jinak (typicky u writerů) není dobrý nápad soubor implicitně zavírat

• metody – new StreamReader, int.Parse
  • zachytíme konkrétním catch blokem pro danou výjimku
  • catch bloky se kontrolují postupně shora dolů – vezme se první, který matchuje
• rethrow v catch bloku
  • typicky v catch bloku je UNDO (obnovení invariantů) a nějaké logování
• u metody LoginUser máme nějakou implementaci – třeba pomocí souborů, takže když uživatel neexistuje, vyhodí se FileNotFoundException
  • druh výjimky ale potom souvisí s implementačním detailem
  • chceme tu výjimku nahradit nějakou hezčí výjimkou
  • budeme mít try catch blok, který zachytí FileNotFoundException a vyhodí ProfileNotFoundException
  • přepíše se nám tak ale stack trace
  • naštěstí má Exception vlastnost InnerException, kterou bychom měli nastavit vždy, když rethrowujeme nějakou jinou výjimku
  • InnerException se typicky nastavuje v konstruktoru
    • např. catch (FileNotFoundException ex) { throw new ProfileNotFoundException(ex); }

• nejprve se hledá místo ošetření (1. fáze)
  • výjimky umožňují exception filtry pomocí klíčového slova when
  • exception filtry můžou obsahovat volání funkcí
  • tyhle funkce se volají během hledání místa ošetření (v 1. fázi)
  • kolem metody Main je try s always-true exception filtrem, který obsahuje výpis „unhandled exception“
    • ten se liší podle verze dotnetu a operačního systému (v dotnet frameworku se zobrazí dialogové okno – takže se může stát, že se finally vůbec nezavolá)
• šíření výjimky (2. fáze)

• zachytím obecnou výjimku, pomocí ifu zkontroluju typ výjimky a případně rethrowuju
• pomocí when

• vstup do catch bloku pausne šíření výjimky
• vstup do finally bloku pausne šíření výjimky
• CLR udržuje zásobník pausnutých výjimek
• při opuštění finally bloku se buď 1) odpausne výjimka pausnutá tímto blokem, nebo se 2) tato výjimka odstraní a místo ní se propaguje nová výjimka (pokud uvnitř finally bloku vznikla nová výjimka)
• při opuštění catch bloku se stane jedna z těchto věcí
  • zruší se výjimka pausnutá tímto blokem (pokud nevznikla nová výjimka)
  • odpausne se výjimka pausnutá tímto blokem (v případě rethrowování pomocí throw;)
  • odstraní se výjimka pausnutá tímto blokem a místo ní se propaguje nová výjimka (pokud je vyhozena nová výjimka)

• malloc/new → free/delete
• ownership
• problém nemazání (memory leaků) a dvojitého mazání

• unique_ptr
• shared_ptr (ref_count)

Rc<T> (ref_count)

• v managovaném prostředí, kde má runtime velkou kontrolu nad programem
• paměť se spravuje efektivněji

když má objekt víc než 85 000 B

• fyzický adresový prostor (PA) – jedna jednotka je rámec
• u virtuálního adresového prostoru (VA) – stránka

• rezervuju určitou část virtuálního adresového prostoru, abych měl zaručeno, že ji nebudou chtít použít ostatní části mého programu (procesu)
• tím způsobem můžu mít jistotu, že budu používat kontinuální rozsah adres (v téhle konkrétní části svého programu)
• nesouvisí to s přidělením fyzické paměti (dokonce jí ani nemusí být dostatek)

• commituju část rezervovaného adresového prostoru
• může selhat, když není dostatek fyzické paměti

decommit = free

• ve workstation módu je halda sdílená, takže když běží garbage collector, tak se všechna vlákna zapauzují
• v server módu garbage collector běží ve více vláknech
  • v některých situacích může garbage collection běžet na pozadí

Windowsy vysílají broadcast zprávu, když dochází paměť počítači, takže i v této situaci se spouští garbage collection

• kde jsou reference
  • ve statických proměnných
  • na zásobníku (lokální proměnné a tracking reference)
  • uvnitř (live) objektů
• každá reference odpovídá hraně v grafu
• garbage collector označí dosažitelné objekty jako live

• přeskupí se objekty na haldě
• opraví se reference (proto se nedá získat adresa referencí)

po heap compactingu se sníží

• výhoda tohohle přístupu je to, že je alokace rychlá
• akorát se ta paměť při alokaci musí nulovat
• GC se pouští, když paměť na haldě „dojde“

jsou fajn, protože žádný objekt nepřežije garbage collection, takže může proběhnout rychle a nemusí se dělat heap compacting

• gen 0 → gen 1 → gen 2
• když objekt vznikne, tak je v generaci 0
• garbage collection se dělá po generacích
• nejdřív se dělá collection gen 0, pokud je potřeba další paměť, tak gen 1 a případně nakonec gen 2
• pokud objekt přežije garbage collection, tak se přesune do další generace
• invariant: po každé collection je generace 0 prázdná
• long living objekt skončí v gen 2
  • pokud vede reference z long living objektu do short lived objektu, tak na něj dlouho nepřijdeme, že se může uvolnit

• když máme long living objekt, co ukazuje na short lived objekt
• když zapomenu na nějakou referenci
  • někdy je vhodné explicitně přiřadit null

• máme hodnotu Count a pole referencí na T
• přístup 1: Clear vynuluje Count v O(1) – špatná implementace, vede k memory leaku, zůstanou tam reference na objekty uvnitř listu
• přístup 2: v O(n) přiřadit všem objektům null

• ToUpper vytvoří nový string
• Substring vytvoří nový string
  • v Javě se použije původní string a ukazuje se na jeho část

• sb.Append("x").Append("y");
• protože Append vrací instanci StringBuilder

pozor na míchání přístupů – pokud uživatel zadá {0}, tak se to může rozbít

• používá se StringHandler
• InterpolatedStringHandler používá duck typing (najde se vhodný handler podle typu, do kterého výsledek interpolace přiřazujeme)