Na C# sa vykašli má určité výhody oproti C++ napríklad čo sa týka správy pamäte, ale je to šmejďárna. Pokiaľ ti ide o dobrú správu pamäte odporúčam skúsiť Ultimate++ nemám na programovanie už vôbec čas, ale pokiaľ si chceš skúsiť naozaj produktívny nástroj a ušetriť si písanie stoviek riadkov zbytočného kódu, vrelo odporúčam.
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++.
C++ nemá ozajstnú správu pamäte, preto som písal či sa medzi C++/C# rozhoduje práve kvôli tomu.
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.
Sry, ale IMHO je tu viac-menej nekorektné, sa o nejakej správe pamäti baviť. new a delete sú 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.
No mne islo presne o to, co si vlastne napisal.., ze C++ nedefinguje ako sa ma sprava heap pamate robit, neimplementuje je ju, hoci standard jej existenciu vyzadovat moze. Aka to bude sprava pamate zalezi na implementacii mallocu (presne co si napisal) a na tom ci nie je new overloadnute.... a kedze sa aj prakticky pouzivaju veci ako Ultimate++ (co je stale C++, podla standardu) mi prislo trochu nevhodne to porovnavat s Javou.
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.
Ani Java standard nedefinuje, ako sa ma robit sprava heapu - preto je aj viac typov garbage collectorov a ma zmysel si medzi nimi vyberat podla pouzitia... Sprava pamati v C++ *nezalezi* na tom, ci new nie je overloadnute - da sa overloadnut, ale std C++ vyzaduje presne chovanie pre neoverloadnute new.
C++ v zaklade kniznice mozno nepotrebuje, ale potrebuje chovanie new, malloc a par dalsich drobnosti.
Ale zalezi... ked overloadnes globalne new, tak sprava pamati bude taka, aku si ju implementujes, uz nebude ziadne malloc volane, bude uplne na tebe, aby si zaobstaral kus pamate a vratil nan pointer.
Myslim ze student to myslel tak, ze sprava pamate nie je zavisla (teda bude fungovat aj bez) overloadnutia new, pretoze stadard poskytuje dafaultnu implementaciu.
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"?
Pravdepodobne je to o tom, co je "ozajstna sprava pamate" - ja si pod spravou pamate predstavujem to, ze mi *jazyk* poskytuje moznost, ako ziskat oblast pamate fungujucej aj mimo scope alokacie. Overloading je len moznost naviac, ktora s tymto prakticky nema nic spolocne. Je uplne jedno, co presne overloadnem - mne ide o to, ze to funguje aj bez neho.
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.
Hej, je to o tom, co je 'sprava pamate', ja som to bral ako 'mechanizmus (presnejsie jeho cast), ktorym je pamat pridelovana'. Prepisane new v danej casti kodu pre mna znamena, ze sa pouzije uplne iny mechanizmus a v tej casti kodu sa ma nejaka defaultna standardom vyzadovana alokacia netyka... nech si existuje, ale v danej casti kodu je to uz irelevantne.
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
Ono, vo vseobecnosti, moznost pridania nejakej featury (operator overloading), ak je to nepovinne, tak to urcite nieco neberie (=neberie spravu pamati). Je to jednoducho len option.
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.
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.