Poznáváme C# a Microsoft .NET – 1.díl

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

Postavil som si svoju prvú aplikácu - čítanie obsahu textového súboru, jeho zobrazenie a zápis. Pohodička!
Ale zarazila ma veľkosť výsledného .exe súboru. 24kB!
Ono by to nebolo až tak veľa, ale keď som si pozrel jeho obsah: veľké bloky zaplnené nulami, veľa textov, medzier ... Keď som ro zbalil pomocou programu RAR, dostal som súbor približne 4kB veľký! To je 1/6 pôvodnej veľkosti!!!
Trošku ma to mrzí, pretože inak je to dosť rýchle. Nedalo by sa s tým niečo spraviť, aby ten súbor bol menší?

jasne, aplikacia je skvelaaa, ale zabudol si dopocitat Framework ku tomu aby to ficalo :o)

Sice trosku pozde, ale tady si rejpnu. To uz k tomu muzes rovnou pricist i velikost windowsu, protoze bez nich to taky nepobezi.

Nevim, ktery debil vymyslel tenhle pojem. Anglicky to je Common Language Runtime, coz by se spis melo prelozit jako "Spolecny jazykovy beh", coz podle me mnohem lepe vystihuje podstatu veci.

docela potesujici vec je taky to, ze Microsoft vypustil zdarma vyvojove prostredi pro C# (C++, VB.NET, J#), ktere je zdarma a po prvnich zkusenostech s VC# 2005 to musim akorat pochvalit.
A taky mi tady ta diskuze misty trochu pripomona nekonecny spor me linux a windows komunitou. Zatvrzeli linuxaci tvrdi, ze linux je lepsi na vsechno a porad argumentujou nejakejma administratorskejma blabolama a ze je vsechno v linuxu rychlejsi, ze se nemusi klikat a podobne .. ale to tak pro jednoho cloveka z 1000, kterej doopravdy vi co dela. A je sice moc pekny si pamatovat ze toto a tamto nastaveni bylo tam v tom a tom souboru nekde v 10 podadresarich a k tomu vedet dalsich 100 prikazu, ale co z toho. A stejny je to se "starym dobrym" C++ a C#. Spousta lidi, co programuje v C++ dlouho si uz zvykla na to, jak to tam chodi, vi ze obejdou veci pomoci pocitani referenci ci toho nebo onoho a potom jsou tu ti ostatni, kterejm nevadi ze ta aplikace pojede o 0-10% procent pomaleji, ale naprogramujou to 10x tak rychle, kod bude srozumitelnejsi, bude ho moc pouzivat vice lidi atd atd ... a to vsechno diky nove filozofii .NET. A navic VC# 2005 uz snad programuje uplne samo, takze se staci soutredit pouze na strukturu programu. A nejhezci na tom je, ze to potom vsechno pojede i na Linuxu (dobre, zatim bez poradne podpory windows.forms) ;)

no neviem, podla mna je VS.NET uplne na prd. viem, vela ludi hovori, ze je to najlepsi IDE ci co a neviem preco, ale ja pouzivam VS.NET jedine kvoli intellisense. kompilujem cez nANT. nepouzivam ziadny form designer, kedze to co generuje VS.NET je proste na zaplakanie, radsej si to napisem sam a prehladnejsie... dalej co sa tyka podpory windows.forms... pochybujem, ze bude niekedy na mono fungovat tak ako ma... v mojej aplikacii mam zasadne oddelene GUI od programu, takze momentalne mam napisane GUI vo Windows.Forms, dalej mozem robit s aplikaciou cez konzolu. ak budem portovat na linux, tak pridam i GUI napisane v GTK#. ziadny problem... kazdopadne, uznavam VS.NET je skvely nastroj pre zaciatocnikov, neskor vsak mozu vadit iste veci, predovsetkym pokial chcete cisty, zrozumitelny a kompaktny kod... a toto je dolezite hlavne ak pracujete na vacsich projektoch s predpokladanou zivotnostou 5 viac rokov.

to si pockej na Whidbey (VS 2005), pak nebudes moci nic rict o cistote kodu...

Jo, s tema winforms a GTK# mas pravdu. taky to tak delam. Spis slo o to, ze to UI aplikcim proste (teoreticky) nemusis delat 2x.

No co se tyka nastaveni, tak jsem si rozjel Windows 2003 server, RRAS, VPN PPTP, L2TP, IPSec, DNS, AD, MS basic firewall... No muzu rict, ze treba nastavovani VPN je mnohem horsi, nez mit par textaku na linuxu. Kdyz chci IPSec, tek musim politiku local computer pro ipsec networking, dale politiku v rras pro overovani a accounting, dale zvlastni adapter v rras, dale dialin v domain users konsoli... (a chrante se nekde neco splest, spatne se pak preklep hleda, dale dokumentace se lisi pro win2000 a win2003 a ISA a ISA2000). No a to nemluvim o reseni problemu, tedy kdyz v jakychsi dvou podpodpodoknech (pravetlacitko/properties/ousko/tlacitko/pravetlacitko/properties/ousko...) zapnete tracing a full log... a spravne jste uhadli, ruzne veci prichozi zadosti do VPN se loguji ruzne, nektere do EventLogu, nektere do win/system32/LogFiles (30 ruznych souboru) a nektere do win/tracing. V tech logach nakonec neni sloupcova struktura, ale plno neusporadanych radku s ruznyma odkazama na 0x... a CLSID... Nakonec jeste restart RRAS - zajimava vecicka, jen se nekdy nedockate, zustane ve stavu "ani ano/ani ne" a sestrelit nejde, je to service - takze restart windows serveru.
To byl jeden z prikladu. Takovych mam z praxe vice. A co se tyka registru, tak zkuste se v nem vyznak, kdyz neco detailniho opravdu potrebujete, tech plno CLSID a i detaily typu opravneni na polozce a neznama provazanost... perfekt Microsoft, tady bych fakt 1000x radeji par textaku (ktere bych si odladene na testovacim prostredi ulozil na disketu a pak uz jen modifikoval podle situace). A to mam jeho desktopove a vyvojove produkty jinak rad.

Me by treba zajimaly vyhody C# a .NET oproti Jave. Ja vidim jen nevyhody.

A jake pak nevyhody, to pane, vidite?

Co treba multiplatformnost Javy? To snad neni obrovska vyhoda?

GoMono...

goMono? go to hell :o)

sorry, ale opravdu nevidím žádné nevýhody na straně C#, právě naopak...
 

Ja jedinu vyhodu .NET vidim v podpore pre svizne GUI, co sa o Jave povedat neda (Swiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiing). Ale zase Java ma multiplatformnost, plus hordy OSS projektov (Jakarta).

Zajimalo by me nejaka nevyhoda. V Jave delam dele nez v .NET, .NET ma mnohem navrhnuty framework a umoznuje bez vice jazyku. To Java nema !. GoMono ci Portable.NET bezi na vsech ruznych platformach a velmi solidne. Mozna vam vadi konexe s MS, ale tohle se jim povedlo.
 

Zaujimalo by ma, ci sa robil nejaky vacsi projekt v .NET na Linuxe (nie ze by som rypal do Windowsu).

Viz můj příspěvek výše. Děs a hrůza. Což není chyba .NETu, je to neschopnost Ximianu; to ovšem nic nemění na skutečnosti, že Mono je pro vážně míněnou práci pro bugovost nepoužitelné. Ostatní implementace neznám, takže tam nemohu posuzovat, třeba jsou na tom lépe.

V principu nic nestoji v ceste napsani prekladace jineho jazyka do Java bytecode, jen nikdo o to nestoji.
Alespon ja o nikom nevim. Java jako jazyk ma proste navrch a ve verzi 1.5 jeste vic.

Co Jython, JPerl, Jacl... ??

Tak o tech jsem vubec nevedel.
Diky za informaci.
OK. Takze jeden z argumentu pro .NET vs. Java tim prakticky pada. Vice jazyku je i pro JVM, nejen pro .NET runtime.

Kdyby Java podporovala syntaxi Basicu a měla jednodušší model GUI, bylo by to také o něčem jiném... Tím nemyslím vytváření nějakých hybridů nebo uvolňování syntaxe normální Javy, prostě klon JVM s dalším jazykem.
Problém zmíněných implementací je malý výkon, zatímco výkon C#, VB.NET nebo JScriptu je prakticky totožný.

Nakolik dobre znas jazyk C#, aby sis mohl roufnout k takto odvaznemu tvrzeni?

S C# jsem doposud nic nedelal, ale delal jsem hodne do Javy a muj byvaly kolega (taky Javista) ted dela C# a ve srovnani s Javou pouziva na opis C# sama sprosta slova. I kdyz porad lepsi C# nez C/C++.
Ale rad si pockam na dalsi dily serialu. Pak urcite prispeji do diskuse.

No jo, java, kam se na ni hrabe C#?! Ten ma preci jenom sve delegaty a dalsi pekelne veci, ktere jsou prece urazkou kazdeho programatora, ze?

Ve VS 2003 je FW 1.1, teď se chystá k vypuštění (?) 2.0 - jak to bude s použitelností aplikací vyrobených pod "starým" a spouštěnou pod "novým" FW ?
Nebo jak rovnou na VS překládat pod tu 2.0 ?

Dobrý den,
aplikace vytvořené pro .NET framework 1.1 by měli bez problémů bežet v prostředí .NET frameworku 2.0.

Super, těším se na další díl. Chce to přeci jen ty pojmy předvést v praxi.

* nekompatibilita jednotlivých programovacích jazyků a s tím související obtížná spolupráce mezi programy/knihovnami napsanými v odlišných jazycích (např. C++ a Visual Basic)

Spíš neschopnost microsoftu napsat překladač kompatibilní s C++ pro visual basic. Také hloupý psát jazykem "základ" velké projekty.

* vysoká chybovost aplikací (chyby v práci s pamětí, neplatné konverze datových typů)

Prostě kvalita lidí jde dolů a někdo má pocit, že to nahradí lepším systémem

* problémy s verzemi knihoven (obtížná práce s provozem více verzí knihoven)

Nepochopeno. V včem je problém, a proč se vlastně pracuje s více verzemi.

* zastaralý a nepřehledný způsob vývoje dosavadních webových aplikací

Ano, tady souhlasím, ovšem dokážu si webovou aplikaci představit i v C++, jenže na ní chybí knihovny, které zatím nikdo nenapsal.

* Garbage collector

Je opět jen nástroj líného programátora. A přitom samotné C++ má prostředky jak se obejít bez garbage collectoru (chytré pointery, počítané reference, koneckonců i garbage collector se dá v C++ napsat.)

Já to shrnu. Místo aby někdo vylepšil normu C++ o další vlastnosti, které nám chybí (a teď nemyslím další vylepšování templatů, které se naopak stávají nástrojem geniů), přidat takové vlastnosti jako třeba podpora threadu a threadových deklarací, properties, a konečně stačí se podívat na spoustu míst v MSDN označených "Microsoft Specific-->", takže místo toho se microsoft vrhá do nové platformy, ano, s myšlenkou "zahoďte staré zdrojáky a pište po našem". Svět podle Microsoftu.

Pointery su strasiakom Ale mam dojem, ze vacsina najpouzivanejsich jazykov v sucasnosti uz pointery zavrhla (.NET, Java, Perl, PHP) a ludstvo zlenivelo, len neviem, ci je to pricina, alebo dosledok.

Pointery nejsou strasak. Kdo to umi pouzivat,je v pohode a kdo ne,ten ma problem. Problemy muzou mit nekteri takyprogramatozi i s charem - napr. dotazy typu jaktoze 127+1=-128??

"Je opět jen nástroj líného programátora. "
Línej programátor je pro tebe asi blbej programátor jo? Asi si v životě nic pořádnýho neudělal, když tohle říkáš. .NET je jedna z mála věcí od MS, co se mi líbí. A ty tvoje plky si vykládej někomu na střední škole. Jseš uplně mimo.

Ano, programuju v C++ již od svých 16 let a nyní mi táhne na 29.

Ahoj Ondreji,
obdivuji tvoji snahu drzet se "zuby-nechty" na potapejici lodi, jakou C++ bezesporu je(rozhodne co
se vyvoje informacnich systemu tyce). :) Ale co se da delat, vsichni vime, ze vzdy se najdou
nejaci "zpatecnici" branici se prizonemu vyvoji( btw. "Prece se toci":D). .Net je vyborna platforma
a ty se evidentne nechces smirit s tim, ze ten shit ve kterym uz 29-16 = -458 :D let programujes
je zavrzen a ty uz neumis nic jineho, vid ? :) A co vic, ty se evidentne nechces uz nic jineho ucit. ;)
PS: Proc treba nepise v assembleru ? (ten bude mit za chvili podporui srovnatelnou s C++)

Nemyslím si, že by se C++ potápěl (v čem si myslíš, že bude naprogramované samotné .NET, v čem si myslíš, že je celý COM+ a notabené celé windows).

Taky nechápu, jak si k číslu -458 přišel.

Pro tvou informaci, pracuji v C++, ale zvládnu Javu, Visual Basic (tedy pravda, ne .NET), PHP, a samozřejmě dokážu programovat i v assembleru. (A kamaráde, divil by ses, jak se píše v assembleru!).

Myslím, že .NET se dá leccos naprogramovat. Ale operační systém, ani ovladač zařízení v něm nenaprogramuješ - C++ ale ano, což staví tento jazyk jaksy na obecnější úroveň, než je cokoliv končící na .NET

>v čem si myslíš, že bude naprogramované samotné .NET
velke mnozstvi samotneho .NET Frameworku je napsano v C#, tot slova Andrew Hejlsberga, otce jayzka

Neda mi to to neni lenost progrmatora to je potreba napsat co nejvice aplikaci za co nejkratsi cas ... zvysuje se poptavka a tak se pise co nejrychleji :) firme se vyplati vrazit 100k do zeleza navic nez platit 1-3 mesice vyvoje... proste tak to je. Stejne tak se vyplati naspat aplikaci co se ppuzije vicekrat nez jednou, pokud ste tak zkuseny vyvojar jak tvrdite urcite zakonitosti cen vyvoje softwaru znate:).
A co se pise dnes v asm??? myslim ze pro lidi jako ja co delaji info systemy je tohle zajimave, pokud nekdo pracuje v asm i to je potreba pak se mozna bude divat na .NET zvrchu ale podle me zcela nepravem.

Cay
Ja programuju od cca 13ti let .. od Atari Basicu, pres Turbo Pascal, C a C++ az k ruznym dalsim proceduralnim jazykum (je to uplne jedno... zaklad je stejnej, pac uz se clovek uci vychytavky) jako PHP, Visual Basic, PowerScript atd atd... Me se .NET libi svou filosofii a nektere veci se v nem opravdu udelaji rychle... Napriklad takovy Webovy servis (jednoduse) se v nem da udelat za chvilinku... neni potreba psat nejake slozite mezixichty (interfacey :) atd, ale je fakt to jsou vse nastroje... jako zaklad pro programovani, by mel kazdy programator neco v Ccku a poneti o pointerech mit...

Preco potom vsetci tiahnu na .NET a Javu? Ked C++ je (hadam) rychlejsie? Su vsetci pohodlni? Je to vec marketingovej strategie? Stane sa Jan Tleskac CEOm Suncrosoftu?

Kde jste získal informaci o tom, že všichni táhnou na C# a Javu? To je zcestné. O obojím je hodně slyšet díky práci marketingových oddělení Microsoftu a Sunu, ale firmy se chovají konzervativně, oproti očekávání stále zůstávají u C++. Tam kde dochází k přechodu na C# jsou stejně nejlépe placení Ti, kteří ovládají C++.NET a zajistí zpětnou kompatibilitu. C++ programátor je, byl a bude C++ programátor - nově bude muset mít znalost i o .NET a C#, resp. VB.NET, ale znalost jen C# je ve většině firem zatím dobrá pouze pro pěšáky.
 

* vysoká chybovost aplikací (chyby v práci s pamětí, neplatné konverze datových typů)
Ještě si neodmyslím jednu připomínku, co se nám může vymstít - podívej me se na poslední viry, kterak zneužívají chyby monolitického systému. Co kdyby náhodou někdo našel v tom .NET nějaký backdoor. Kdyby vše bylo v .NET, tak se takový útok rovná apokalipse počítačů.

To skor vyplyva z uzavretosti .NETu, z ,,reakcieschopnosti" jeho tvorcu a z rozsirenia tejto technologie.

zeptam se jinak, je snad WinAPI nastrojem lineho programatora, je snad C++ nastrojem lineho porgramatora, kteremu se nechce psat v assembleru (teda jazyce symbolickych adres), je snad assembler nastrojem lineho programatora, ktere mu se nechce psat ve strojevem kodu (to jeste taky umim, hec!)?

ano muzeme psat programy v assembleru s primim pristupem k jadru OS, nebo rovnou k hardwaru, toto reseni prinasi sice uzasny vykon, mozna az o 10% nez v C++, ale programator se musi starat o 1000 veci a na programovani samotneho programu mu zbyva pomerne mala doba. a prave tady toto se C++, ale i .NET, Java snazi eliminovat.

dalsi rozsirovani C++ nevidim jako dobrou volbu, uz tak je to preplacany jazyk, osobne jsem jeho pouzivani preskocil a pouzivam bud Ansi C nebo rovnou Javu, ci C#. uz ted jsou problemy udelat standardni C++ prekladac a obcas i prenositelnou aplikaci, protoze kazdy prekladac si resi veci posvem (viz ono MS specific)

>zeptam se jinak, je snad ..... nastrojem lineho porgramatora
tohle je demagogie. Je snad knihovna nástrojem líného programátora? No není. Ale my mluvíme o systému.

>ale programator se musi starat o 1000 veci
houby. Samozřejmě že nemusí! S dobrou knihovní základnou se programuje velmi dobře a nemusíš se o nic starat. Naopak možnost kdykoliv opustit knihovny a programovat "low-level" je někdy užitečná, zvlášť tam, kde musíš vyhnat výkon.

A nebo mi vypiš nějaké věci o které se musíš starat?

>dalsi rozsirovani C++ nevidim jako dobrou volbu, uz tak je to preplacany jazyk, osobne jsem jeho pouzivani preskocil a pouzivam bud Ansi C

Tohle nepotřebuje komentář. Ukazuje to na to, odkud pramení tvé názory.

1) C++ aplikace se pomerne jednodusse da prepsat do Managed C++ - viz. Diablo II ci podobna hra byla behem mesice kompletne prevedena coz je k mnozstvi zdrojaku hodne dobry vysledek. Jiste napsane aplikace by meli jit teoreticky prelozit v obou jazycich.
2) Managed C++ muze take obejit GC, ale v VS2003 je to dost neprehledne. Lepsi to bude v VS2005 - bude tam managed pointer(   "^"    ) a klasicky pointer(  "*" ) odlisen, v VS2003 se musi psat slozite "__gc". Jinak si nemyslim, ze napsat kvalitni GC je zalezitost jednoducha, spise dosti komplikovana - pocitani referenci je jen nejneefiktivnejsi zpusob, o tom svetsi i fakt, ze jako jednina vec se vetsinou nezverejnuje a kazdy si ji chrani oc to jde. (viz Microsoft - .NET kody stazitelne, ale GC v tom nenajdete)
3) Vsechno je zalozeno na C/C++, to ze se to jmenuje C# je toho samo dokladem. Jinak neni pravda, ze bz C# byl "Microsoft Specific ... " - je to schavaleny standart, stejne jako cely .NET Framework

2) Ad GC, netvrdil jsem, že počítání referencí je efektivní náhrada GC. Samozřejmě není. Ovšem denní praxe mi většinou ukazuje, že toto většinou stačí. Používáme různé strategie úklidu, počítání referencí je jen jedna z nich. Další je například cacheování předalokovaných bloků pro části kódu, kde se něco alokuje takřka na každém řádku. Chci jen říct, že všechny tyhle "featury" lze mít ve standardním C++ bez ztráty výkonu. Možná jen někdy s malým opruzem, při vymýšlení syntaxtických konstrukcí.
Managed jsem chápal jen jako možnost pouštět přeložený kód na strojích, které nejsou postavené na platformě Intel procesorů. Tady bych viděl jedinou zásadní výhodu managed kódu. Na druhou stranu, je tady vidět i snaha microsoftu skrýt zdrojáky. Současná praxe zejména na Linuxu distribuovat zdrojáky, které se na cílové platformě přeloží, Microsoftu nesedí (ani se nedivím). Ze zdrojáků lze mnohem snadněji ukrást různé technologie, a to se prostě z managed kódu tak snadno nedá.
Stejně tak pojatá Java v době vzniku však měla výrazné PRO a to byly aplety, platformově nezávislé aplikace pro webové stránky. Stejně na tom je Java u mobilních zařízení (ačkoliv i tady jsou velké platformové rozdíly).
Pokud mě nekdo přesvedčí, že Managed aplikace se pomocí JIT technologie dokáží přeložit na cílovou platformu stejně optimálně, jako native, pak nic proti nim nemám. Ale tato technologie měla jít jinou cestou, měla vzít to co už je k dispozici a pracovat s tím (c++), ne vymýšlet něco nového (C#)

"Chci jen říct, že všechny tyhle "featury" lze mít ve standardním C++ bez ztráty výkonu"
Co znamena "Bez ztraty vykonu, nejakou dobu to prece trva, ne? Zatimco alokace na Managed heapu trva stejne dlouho jako vyhrazeni mista na zasobniku - a ten princip je pomerne jednoduchy.

"Ze zdrojáků lze mnohem snadněji ukrást různé technologie, a to se prostě z managed kódu tak snadno nedá"
Kdyby tohle byla pravda, povazoval bych to za plus pro .NET, ale existuji utility, ktere z CIL kodu vyrobi neco, co je mozna prehlednejsi, nez standardni C++ zdrojak...

"Pokud mě nekdo přesvedčí, že Managed aplikace se pomocí JIT technologie dokáží přeložit na cílovou platformu stejně optimálně, jako native, pak nic proti nim nemám"
- Stejne optimalne ne, spis to bude jeste lepsi, princip je totiz v tom, ze JIT zna presne vlasstnosti pocitace, na kterem bez, coz je neuveritelna vyhoda proti sebechytrejsim kompilatorum, ktere nemohou absolutne nic predpokladat o prostredi, kde se ocitnou, zvlaste citelne je to u pouziti ruznych pokrocilych procesorovych instrukci, ktere u nativnich aplikaci vetsinou zustanou nevyuzity, protoze nikdo nevedel, jestli je muze vyuzit.

"Ale tato technologie měla jít jinou cestou, měla vzít to co už je k dispozici a pracovat s tím (c++), ne vymýšlet něco nového (C#)"
Nedovedu si predstavit, jak by to v praxi vypadalo. Microsoft proste vyvynul novou platformu a potreboval pro ni nejaky novy jazyk, ktery by byl schopen vyuzit jejich moznosti a kobnec koncu samotna syntaxe C# obsahuje nektere nove prvky, ktere si nedovedu dost dobre prestavit, jak by se napasovaly na C++, navic k tomu nevidim sebemensi duvod (krome zbytecneho konzervatismu, ale ten je dobre prekonavat)

Dovoluji si oponovat:
>Zatimco alokace na Managed heapu trva stejne dlouho jako vyhrazeni mista na zasobniku -
> a ten princip je pomerne jednoduchy.

Pokud je alokace na managed heapu rychlejší než cečkovský malloc, proč se tato technologie v C nepoužívá? Nebude to spíš něco jiného?

>Stejne optimalne ne, spis to bude jeste lepsi, princip je totiz v tom,
>ze JIT zna presne vlasstnosti pocitace, na kterem bez,
>coz je neuveritelna vyhoda proti sebechytrejsim kompilatorum

Tady taky nevím, dle mého názoru, nejchytřejší je překladač z C++ do instrukcí platformy optimalizovaného přímo na tuto platformu. Zdrojáky se překládají až na cílové platformě, ne? (mluvíme-li o linuxu). Tady není problém v technologii, ale v lidech a někdy v nechuti psát překladače optimalizované na počítače mající "pár instrukcí" navíc oproti pentium.

>syntaxe C# obsahuje nektere nove prvky, ktere si
>nedovedu dost dobre prestavit, jak by se napasovaly na C++,

Tak jednak syntaxe je jen formát zápisu něčeho, asi jsi tohle zrovna nemyslel. Které prvky přesně máš na mysli?

"Pokud je alokace na managed heapu rychlejší než cečkovský malloc, proč se tato technologie v C nepoužívá? Nebude to spíš něco jiného?"

V C se nepouziva, protoze to neni mozne, alokace na managed heapu je tak rychla diky pouzivani Garbage Collectoru (princip je v tom, ze pri "zberu odpadku" se halda vzdycky "sesype", aby byla kompaktni, diky tomu neni treba hledat misto, kde se ma novy objekt naalokovat, proste se pouzije ukazatel na vrchol haldy, ktery se pak posune o naalokovany kus.

"Tady není problém v technologii, ale v lidech "

Tvuj problem obecne je, ze nechapes proc lidi pocitace a pocitacove programy pouzivaji, takze ti to ted prozradim: Pouzivaji je, aby si usetrili praci. Takze pokud reknes, ze nejaka technologie je urcena jen pro line lidi, tak ji ve skutecnosti delas reklamu.

"ak jednak syntaxe je jen formát zápisu něčeho, asi jsi tohle zrovna nemyslel. Které prvky přesně máš na mysli?"

Problem C++ je, ze to je zastaraly jazyk, se zastaralou syntaxi, ktera NEJDE donekonecna rozsirovat. Jestli chces konkretni priklady, tak tady jsou:

operator[]: Pouziva se pro indexovani ve tride, ktera se chce tvarit jako pole. Neumoznuje programatorovi, ktery pise obsluznou metodu, rozlisit, jestli se vola pri zapisu nebo cteni.
Konkretni priklad dusledku (primo z STL(!)): pokud do vectoru (coz je "nafukovaci" pole zapisujes, za doposud vyhrazenou cast, vyhodi se vyjimka, prestoze logicky by melo byt mozne toto provest. Tenhle priklad se da jeste oznacit za umysl, prestoze je to spis z nouze ctnost, protoze kdyby autori knihovny meli v umyslu pole automaticky nafouknout, v C++ to neni mozne(teda vlastne je, ale to by zase byl problem, pokud chce uzivatel z pole cist). Dalsi priklad je ale jednoznacny: Pokud z mapy ctes podle klice, ktery tam neni, vubec se to nedozvis, navic tam od te chvile ten klic uz je.
C# ma indexery, coz je vec, ktera se chova stejne jako operator[], ale ma Getter a Setter.

events: Velmi mocny nastroj, nejen pro psani uzivatelskych rozhrani. Vec, kterou C++ vubec nema. (A je to syntakticky prvek; sytaxe neni "jen" format zapisu).

Prikladu by se naslo vic, ale nechce se mi je psat, tohle konec koncu docela staci.

C# neni jazyk, ktery by nejaka parta noumu zflikovala za odpoledne. Je to moderni jazyk, ktery vyuziva vsechny osvedcene prvky, na ktere kdo kdy prisel (pomerne dost "vykrada" Javu, i kdyz nektere veci jsou pro nej specificke (a mimochodem Java zase spoustu myslenek vykradla ze Smalltalku))

Takže to bude něco jiného. Dokážu si teda představit jak se mi hromada o velikosti 500MB sesypává. Myslíš že to je rychlejší?

operator[], to vis ze to lze
type &operator[] //zapis
const type &operator[] const //cteni
pokud chces nejak handlerovat zapis, tak misto type si das pomocnou tridu s pretizenym operatorem=.

Konkretni priklad dusledku (primo z STL(!)):
STL je na houby. (chtel jsem rict sprostsi slovo).

events: MFC na to má message mapy, a taky to funguje na dve kliknuti a mas udalost.

"Dokážu si teda představit jak se mi hromada o velikosti 500MB sesypává. Myslíš že to je rychlejší?"

Odpovim ve dvou krocich - elementarni uvahou snadno zjistime, ze pokud jednou za cas znicis vsechny nepotrebne objekty, na celkovem case behu programu se to nemuze projevit hur, nez kdyz jednotlive objekty likviduju prubezne
2. krok - dve otazky naraz - nevadi mi, ze se to deje jednou za cas narazove, na druhou stranu Neni to nahodou celkove dokonce rychlejsi?
Garbage collection, kdyz se spusti, bezi ve vlastnim vlakne. Na mem pocitaci (ktery je, pravda v dnesni dobe mozna stale mirne nadprumerny) jsem zvikly si dobu pri vypalovani CD kratit poslouchanim hudby a surfovanim po Internetu, z cehoz usuzuji, ze vec, jako je jedno vlakno navic, nemuze predstavovat vazny vykonnostni problem.
Takze - Nevadi a Je.

"operator[], to vis ze to lze"
#include
#include

using namespace std;
class Demo{
private:
int pole[1000];
public:
Demo(){};
~Demo(){};
int &operator[](int index){

cout << "Demo :: Nekonstantni hranatice" << endl ;
return pole[index];
}

int operator[](int index) const {
cout << "Demo :: Konstantni hranatice" << endl ;
return pole[index];
}
};

int main(void){
Demo A;
int b;
A[5]=10;
b=A[5];
getch();
}

Vypise:
Demo :: Nekonstantni hranatice
Demo :: Nekonstantni hranatice

Muzes si to vyzkouset. A tohle je standartni chovani, existuji prekladace, ktere se chovaji, jak pises, ale neni to podle normy.

"STL je na houby"

No, to je vec nazoru, kazdopadne pokud zacnes pouzivat napriklad zminovane MFC, portabilita kamkoli mimo Windows prijde docela zkratka.

Dobre, rekneme, ze MFC neco na zpusob events ma, prestoze pochybuju o tom, ze se pouzivaji tak dobre, a poskytuji tolik moznosti, jako ty v C#.
Je zde ale spousta dalsich veci: Serializace, Remoting, Reflecnion a cely koncept metadat, uroven, na ktere je mozne sdilet cizi kod... . No a na druhe strane veci typu Unsafe mod v C#, COM-Interop, nebo P-Invoke, diky kterym muzu, pokud o to doopravdy stojim a myslim si, ze se bez toho neobejdu, pouzivat cokoliv, co .NET FW sam neumoznuje.

Je mne asi o nejakej ten rok fic jako vam/tobe  a zacinal sem na nejakem tom ATARI a BASICU  dokonce sem dle meho nazoru byl na svuj vek dost daleko ale po nejake dobe kdyz prisly ty PCcka sem se k tem complum par (10)let nedostal a ted po par letech co sem se k tomu vratil sem zjistil ze sem prisel ze stredoveku fsecko je jinak.
Takze sem stahl par veci k C++ Ninstaloval C++ Builder6 a zacal hledat info ke a jak zacit ale jak rikam v 33 letech  vlastne zacinat od znovu takze tridy a podobne   no proste sem z toho jelen.
Takze otazka zni takto v jakem prostredi mam zacit a pozdeji snad i pokracovat pokud se v tomto veku prokousu pres zacatky?
Pokud by ste mne nejak rozumne poradil budu vdecny za kazdou radu,

Pokud by nejaka ta rada prisla treba na ICQ 199557068 nebo na mejlik DDimik@seznam.cz 

Vazeny pane,
k nekompatibilite - az dokoncite alespon jeden projekt, a budete jej muset po ukonceni predelavat, poznate cenu kompatibility
verze knihoven - az dokoncite alespon jeden projekt, a budete jej muset po ukonceni predelavat, poznate jak moc jste myslel omezene, kdyz jste psal knihovny
Garbage collector - jestli si myslite, ze pocitane pointery = Carbage collector .. tak se ani radeji nebudu vyjadrovat k tomu co si myslim, o kvalite vaseho programovani ..
snad omluvite, ze nemam ak velkou hubu, abych tvrdil, ze kdyz neznate principy Carbage collectoru, jste min kvalitni clovek.
Takze to shrnu .. lepsi jakakoli koncepce a vize od kohokoli, nez urazky ..

Dovolím si trochu oponovat vyjádření, že uživatel u spousty úloh nepocítí snížení rychlosti. Uživatel totiž (pokud není program špatně napsán) nepocítí snížení rychlosti vůbec ! Jde o to že, podle mé zkušenosti, je program v .Net cca o 10% pomalejší než nativní C/C++ a to je v podstatě zanedbatelné. Tento mýtus, že interpretovaný jazyk musí být pomalý přetrvává ze z dob starších verzí Javy, které fungují obdobně a opravdu pomalejší jsou (verze 1.5 už by měla zaznamenat výrazný rychlostní posun).
To že se C# nepoužívá pro vývoj výpočetně náročnějších aplikací je způsobeno tím, že je to relativně nový jazyk a firmy, které tyto aplikace vyrábějí mají jistou nezanedbatelnou setrvačnost a nejsou tedy schopny ze dne na den přejít na jiný programovací jazyk (bohužel ani z roku na rok :)
PS: jazykem C# se zabývám už přes tři roky a už předem se omlouvám, že do těchto článků budu trochu rejpat :) Jinak jsem rád, že na živě něco takového vychází a držím palce, aby to za něco stálo

10% je moc. V našich aplikacích často minimalizujeme virtuální funkce, aby se využil maximální výkon procesoru. A to se říká, že zdržují méně než 1%

Není on náhodou Garbage Colector náročný hlavně na paměť?

Ono hodně záleží na tom co se porovnává. V některých věcech (např hashtable) je C# výrazně rychlejší, v jiných (např výjímky) je o dost pomalejší
těch 10% jsem myslel výpočet hrubou silou (tedy nějaký krátký prográmek miliónkrát volaný v cyklu) - důležité je, že rychlost pro něj není handicapem oproti C++ (mimochodem, kdyby byla, tak by to i tak byl handicap jediný :)
ale některé věci se liší hodně framework od frameworku (kvalita výrazně stoupá a 2.0 byť jen beta je o dost rychlejší třeba i jen v práci s poli)

No čučím do čeho se to zive.cz pouští a doufám, že to bude naučné, narozdíl od pana petříka :o)

Zatím dobré, hlavně ty webové služby nešlo popsat lépe. S tím mám pokaždé potíže, když to popisuj někomu, kdo to nezná a Vaše definice je velice výstižná.
Ještě bych dodal, že je tato platforma portovaná na Linux:
www.mono-project.com 
a musím uznat, že je to zatím udělané dobře, jen tam není Windows.Forms(tedy je, ale není jako stable), ale bude na koci roku. Formulář udělán přes GTK# je velice svižný.
Takže tento článek je možné doporučit u Linuxákům.
 

pokud chcete windows.forms zkuste http://www.southern-storm.com.au/portable_net.html dalsi slusna implementace .NET

Hmm, ač mi nad Monem jede už přes rok můj vlastní pidiweb, ač jsem jeden čas posílal bugreporty a většinou současně i patche tak intenzivně, až jsem se objevil v seznamu přispívajících vývojářů, ačkoli jsem v té době já blbec přesvědčoval ostatní jak bude Mono úžasné, po vydání verze 1.0.0 jsem hoooodně znejistěl a v současné době jsem již nad ním (a díky tomu i nad .NETem, protože potřebuju jet multiplaformně, tj. i pod Linuxem; i když jinak se mi .NET stále líbí) zlomil hůl. Předpokládál jsem, že verze 1.0 bude konečně odladěná a funkční, bohužel vývojáři Mona jedou  stylem "jednu chybu opravím, dvě další nasázím". Roadmap v podstatě dodržují pouze číslováním verzí, ale ne stavem kódu. A jestliže - jeden příklad za všechny - po upgradu z verze 1.0.1 na 1.0.2 musím upravovat všechny šablony ASP.NET stránek tak, abych v prvcích z System.Web.UI.Html neměl přímo zadané číselné hodnoty (třeba [textarea runat="server" cols="20" /] nahradit [textarea runat="server" cols="[%= promenna %]" /] - hranate zavorky si nahradte spicatymi) protože po načtení prvního virtuálního webu mod-mono-serverem spuštěným s českými locales už v dalších při kompilaci šablon nefunguje konverze ze stringu na int, považuju to za dost zásadní problém. Neustálé přiohýbání kódu tak, aby fungovalo v Monu určité verze - čímž pro změnu přestane fungovat ve verzi původní - a hledání úkroků stranou aby to všechno zároveň šlapalo i pod MS Frameworkem je dost otravné. Na bugreporty už kašlu, podle mého soudu to nemá cenu.

Nedokážu si představit, že bych na něčem podobném postavil řešení pro zákazníka, stávající Mono považuji za ranou betu nehodící se pro ostré nasazení.

mozna by stalo za uvahu i par radek o autorovi serialu, abychom vedeli, s kym mame tu cest a na jake odborne urovni autor je, dekuji

Take bych rad vedel, zda-li autor ma nejake vetsi zkusenosti s vyvojem aplikaci.

Zdravím, vývojem aplikací se pro .NET zabývám přes 2 roky. Zpočátku jsem si při studiu přivydělával tvrobou webových aplikací v ASP.NET (C#). Teď již několik měsiců pracuji ve významné softwarové firmě v ČR, která zabývá tvorbou zakázkových informačních systémů pro platformy .NET a J2EE.
Přeji pěkný den.

Vydejte pak souhrn v PDF!