C# alebo C++
Zdravim ake su rozdiely okrem syntaxe v tychto dvoch jazykoch?
O Linuxe
Portál
Odporúčame
Podporte nás
Ak sa vám táto stránka páči, môžete nás podporiť tak, že si na vaše stránky umiestnite tento banner.
Náš Twitter tag je #LinuxOSsk
Finančne nás môžte podporiť cez PayPal:
Má ozajstnú správu pamäte, pri dobrom návrhu môžeš zabudnúť na ukazatele, kde vzniká najviac memory leaks, segfault atď. Má proste výhody Java a pri tom je rýclejšie ako C++, kód sa skráti o tretinu až polovicu, rýchlosťou za sebou nechá všetko čo poznáš! Keby som začínal, nič lepšie neexistuje.
Má ozajstnú správu pamäte, pri dobrom návrhu môžeš zabudnúť na ukazatele, kde vzniká najviac memory leaks, segfault atď. Má proste výhody Java a pri tom je rýchlejšie ako C++, kód sa skráti o tretinu až polovicu, rýchlosťou za sebou nechá všetko čo poznáš!Uf, tak toto je naozaj sila! Zrovnavas dve takmer nezrovnatelne veci. Trochu sa rozpisem, zakladatel thread-u si moze z toho urobit nejaku predstavu o C++ a C#.V C++/C (C++ v minulosti zacalo ako syntax sugar jazyka C) su pisane operacne systemy, najroznejsie drivre, prekladace (napr. GCC), embedded veci. Spravu pamati si napises/pouzijes aku potrebujes a ver mi ze velmi vela krat ti staci stack v embedded systemoch atd..
Java je zas na to co by sa dalo nazvat uzivatelske aplikacie atd.. Samotna java sa preklada na specialny jazyk ktorym sa krmi velmi specialny pocitac (JVM), ktory sam je v beznych PC napisany v C/C++! Tento pocitac funguje (z mojho pohladu) podstatne odlisne od normalneho ARM alebo x86 CPU. Akosi tu zanika pojem pamate ako ju bezne a intuitivne chapeme. Nejaka pamat sa tu "neriesi", ale riesi ju sam JVM pocitac. To moze byt extremne zlozite na HW implementaciu a prave preto skoro vzdy virtualny napisany v C/C++. Toto je vyhoda prave u tych uzivatelskych aplikacii, kde si mozes ziadat o pamat ako sa ti zachce a nic ine neriesis. V nejakych drivroch zasa ziadnu pamat nepotrebujes, alebo vies presne co a ako s nou spravit a trebars potrebujes nejake veci spravit na co najmensi pocet instrukcnych cyklov.
C# je, ako bolo povedane, smejdarina. Je to parodia na Javu, ktora je maximalne nemultiplatformova, takmer windows-only, microsoft zalezitost. S C/C++ nema nic spolocne, s Javou ma spolocny princip.
A btw. Ultimate++ nie je jazyk! Je to framework, kniznica pre jazyk C++.
U++ je naozaj framework C++, ale používa vlastné knižnice, vďaka čomu sa zvyšuje rýchlosť a vďaka skutočnej správy pamäte a GUI nástrojom, rýchlosť tvorby.
C++ ma ozajstnu spravu pamate - ma new a delete.
Dokonca je mozne pouzit aj garbage collector, napriklad Boehmov konzervativny garbage collector.
newadeletesú operátory, ktoré v prípade ak nie sú pre danú triedu definované, kompilátor nahradí defaultnými, v ktorých volá funkcie KNIŽNÍC operačného systému. Tie knižnice nemusia v systéme existovať a v mnohých emebedded systémoch ani neexistujú tj. linkovanie sa nepodarí.Samotný operátor new može robiť prakticky čokolvek, rovnako ako všetky ostatné operátory v C++, vyžaduje sa od neho len vrátenie pointeru na oblasť nad ktorou sa zavolá konštruktor. Vobec nemusí ísť len o
malloc, alokácia može byť kompletne vlastná, trebárs v súbore, alebo v nejakom statickom poli. A prečo by to niekto robil? No napr. pre zarovnanie. Alebo si mallocom (alebo akokoľvek inak) vytvorené kúsky može aplikácia registrovať do nejakého systému... toto používa QT v hierarchii vlastníctva a pravdepodobne aj Ultimate++ v garbage collection systéme.Chápe ma niekto, čo chcem povedať? C++ defaultne nemá žiadnu správu pamäti, len akúsi velmi jednoduchú konvenciu, že sa bude volať akási funkcia s presným názvom.. ktorá na linuxoch defaulne skončí nalinkovaná na malloc. Konvencia volania funkcie ktorá nemusí existovať, nie je správa pamäti podla mňa.
Malloc a new nie su len konvencie, kedze su aj s ich chovanim definovane v standarde.
Ak sa teda na platforme nepodari nalinkovat new alebo std::malloc, tak kompilator pre tu platformu nedodrzuje standard a teda sa nejedna o C++.
Jasne, operatory mozu byt overloadnute, ale o tom sa snad nebavime - aj standard to spomina len tak mimochodom a inak pise o ich neoverloadnutej forme, ktora ma alokovat objekt tak, nech je ho mozne pouzivat aj mimo scope, kde je pouzite new.
Ak niekto moze pouzit iny alokator, tak je to jeho volba - to nijak neberie zo schopnosti jazyka. Rovnako zo schopnosti jazyka neberie ani moznost ukladania pointrov niekam (do lubovolnej hierarchie). A rovnako ani to, ako malloc bezne funguje na nizsej urovni a ze vysledkom je takmer zarucene nezarovnany kus pamati (v mojom systeme si malloc mozem implementovat ako chcem - kludne aj nech garantuje pamat zarovnanu na cache-line).
C++ sice nedefinuje, ako sa ma sprava pamati robit, ale ju de-facto vyzaduje tym, ze pozaduje nejake fungovanie od nejakych funkcii a operatorov. Preto ma spravu pamati.
A o tom ci su standardne kniznice sucastou jazyka podla standardu by sa dalo polemizovat. Vid.: C - prva otazka a odpoved a C by malo byt podla standardu v istom zmysle podmnozina, ale C++... takze minimalne keby poviem, ze standardne "C++ core language features" nepotrebuju kniznice, tak mam pravdu. S cisto povedanym C++ teda asi nie, OK...
V kazdom pripade, asi som uz veeelmi off-topic od zaciatku threadu.
C++ v zaklade kniznice mozno nepotrebuje, ale potrebuje chovanie new, malloc a par dalsich drobnosti.
C++ ma prostriedky na spravu pamate, c++ nema automaticku spravu pamate, o uvolnovanie pamate sa musi starat programator volanim delete. Nebude podstata vasho sporu v tom co z uvedeneho bolo myslene terminom "ozajstná správa pamäte"?
Pri overloadingu mi je celkovo uplne jedno, ze je moznost overloadnut unarny operator * a pouzit ho napriklad ako operator na vypis danej hodnoty - pre mna je dolezite, ze mozem napisat kod, ktory bude bez overloadingu fungovat - napriklad *(uint8_t *)0x7090 = 0x1F zapise presne urcene cislo na presne urcene miesto vo virtualnej pamati alebo ze mi new poskytne oblast pamati.
Mimochodom, pri overloadovani je mozne spravit si v C++ aj (transparentny) garbage collector, ale to nie je to, o com som sa chcel bavit - mimo ine aj preto, lebo to nie je sucast C++ podla standardu.
Bez spravy pamate je to tazke - napriklad pri vlastnom OS si musi clovek spravovat pamat sam, pricom niekedy dostane len prvu adresu (velkost si zisti sam). Potom si treba spravit alokator - malloc ako v userspace, tak aj nejaku podporu v kerneli (pricom je dobre nevolat kernel pri kazdom userspace mallocu). To zahrna mapovanie virtualnej pamate a zabezpecenie prekladu na fyzicke adresy; samozrejme treba mat napamati, ze kod moze bezat na viac CPU zaroven, procesy by nemali mat moznost sa ovplyvnit mimo urcene syscally atd.
Napisal si "Jasne, operatory mozu byt overloadnute, ale o tom sa snad nebavime".. ale ja som sa snazil prave presne o tom bavit.. teda presne o tom strednom odstavci tvojho postu a o tom, ze je to mozne v standartnom C++ ten garbage c. napisat, bez pouzitia nestandardnych veci.
A tiez som pojmom pamat myslel nieco vseobecnejsie, nie "klasicku RAM".
posledny post, koncim, dovi, lebo uz viac offtopic to uz asi nemoze byt :D
Ak overloadnes new, tak zrovna spravu pamati (od C++) nepouzivas - ale to neznamena, ze v C++ nie je.
Vyzerá to skôr ako Java, ako C ++, to nie je vybudovaný do strojového jazyka, ale namiesto toho sa do NET byte kódu, sa jej podarilo odpadky zhromažďujú manipuláciu pamäti, je orientovaná objektu. Tvorba katastrofálne chyby je oveľa ťažšie, pretože C # je zvyčajne schopný vyčistiť za seba. Odporučil som C ++ pomáha získať najlepšiu prácu potom C # môžete dozvedieť rozhovor otázku a odpovede.otázku a odpovede.