Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: cheki 26. 06. 2013, 14:20:35
-
Cawte.
Ucim sa c++. Mam nejake knihy, mam ho aj na skole(v skole to je slabota) a rozne zdroje na nete. Ale od zaciatku rozmyslam nad javou. Nedovolim si tvrdit ze som nejaky pokrocily v c++, stale uroven zaciatocnik si myslim.
Dostala sa mi do ruk kniha od pavla herouta...mam uz od neho jednu k C...a chcem sa opytat ci prejst na javu alebo pokracovat v C++...popripade zacat sa popri c++ ucit aj javu zaroven.
Dakujem za rady
-
moment. nalestim kristalovou kouli a reknu ti co se bude pouzivat, az dostudujes.
-
osobně jsem radši pro C++, nicméně to je otázka mojí preference a tisíc lidí - tisíc názorů
-
Vyber si jazyk, který se ti líbí...
Předpokládám, že jsi na střední a pokud půjdeš na VŠ, tak tě čeká ještě cca 5let než to začneš opravdu dělat. Do té doby můžou být oba jazyky mrtvé a nahrazené Brainfuck-em. Jakmile se naučíš jeden, tak základy použiješ i jinde a není takový problém přejít na jiný jazyk.
Ideálně se nauč oba + klidně nějaký další.:D
-
nevím, jestli je dobrý se učit víc jazyků - já jsem se jich učil asi bažilion a ani jeden tím způsobem neumim pořádně :D Ale možná to je jen chyba mezi židlí a klávesnicí...
-
No já to taky nevím...:) Ale takoví ti programátorští guru doporučují se každý rok kouknout na nějakou novou technologii, aby člověk nezakrněl u jednoho jazyka. Určitě je dobré si alespoň udržovat přehled... Nikdo neříká, že člověk si musí v 15 vybrat např. C a bušit ho do smrti.
-
to je zas asi pravda, no...
-
none_: to ne, ale aspon se to naucit poradne ne? :)
cheki: a planujes delat co? kazdopadne, pokud jsi urovni zacatecnik v c++, zustan u toho a poradne se nauc OOP, vazne nepotrebujeme v Jave dalsi bastlire... jak budes umet poradne principy OOP a v c++ nejaky programek udelas, muzes se klidne podivat na javu... ja osobne momentalne delam vetsinou kombinaci c++ (klient) a java (server)
-
Z môjho skromného pohľadu ti to môže byť takmer jedno ktorý jazyk zvolíš. Dôležitejšie je získať skúsenosti s rôznymi paradigmami, naučiť sa analyticky myslieť. Až potom budeš mať dobrý základ pri návrhu softvéru a pri voľbe vhodných prístupov a technológií. Špecifiká jazyka (a C++ tých špecifík ma zaisto fúru) potom pochytíš praxou. Podľa mňa mnohí developeri robia chybu že sa sústredia len na jednu technológiu a stávajú sa z nich "cvičené opice" s perfektnou znalosťou jazyka a už nevedia priniesť do projektu nič nové iba dokonale kopírovať existujúce patterny a aj to len limitovaný počet.
To máš tak aj v reálnom živote. To že niekto vie perfektne po anglicky automaticky neznamená, že vie písať romány alebo básne.
-
moment. nalestim kristalovou kouli a reknu ti co se bude pouzivat, az dostudujes.
Leštit nic nemusíš, používat se bude oboje ;-)
-
Pokud je Ti těch 8-10 roků (jak tajně doufám), tak Ti poradím, aby ses tímto ještě moc nezatěžoval a věnuj se normálnímu učení a vůbec všem věcem odpovídajícím Tvému věku.
Pokud jsi už na nějaké střední škole, tak jsem lehce zděšen.
A pokud už jsi student VŠ, tak jen poprosím, zda bys nemohl zveřejnit jméno onoho ústavu. Zařadím si ho do seznamu odstrašujících příkladů ...
-
Proč zděšen ze střední? Pokud chodí třeba na gympl, tak tam tě programovat moc nenaučí. Nejen, že to tam nikdo neumí, ale hlavně tam na to není hodinová dotace.
Netuším, proč by to nemohl dohnat na VŠ. Např na FEL bych řekl, že je poměr gympláků vs technický školy klidně 50:50 a, pokud nejde o pájení, tak jsem si nevšiml žádného významného rozdílu po skončení VŠ.
-
Hi.
A co je Tvojim cielom?
-
Let the flame begin!
-
no takze nebudem kazdemu odpovedat zvlast:D
takze studujem na vysokej skole, pred par dnami som spravil statnice(bc) a idem dalej.
Neviem preco si zdeseny, ale okej bud...
nestudujem zrovna it skolu, ja na to trochu zamerana...ale mam v plane ist na fit.
co sa tyka tych jazykov tak nejde mi o to ze co sa bude pouzivat ked dostudujem pretoze aj kebyze studujem este 10r tak si myslim ze stale sa budu pouzivat tie co teraz.
Co sa tyka c++ tak presiel som knihu naucte se c++ za 21 dni (dufam ze nebude z toho nikto zdeseny ale trvalo mi to viac ako 21 dni kym som ju presiel) potom som siel na mistrovstvi v c++, nieco nove som sa naucil, nieco zopakoval.
nejake tie programy uz spravit viem...samozrejme nie nejake extra zlozite a super ale nieco primitivne uz zvladam...zatial vsetko len konzolove programy....nejake to gui ci interface este neovladam(dotycny zhrozeny, dufam ze este zijes)
a inac studoval som na gympli...ale to neznamena ze som sa inf nevenoval, neviem ake su koho vedomosti z coho ale mam ich dost...co sa tyka programovania tak som stale na zaciatku.
Islo mi hlavne o to aby som zistil ci je lepsie venovat sa jednemu alebo ak by som sa popri c++ ucil aj druhy, ci to ma aj vyznam, su dost podobne, takze by sa to dalo. Nechcel som aby debata smerovala kde studujem a ze sa mam na to radsej vy*rat a niekoho zdesit(:D)
tisic ludi, tisic nazorov> preto som chcel aspon par nazorov nech viem co dalej.
Co sa tyka co by som chcel robit? tazko povedat zatial si neviem predstavit ako sa navrhuje nejaky kvalitny program(to je uz jedno aky napr icq, to je fuk) kedze neviem ako sa robi interface...nieco som k tomu uz pozeral ale zatial som tomu nevenoval velku pozornost. Mozno casom, ak by som sa pustil aj do tej javy tak nejake aplikacie na android...
-
Let the flame begin!
Zatial pracovat ako databazer, neskor prejst na programatora....nejaky developer
-
Hi.
A co je Tvojim cielom?
Zatial pracovat ako databazer, neskor prejst na programatora....nejaky developer
-
moment. nalestim kristalovou kouli a reknu ti co se bude pouzivat, az dostudujes.
Leštit nic nemusíš, používat se bude oboje ;-)
Co ty vis jak dlouho bude studovat? (No a prave na to zjisteni potrebujeme tu kouli.)
-
To je dotaz typu "Lidi, poraďte mi, jestli mám topit hnědým nebo černým uhlím" nebo "Jsou lepší nektarinky nebo broskve?". Já jsem si u obojího vybral, Ty by sis možná vybral něco jiného. Ani jedno by nebylo špatně.
C++ je jeden z nejkomplexnějších jazyků, které jsou "mainstream". Java je přeci jen jednodušší, i když taky má "ostré hrany". Jestli jsi na střední, je celkem jedno, co si vybereš - jde tu spíš o tom, jaké prostředí je Ti bližší.
Máš raději programy, které běží přímo nad operačním systémem a mohou si snadno sáhnout na železo? Chceš aby Ti nikdo nekecal jak si urovnáváš data v paměti? Chceš mít volnou ruku v tom tu a tam udělat nějakou prasečinku a tím zrychlit běh svých programů?
Pak zvol C++!
Máš raději prostředí, které Ti poskytne všechno možné, které má knihovny téměř na všechno a při tom nemusíš řešit noční můry jako nekompatibilní ABI různých kompilátorů nebo ruční kompilaci závislostí? Nechceš zbytečně řešit těžko dohledatelné "memory leaky" (= zapomenutá / ztracená data v paměti), prostě ať se o to postará někdo jiný, já jsem tu od programování? Nechceš se zbytečně strachovat, kdy Tě zase jazyk vyliská s naprosto nepochopitelnými a nečitelnými hláškami kompilátoru?
Pak zvol Javu!
V dnešní době také neplatí, že OOP = Java nebo OOP = C++. Objektově orientované programování se naučíš klidně v Object Pascalu nebo Pythonu, je to celkem jedno.
A jinak jestli myslíš brněnský FIT VUT, tak se začni drtit C. Budeš ho v prváku potřebovat (Základy programování), jestli se něco nezměnilo. Jestli chceš jít rovnou na magisterské studium FITu a neumíš programovat (tam je prý celkem jedno, v jakém jazyku projekty děláš - většinou si můžeš vybrat; sice mám tu informaci z první ruky, ale osobně jsem to nezažil, tak to ber s rezervou), bohužel Ti musím s lítostí oznámit, že jsi zbytečně vyhodil peníze za přihlášku.
-
Tak teď jsem se trochu zděsil já...:) Pokud už jsi Bc, tak to vážně zavání tím, že jsi trošku zaspal... Programovat jsem se naučil nejvíc právě na Bc.
Ale možná, že si jen málo věříš a programovat umíš... Každopádně po Bc už by si měl aspoň vidět víc než jeden jazyk a vědět, který z nich tě baví a více se mu věnovat.
-
Let the flame begin!
Zatial pracovat ako databazer, neskor prejst na programatora....nejaky developer
To byla odpověď? :)))
Jinak imho se ptáš špatně - příliš obecně. Otázka "co je lepší?" je skoro vždycky špatně. Jestli chceš dělat embedded systémy, tak je asi lepší C++. Jestli chceš dělat velké komerční weby, tak je lepší java. Jestli se ptáš na to, jaký jazyk má větší budoucnost, tak může každý tak leda odhadovat na základě volně dostupných statistik (např. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html nebo nějaké ty jobs portály).
Prostě, pokud chceš dostat nějakou rozumnou odpověď, ze které se něco dozvíš a ne jenom zahájit mnohastránkové plkání o ničem, musíš tu otázku postavit nějak konkrétněji. Jenže když ji postavíš konkrétněji, stačí ji přeložit do angličtiny, zadat do googlu a nemusíš ji psát sem :)
-
...
V dnešní době také neplatí, že OOP = Java nebo OOP = C++...
to sice ne, ale je rozdil mezi ciste objektovym jazykem a jazykem, ktery ma i funkcionalni cast
ad autor: no to je dost mimo, pokud jsi Bc, ikdyz ne uplne IT... pokud planujes jit znovu do bakalarskeho studia na informatiku, nauc se c++, pokud na magisterske, ani tohle ti nepomuze
-
Uf, co Ti povedat. Ries Javu, i ked ja by som skor riesil C#, lebo pisat v Jave sa mi fakt nechce, je strasne ukecana. C# je nieco ako dotiahnuta Java. Ak narazis na nieco, na co Ti Java nestaci, potom C++. Ale aj bez stastia by to nikdy nemuselo nastat. Pre Tvoju informaciu, kniha Mistrovstvi v C++ je velmi roztahany uvod do C++. Skutocne, iba uvod. Pride mi to taky prakticky pristup. Je dost velka sanca, ze si cely zivot vystacis s Javou.
Ale jazyk je iba nastroj na vyjadrenie myslienok. Je fajn vediet nieco o zlozitosti, datovych strukturach a algoritmoch. Este takto. Poznam ludi, najme z VSE ktori programuju v Jave. Oni vedia pisat kod v Jave ale vo vseobecnosti programovat nevedia. Otazka je, ci chces vediet programovat alebo sa uspokojis s pisanim kodu v Jave. Pre business aplikacie je vacsinou pisanie kodu v Jave dostacujuca schopnost. K tomu este treba byt timovi hrac, na co odporucam knizku Clean Code.
Drz sa.
-
Ve fázi znalostí c++ za 21 dní bych se mrknul na nějaké algoritmy a také vzory, které v oné knížce nejsou. Co se týče práce, více se chce Java. Ale je tam taky proto velká konkurence.
-
Uf, co Ti povedat. Ries Javu, i ked ja by som skor riesil C#, lebo pisat v Jave sa mi fakt nechce, je strasne ukecana. C# je nieco ako dotiahnuta Java.
Väčšinu nudnej práce okolo písania v Jave dokáže zvládnuť solídne IDE. C# je naozaj dosť dobre obtiahnutá Java a ako obyčajne to tým zlodejom z M$ prešlo.
-
...zatial vsetko len konzolove programy....nejake to gui ci interface este neovladam(dotycny zhrozeny, dufam ze este zijes)
Na tom neni nic spatneho.
Ale pokud se chces s GUI alespon trochu seznamit, v pripade, kdy umis trochu C++, muzu jedine doporucit Qt (samozrejme v Qt Creatoru). Sam sem s nim zacinal v dobe, kdy sem umel dobre akorat C, o C++ a OOP sem mel jen mlhave predstavy. Ale stejne sem do hodiny udelal prvni program s par funkcnimi tlacitky a velmi brzy zacal delat rozsahlejsi veci. Qt ma predevsim skvelou dokumentaci a velmi dobre IDE, umoznuje vylozene se ucit za chodu.
K tomu nastupu na vysku, pokud mas na mysli opravdu FIT na VUT v Brne, na magistra honem rychle zapomen. Pokud bys nastoupil na bakalare, nadres se, ale mas sanci (nicmene velky duraz bude na C). Pouzivani vice jazyku se ale tak jak tak nevyhnes, nicmene nevidel bych to jako problem.
-
Tak ono je hlavne dobry vedet, proc si vybiram, ze se budu neco ucit. Jinak je to takova otazka trosku obdobna jak z vlakna jaky jazyk pro freelancera akorat s mozna jinymi hodnoticimi kriterii. Jinak vyvojove trendy se daj podchytit ze statistik, ktery ovsem budou ukrutne zkresleny, protoze vzorek co pouzivaji nebude nikdy odpovidat kriteriim podle kterych vybiras ty.
(Launchpad) S kterym jazykem se nejcasteji prauje dalsi:
http://flossmole.org/category/queries/programming-language
(ohloh) Srovnani jazyku podle radek kodu v projektech
http://www.ohloh.net/languages/compare
Ktery jazyk sytakticky a principy z ceho castecne vychazi http://www.techjini.com/blog/wp-content/uploads/2011/10/tongues-cleaner.png z toho je videt, ze kdyz umis C++, tak Java ani C# nejsou uplne slapnutim do neznama.
(Sourceforge) Statistiky radek kodu v commitech v case
http://wismuth.com/lang/languages.html a dole na strance dalsi dva zdroje (btw. ta RH 7.1 co je v jednom odkazu neni 7.1 co se jeste nezacala ani planovat, ale staricka jeste z dob, kdy neexistovala Fedora)
(kumulativni, kod, dotazy, pouzivanost) Jazyky podle "zivosti" komunit programatoru.
http://www.tiobe.com/content/paperinfo/tpci/index.html
(O'Reilly) popularita jazyku podle prodeje knih.
http://radar.oreilly.com/2006/08/programming-language-trends.html
Trendy vyhledavani jazyku
http://stackoverflow.com/questions/7391419/how-to-find-stats-for-general-trends-of-programming-language-popularity-using-go
Mimoradne vtipny je druhy trend, kde nejvic programatoru ve Flashi je v Pakistanu. Podobnost jmena jazyka s nastraznymi vybusnymi systemy nebo obnazovanim je ciste nahodna a vubec tento trend nezkresluje ;-)
-
a jeste jedna opomenuta... http://www.r-bloggers.com/programming-language-popularity-stackoverflow-and-ohloh/
-
nedavno to tu bylo krasne napsane, ale programovani a znalost nejakyho jazyka je tak slaba petina toho co potrebujes abys byl pouzitelnym programatorem => je to naprosto nevyznamna a podruzna otazka. musis mit mnohem sirsi zaber znalosti.
-
Nauč se nejprve C++, protože z C++ se dá na Javu zlenivět vždy bez problémů. Zato s přechodem z Javy na C++ mají lidi neskutečné problémy, protože pořádně nechápou pointery, nezajímá je práce s pamětí a bastlí neuvěřitelné zhůvěřilosti - např. už namísto atoi, scanf, printf raději na haldě vytvoří stringstream. Plus si z Javy do C++ přinesou množství návyků, které jsou v C++ vyloženě špatné.
-
Nauč se nejprve C++, protože z C++ se dá na Javu zlenivět vždy bez problémů. Zato s přechodem z Javy na C++ mají lidi neskutečné problémy, protože pořádně nechápou pointery, nezajímá je práce s pamětí a bastlí neuvěřitelné zhůvěřilosti - např. už namísto atoi, scanf, printf raději na haldě vytvoří stringstream. Plus si z Javy do C++ přinesou množství návyků, které jsou v C++ vyloženě špatné.
Do značné míry to platí i opačně, pouze v Javě jsou dopady směšné ve srovnání s C++ (typicky: špatně udržovatelný kód vs. segmentation fault).
Osobně bych spíš doporučoval C, tam se skutečně člověk naučí co je to pointer. K tomu nějaký vyšší jazyk (třeba Python/perl/ruby) a tam se naučit že to jde i bez pointerů. A pak lze míchat kombinace :-)
-
Nauč se obojí, ono se to hodí. Já to během své pracovní kariery střídám, 2x jsem dělal s JNI, tam je oboje najednou. Jinak Java/C++ záleží na programátorském stylu a na tom, co chceš psát. Hodně lidí tvrdí, že jeden nebo druhý jazyk je na XXX, ale to jsou většinou vymaštěnci nebo zaslepenci.
-
Ahoj, za mě osobně C++. Ne, že bych měl něco proti Jave (vlastně mám, C# - kéžby takhle Java vypadala od začátku, bohužel se z ní stáva stále větší nenažranec systémových prostředků), ale C++ je natolik komplexní jazyk, že z něj přejdeš do jakéhokoliv jiného (kromě v jednom z příspěvků zmiňovaném Brainfucku :D ). Jinak, pokud půjdeš na další výšku, tak v prváku bych počítal se základy algoritmizace (na některých výškách se jde dodnes setkat s Pascalem), ty budou v C a C++, ve druháku už by se to mělo profilovat (bohužel z mé zkušenosti vím, že výška moc vprogramování nedá - začneš Hello World a skončíš u práce s textem a soubory, možná dojde i na grafiku a myš, ale hlavně se musíš tomu věnovat sám, to se teď týká toho Céčka a C++).
K jednomu zdejšímu příspěvku: On sice možná ten MS ukradl koncept Javy a udělal z něj C#, ale dle mého názoru, je tady aspoň vidět, že i tak neoptimalizovaná věc, jakou Java je, se optimalizovat dá. Bohužel se někde vytratila multiplatformost (na Javu stačí snad jen prohlížeč).
-
Nauč se nejprve C++, protože z C++ se dá na Javu zlenivět vždy bez problémů. Zato s přechodem z Javy na C++ mají lidi neskutečné problémy, protože pořádně nechápou pointery, nezajímá je práce s pamětí a bastlí neuvěřitelné zhůvěřilosti - např. už namísto atoi, scanf, printf raději na haldě vytvoří stringstream. Plus si z Javy do C++ přinesou množství návyků, které jsou v C++ vyloženě špatné.
Nemůžu si nerejpnout, že scanf a printf jsou v C++ neuvěřitelné zhůvěřilosti. Jsou to Cčkové funkce, ne C++. Chápu, ty dva jazyky k míchání svádí, ale mělo by se to dělat pouze v dobře odůvodněných případech (např. C wrapper kolem C++ kódu apod)
-
OK :) A souhlas i s Podleshem :)
Když jsem to psal, tak jsem si vzpomněl na člověka, který měl načíst dvě celá čísla z textu, např. "1 2\n". Tak to udělal ala Java tím, že nejprve alokoval paměť, kam zkopíroval řetězec, který už měl jednou v paměti. Pak na haldě vytvořil objekt vlastní třídy, String.split, jehože metoda mu vrátila dva nové řetězce "1" a "2". Ke každému z nich opět na haldě vytvořil stringstream, se kterým konečně udělal ss >> d;
Celé číslo pak konvertoval na řetězec vyvvořením stringstream na haldě, přes << zařídil konverzi, přes stringstream.str získal std::string a teprve potom přes .c_str() printf vypsal stdout. Tak jsem mu tenkrát ukázal právě zmíněné, rýpnutelné scanf a printf :)
Z části je to jeho neznalost dostupných knihoven a funkcí, z části je na tom vidět, jak kopíruje způsob práce Javy. Ale nejvíc zarážející na tom je, že ačkoliv byl považovaný za dobrého Java programátora, nic ho netrklo, že to dělá dost zbytečným a komplikovaným způsobem. V C/C++ by programátora snad otrávila už jenom četnost alokace paměti a hledal by, jestli se to nedá udělat jednodušeji.
-
Nemůžu si nerejpnout, že scanf a printf jsou v C++ neuvěřitelné zhůvěřilosti. Jsou to Cčkové funkce, ne C++. Chápu, ty dva jazyky k míchání svádí, ale mělo by se to dělat pouze v dobře odůvodněných případech (např. C wrapper kolem C++ kódu apod)
A co teprve c/s/f-scanf a printf :D Úpřimně, na jednoduchý vstup a výstup cin a cout postačí, ale na formátovaný už ne (a taky si rýpnu - oba dva jak cin a cout sou oproti printf scanf pomalé).
to x86: Proč dělat něco jednoduše, když to jde v Javě :D Nedivím se, že je tak nenažraná.
-
x86: pokus o trolling? oznacovat tyhle prasarny za praktiky javy? :)
Withy14: je videt, ze javu neumite... pokud programator neni prase, tak jsou ty aplikace rychlejsi nez v c#, hlavne je to dano VM... bez optimalizace se neobejdete nikde :)
-
x86: pokus o trolling? oznacovat tyhle prasarny za praktiky javy? :)
Withy14: je videt, ze javu neumite... pokud programator neni prase, tak jsou ty aplikace rychlejsi nez v c#, hlavne je to dano VM... bez optimalizace se neobejdete nikde :)
Javu možná neumím, ale rychlejší než C#? Nesetkal sem se s žadnou aplikaci Javy, která by mě o tom přesvědčila. Schválně mi najděte dvě stejné aplikace - jednu v Javě a druhou v C#, které mě přesvědčí o opaku. A teď nemyslím jednoduché aplikace typu 1+1, tam těžko budu vidět rozdíly.
-
x86: pokus o trolling? oznacovat tyhle prasarny za praktiky javy? :)
Ne, prostě jsem jenom popsal, co jsem (nejednou) viděl - Java programátora snažícího se programovat v C++ způsobem, na který byl zvyklý z Javy. Prostě jenom příklad z praxe k prvnímu komentáři, který jsem v tomhle vlákně napsal.
-
Jazyk je jen nástroj, vyberte si na učení ten, který vám vyhovuje a ve kterém vás bude bavit stále něco programovat.
Stejně nic použitelného ještě pár let nevytvoříte, tudíž zabývat se tím jak je který použitelný v praxi je zatím zbytečné - důležité je osvojit si principy programování.
Jinak dobře že čtete Pavla Herouta, také jsem ho kdysi četl a jeho učebnice mi ze začátku hodně daly.
-
Ne, prostě jsem jenom popsal, co jsem (nejednou) viděl - Java programátora snažícího se programovat v C++ způsobem, na který byl zvyklý z Javy. Prostě jenom příklad z praxe k prvnímu komentáři, který jsem v tomhle vlákně napsal.
Jenom tak naokraj: a není to trochu taky tím, že C++ je prostě jazyk, který si hraje na OOP, ale člověk ho nemůže normálně jako OOP používat, aniž by nemyslel na miliony různých skrytých souvislostí? ( => byla to opravdu chyba toho programátora, že předpokládal, že C++ je sane OOP jazyk?)
-
Tak, že je Java rychlejší než C#, je tvrzení od člověka, který má o C# asi dost zkreslené představy. Ono taky záleží, jestli člověk člověk v C# používá pointry (to jsem si nevymyslel, pár let v tom programuju). V C# člověk totiž může používat garbage collection, který je tam "default", ale taky nemusí a může se přistupovat i přímo do paměti. CLR funguje jinak, než JVM. To je jeden z důvodů proč se v C# píšou i drivery.
S kolegy jsem prováděli nějaké testy C# x C++, na velkých množství dat a C# byl v některých momentech jen o málo pomalejší než C++.
Navíc dnes už není pravda, že C# je jen pro malé aplikace. Vyvíjel jsem pár rozsáhlých serverových systémů, které byly v C# (měly OS Win i Linux). Nemám nic proti Javě, každý jazyk se hodí k něčemu, ale mám hodně proti podobným unáhleným (možná trošku zaslepeným) tvrzením, které tu zazněly.
-
Honta: nikde netvrdim, ze C# se neda pouzit na velke aplikace... jinak by se nepouzivalo :) s CLR moc zkusenosti nemam, nicmene JVM se da vyborne skalovat
hlavne ono ani neni pravda, ze je java vzdy rychlejsi nez c#... v necem je c# rychlejsi, ale z mych zkusenosti (a nejenom mych), je java obecne rychlejsi (ale rikam, zalezi na aplikaci, programatorova a optimalizacich jvm)... tvrdit, ze java je vzdy rychlejsi nez c# je stejna blbost, jako napsal Withy14
no a o monu ani nediskutuju, to je na linuxu paskvil... je treba na nem jeste zapracovat, aby se c# mohlo nazyvat multiplatformnim jazykem
x86: na takoveho programatora narazit v praci, tak ho hnedka vyrazim... nejenom proto, ze neznam snad zadneho javistu, ktery by programoval tak prasacky
Withy14: a nejakou takova existuje? proc by nekdo delal velkou aplikaci dvakrat v ruznych jazycich? podivejte se na benchmarky z implementaci "jednoduchych aplikaci", ktere jsou urcene prave pro toto... no a jak muzete hodnotit javovske aplikace a tvrdit, ze java je blba, pomala, ze c# je rychlejsi, kdyz javu neumite? navic, ja vas o nicem presvedcovat nehodlam... svuj nazor mate, zaryte se ho budete drzet, i kdybych predvedl solidni argumenty
-
CLR funguje jinak, než JVM. To je jeden z důvodů proč se v C# píšou i drivery.
V C# drivery ?!
Pokud se bavime o kernel-modu, tak je to zcela vylouceno.
Pokud se bavime o user-modu, tak jedine s nejakym dalsim frameworkem, cimz tak nejak postradam, proc to tu vlastne zminujes.
-
namísto atoi, scanf, printf raději na haldě vytvoří stringstream
printf a spol. narozdíl od streamů nemá žádnou typovou kontrolu a dá se s tím užít spousta legrace:
int a = 0, b = 1;
printf("%i\n%i\n", a, b);
Upíšu se a místo \n napíšu %n:
printf("%i%n%i%n", a, b);
Neoprávněný přístup do paměti (SIGSEGV)
-
To je jeden z důvodů proč se v C# píšou i drivery.
Tak to ani náhodou, linker od C# vůbec neumí vyprodukovat SYS soubor pro kernel.
V C# jsou leda tak hračky v user-mode, to ale nemá s driverem společného vůbec nic.
-
to gamer: Jestli se takhle upisuejs bezne (kde je ku**a na klavesnici lomitko vedle procent?), tak radeji zustan u her. Je to asi jako bych rekl, ze matematika je na nic, protoze se muzu upsat a misto 4 + 2 = 6 napsat 4 * 2 = 6 a mit to blbe. Debilni vec ta matematika, co?
-
to gamer: Jestli se takhle upisuejs bezne (kde je ku**a na klavesnici lomitko vedle procent?), tak radeji zustan u her. Je to asi jako bych rekl, ze matematika je na nic, protoze se muzu upsat a misto 4 + 2 = 6 napsat 4 * 2 = 6 a mit to blbe. Debilni vec ta matematika, co?
Osobní urážky místo něčeho konstruktivního? Nic lepšího nevymyslíš?
-
printf a spol. narozdíl od streamů nemá žádnou typovou kontrolu a dá se s tím užít spousta legrace:
int a = 0, b = 1;
printf("%i\n%i\n", a, b);
Upíšu se a místo \n napíšu %n:
printf("%i%n%i%n", a, b);
Neoprávněný přístup do paměti (SIGSEGV)
Tak to si resi kazdej rozumnej prekladac:
test.c:6: warning: format ‘%n’ expects type ‘int *’, but argument 3 has type ‘int’
test.c:6: warning: too few arguments for format
-
...
Tak to si resi kazdej rozumnej prekladac:
test.c:6: warning: format ‘%n’ expects type ‘int *’, but argument 3 has type ‘int’
test.c:6: warning: too few arguments for format
No, chodí po tomto světě "experti", kteří si warningy vypínají, aby měli compile-logy "co nejčistší"...
;D ;D
-
Tyhle warningy se musí explicitně zapnout:
g++ main.cc
g++ -Wall main.cc
main.cc: In function ‘int main()’:
main.cc:9: warning: format ‘%n’ expects type ‘int*’, but argument 3 has type ‘int’
main.cc:9: warning: too few arguments for format
a fungují jen tehdy, pokud je formátovací řetězec konstatní string, známý už během compile-time:
const char* format = "%i%n%i%n";
printf(format, a, b);
g++ -Wall main.cc
Takže spoléhat se na ně rozhodně nedá. printf a spol. funkce by v moderním C++ kódu neměly vůbec být kvůli nulové typové kontrole, pokud k tomu není nějaký zvláštní důvod. Doporučuju používat boost format, to je typově bezpečné:
http://www.boost.org/doc/libs/1_53_0/libs/format/
-
Neznám nikoho, kdo by nebyl totální lama* , a -Wall neměl zaplé.
Každopádně souhlasím s tím, že funkce jako printf, malloc/free, setjmp/longjmp etc. by v C++ kódu být neměly, přestože si překladač stěžovat nebude.
* takovej lempl, že pracovat s ním v týmu, tak zajdu za šéfem s podepsanou výpovědí a "Buď já nebo on půjde do jinýho týmu, anebo mi podepiš tohle a za dva měsíce už mě tu neuvidíš"
-
Každopádně souhlasím s tím, že funkce jako printf, malloc/free, setjmp/longjmp etc. by v C++ kódu být neměly, přestože si překladač stěžovat nebude.
Tohle považuji za naprosto zásadní výhodu Javy - tyhle nebezpečné funkce v ní prostě nejsou. Když pracujete na obrovském projektu tak je strašně důležité mít jistotu že modul od dodavatele na druhé straně planety v sobě nemá podobnou past. To samé platí o přebírání cizího kódu - v C++ můžete strávit dost času přepisováním do "lepšího C++", v Javě je ten minimální standard jasně daný (a mnohem vyšší než v C++). Toto (zahození zpětné kompatibility s C) považuji za velkou výhody Javy která vedla k jejímu dnešnímu velkému rozšíření do "enterprise" sféry, kde je spolupráce obrovských týmů a předávání kódů mezi dodavateli běžná věc.
-
Toto (zahození zpětné kompatibility s C) považuji za velkou výhody Javy která vedla k jejímu dnešnímu velkému rozšíření do "enterprise" sféry, kde je spolupráce obrovských týmů a předávání kódů mezi dodavateli běžná věc.
V tom mas pravdu, ale to same se ted deje v Jave znovu - na vyssi urovni. Jeden tym "fandi" Springu, druhy pouziva JEE zatimco treti jeste zustava u J2EE(plus JSP vs. JSF vs JSF2, ElipseLink vs. Hibernate, ...). Prenositolnost mezi OS uz docela funguje a najednou se resi prenositelnost mezi aplikacnimy servery.
-
stve ma, ze si tu nicky meraju medzi sebou penisy a povodna otazka zapadla do zabudnutia aj z jej autorom
-
Takhle končí každý flame. Sorry, ale ta otázka si o to přímo řekla.
-
Toto (zahození zpětné kompatibility s C) považuji za velkou výhody Javy která vedla k jejímu dnešnímu velkému rozšíření do "enterprise" sféry, kde je spolupráce obrovských týmů a předávání kódů mezi dodavateli běžná věc.
V tom mas pravdu, ale to same se ted deje v Jave znovu - na vyssi urovni. Jeden tym "fandi" Springu, druhy pouziva JEE zatimco treti jeste zustava u J2EE(plus JSP vs. JSF vs JSF2, ElipseLink vs. Hibernate, ...). Prenositolnost mezi OS uz docela funguje a najednou se resi prenositelnost mezi aplikacnimy servery.
Ano, je to tak - ale to je přirozený vývoj a důsledek otevřenosti Javy, nikdo tam nikomu nemůže zakázat aby si implementoval vlastní framework (typicky třeba Spring má všude něco udělaného po svém), jen trh rozhodne o tom zda se framework rozšíří nebo ne. U C++ je to podle mě ještě horší, tam velké obecné frameworky snad ani nejsou, takže si aplikace každý musí psát po svém - a šance že se trefíte do toho že ten druhý to bude rovnou umět je tedy nulová.
Spekulace: že by se u C++ velké projekty dusily na řešení banálních low-level věcí jako je třeba memory management a proto těch velkých projektů v C++ nakonec není tolik a proto se nikomu nevyplatí investovat do tvorby obecných frameworků?
Nepsal jsem že spolupráce mezi programátory je v Javě jednoduchá, jen jsem psal že je díky těm standardizovaným low-level věcem jednodušší než u C++ a existence obecných frameworků (i když více a soupeřících) je taky nakonec plus - dává jakousi naději že trefíte na programátory kteří už ten framework budou znát a nebudou se všechno muset učit od nuly.
-
Takhle končí každý flame. Sorry, ale ta otázka si o to přímo řekla.
To je tak když chybí moderátor
-
Také si myslím, že nikdo neudělá chybu, když si dá epizodu třeba s čistým C a ASM na nějakém jednochipu. Zjistíte, jak funguje procesor a jak řešit problém s velmi omezenými zdroji.
-
Mistr mého bojového umění mi neustále tvrdí, že je jedno, jak cvičím, ale hlavně, že cvičím. To, jak to dělám, se s postupem času vypiluje.
Tazateli, ať si zvolíš Javu nebo C++, neuděláš chybu. Každý jazyk má svá specifika. Hlavní je, abys programoval. Ať Ti kdokoliv bude tvrdit, že přechodem z C++ do Javy se neodnaučíš špatné návyky z Javy, pak je to kec. Vše je jen o sebemotivaci.
-
Také si myslím, že nikdo neudělá chybu, když si dá epizodu třeba s čistým C a ASM na nějakém jednochipu. Zjistíte, jak funguje procesor a jak řešit problém s velmi omezenými zdroji.
To su len zbozne priania nedocenenych ludi, ktori sa ucili programovat v 80tych rokoch.
-
Mistr mého bojového umění mi neustále tvrdí, že je jedno, jak cvičím, ale hlavně, že cvičím. ´
...
Tazateli, ať si zvolíš Javu nebo C++, neuděláš chybu. Každý jazyk má svá specifika.
Este by som doplnil: Tak ako v bojovom umeni by bolo naivne najprv sa naucit najprv iba postoje a az ked tieto dokonale zvladnes prejst na techniky ako kopy a udery, tak isto je naivne mysliet si, ze najprv sa naucit dokonale jeden jazyk a az potom prejdes na iny. Mozes sa obe veci t.j. C/C++ a Javu ucit sucasne. Aj tak kym v nich neurobis niekolko projektov nebudes ich vediet dokonale. Ale mozes sa s nimi zoznamovat aj sucasne. Vyvojove nastroje pre oba jazyky su k dispozicii zadarmo. Takze mozes si sucasne skusat C/C++ aj Javu a porovnavat co sa ako da v ktorom jazyku naprogramovat. Neskor v praxi C/C++ sa ti moze hodit na backendy a Java na frontendy aplikacii.
-
Java je krajsi jazyk, nie je nou co pokazit.
C++ umoznuje pisanie rychlejsieho kodu a mozno o nieco malo efektivnejsie, ale to moze viest k zlym navykom (viacnasobna dedicnost, ked ide o nieco viac ako "interface"; public/private dedicnost). Na druhu stranu to uci cloveka po sebe "upratovat" a nespoliehat sa na GC a mozno aj nieco o tom, ako mozu byt objekty reprezentovane.
-
Ak chces univerzalny jazyk tak C++ - s nim sa naucis zaklady ako pisat efektivne algoritmy - pochopis ako vytvorit rychly, optimalizovany a pametovo nenarocny kod a naucis sa zaklady proceduralneho a objektoveho programovania. Vyhoda C++ je ze ho mozes pouzit prakticky na akykolvek typ aplikacie (od hier, cez systemove veci, po ovladaci software pre raketoplany). Nevyhoda je ze je to nehorazny bordel - kde sa da kazda vec robit X sposobmi.
A potom mozes skusit nejaky moderny vysokourovnovy jazyk ako trebars: F#, Erlang, Scala, Clojure, Kotlin, Ocaml - tieto jazyky ti rozsiria obzory a uplne ti zmenia pohlad na programovanie. Taktiez by si mohol skusit dynamicke jazyky ako LUA, Javascript alebo Ruby - na take domace skriptovanie (dynamickym jazykom by som ale rozhodne nezacinal).
-
Java je krajsi jazyk, nie je nou co pokazit.
C++ umoznuje pisanie rychlejsieho kodu a mozno o nieco malo efektivnejsie, ale to moze viest k zlym navykom (viacnasobna dedicnost, ked ide o nieco viac ako "interface"; public/private dedicnost). Na druhu stranu to uci cloveka po sebe "upratovat" a nespoliehat sa na GC a mozno aj nieco o tom, ako mozu byt objekty reprezentovane.
Co je špatného na vícenásobné dědičnosti, kde jde o něco víc než jen interface? A co je špatného na private dědičnosti?
Btw. nespoléhat se na GC je hodně velká výhoda. Člověk pak nedělá příšerné leaky, protože mu nedojde, že to GC nevyřeší.
-
Co je špatného na vícenásobné dědičnosti, kde jde o něco víc než jen interface? A co je špatného na private dědičnosti?
Vícenásobná dědičnost není v Javě, tak musí být špatná ;)
-
..ani v jave, ani v pythone, ani v ruby...vlastne, kde inde *je*?
leaky v jave sa robit daju, ale zase sa daju naucit aj zasady, ako ich nerobit
navyse tie zasady netreba poznat hned na zaciatku vzdelavania sa
-
Viacnasobna dedicnost nie je popularna v jazykoch s GC. Problem je v tom, ze vsetky triedy su vecsinou odvodene od bazoveho objektu. Takze pri viacnasobnej dedicnosti by vzdy vznikal diamant a to by bol problem... C++ nema GC a nepotrebuje bazovy objekt takze nie je problem z viacnasobnou dedicnostou.
-
C++ nema GC a nepotrebuje bazovy objekt takze nie je problem z viacnasobnou dedicnostou.
Problém je i v C++, s vícenásobnou dědičností neuděláš
Base* base = nejaka_bazova_trida;
Derived* derived = static_cast<Derived*>(base);
Musí tam být dynamic_cast.
-
C++ nema GC a nepotrebuje bazovy objekt takze nie je problem z viacnasobnou dedicnostou.
Problém je i v C++, s vícenásobnou dědičností neuděláš
Base* base = nejaka_bazova_trida;
Derived* derived = static_cast<Derived*>(base);
Musí tam být dynamic_cast.
Jenže ten je potřeba i u interfaců, aby se správně posunul pointer ve vtable
-
Jenže ten je potřeba i u interfaců, aby se správně posunul pointer ve vtable
C++ nemá interfacy a java nemá static_cast, takže nějak nerozumím, jak static_cast na interface udělat ;)
-
..ani v jave, ani v pythone, ani v ruby...vlastne, kde inde *je*?
Vícenásobná dědičnost je v Javě 8 (až tedy vyjde), Scale i Ruby. Diamond není problém, pokud se to navrhne dobře.
V Javě 8 to vyřešili jednoduše tak, že v interfacech stále nesmí být fieldy a v případě kolize metod je třeba explicitně říct, kterou ze zděděných implementací chci.
Scala má naproti tomu jasnou specifikaci pořadí přimixování traitů, takže trait díky tomu umí v podstatě všechno co abstraktní třída (fieldy, protected dědičnost), jenom mu chybí kontruktor.
-
Cawte.
Ucim sa c++. Mam nejake knihy, mam ho aj na skole(v skole to je slabota) a rozne zdroje na nete. Ale od zaciatku rozmyslam nad javou. Nedovolim si tvrdit ze som nejaky pokrocily v c++, stale uroven zaciatocnik si myslim.
Dostala sa mi do ruk kniha od pavla herouta...mam uz od neho jednu k C...a chcem sa opytat ci prejst na javu alebo pokracovat v C++...popripade zacat sa popri c++ ucit aj javu zaroven.
Dakujem za rady
Programming: Principles and Practice Using C++
http://www.amazon.com/Programming-Principles-Practice-Using-C/dp/0321543726
The C++ Programming Language, 4th Edition
http://www.amazon.com/The-Programming-Language-4th-Edition/dp/0321563840
-
Cawte.
Ucim sa c++. Mam nejake knihy, mam ho aj na skole(v skole to je slabota) a rozne zdroje na nete. Ale od zaciatku rozmyslam nad javou. Nedovolim si tvrdit ze som nejaky pokrocily v c++, stale uroven zaciatocnik si myslim.
Dostala sa mi do ruk kniha od pavla herouta...mam uz od neho jednu k C...a chcem sa opytat ci prejst na javu alebo pokracovat v C++...popripade zacat sa popri c++ ucit aj javu zaroven.
Dakujem za rady
The C++ Programming Language, 4th Edition
http://www.amazon.com/The-Programming-Language-4th-Edition/dp/0321563840
Programming: Principles and Practice Using C++
http://www.amazon.com/Programming-Principles-Practice-Using-C/dp/0321543726
-
C++ nemá interfacy a java nemá static_cast, takže nějak nerozumím, jak static_cast na interface udělat ;)
C++ má interfacy (http://stackoverflow.com/questions/318064/how-do-you-declare-an-interface-in-c), i když se jim tak ve standardu neříká.
Java dělá všude dynamic_cast, právě z tohoto důvodu.
-
C++ má interfacy (http://stackoverflow.com/questions/318064/how-do-you-declare-an-interface-in-c), i když se jim tak ve standardu neříká.
Java dělá všude dynamic_cast, právě z tohoto důvodu.
To, že se dají v C++ interface nějak udělat, ještě neznamená, že C++ má interface :). Co mi brání v C++ v nějaké třídě IInterface implementovat nějakou metodu? Vůbec nic, úplně v klidu se to přeloží, bude se to jmenovat interface, ale nebude to interface. Podporu interface si představuju tak, že mi překladač řekne "implementace metody do interface opravdu nepatří".
static_cast v javě chybí hlavně z toho důvodu, že to není typově bezpečné a tvůrci javy si řekly (asi zcela správně) "nebudeme dávat těm neschopným programátorům do ruky nic nebezpečného"
-
To, že se dají v C++ interface nějak udělat, ještě neznamená, že C++ má interface :). Co mi brání v C++ v nějaké třídě IInterface implementovat nějakou metodu? Vůbec nic, úplně v klidu se to přeloží, bude se to jmenovat interface, ale nebude to interface. Podporu interface si představuju tak, že mi překladač řekne "implementace metody do interface opravdu nepatří".
A je nějaký důvod, mimo jazykového fanatismu, proč by některé metody interface nemohly mít nějakou základní implementaci? Například sémantika nějaké metody je definovaná čistě pomocí jiných metod.
static_cast v javě chybí hlavně z toho důvodu, že to není typově bezpečné a tvůrci javy si řekly (asi zcela správně) "nebudeme dávat těm neschopným programátorům do ruky nic nebezpečného"
static_cast moc nebezpečný není. Naopak je to označení pro relativně bezpečná přetypování jako z potomka na předka. To může překladač zkontrolovat a nemusí se to ověřovat za běhu dynamic_castem. Asi si to pleteš s reinterpret_cast, který dovolí úplně všechno a z toho důvodu se používá docela málo.
BTW : Neschopný programátor je schopný zneužít nezneužitelné a zničit nezničitelné.
-
Jednou z nevýhod interface v C++ mohou být problémy s binární kompatibilitou. Už jenom přidání členské proměnné může být problém, a přidání virtuální metody může být nemožné - zvláště pak pokud zákazník nechce ani slyšet o tom, že by se všechny dll soubory měly přepsat, protože s tím má špatnou zkušenost, třeba proto že měl staré verze dll knihoven a s novými se mu dostanou i změny které nechtěl.
Ale dokonce i při absenci těchto problémů nabízí C++ veselé problémy. Třeba při vícenásobné dědičnosti pokud se někdo v potomku pokusí předefinovat metodu která nebyla přiděděna v base line (tudíž první děděná třída ve vícenásobné dědičnost, ta nejvíce vlevo) tak tím změní tabulku virtuálních metod potomka. Pokud něco z něj dědí, tak je třeba to všechno překompilovat, což mohou být desítky až stovky dll knihoven. Tohle se málo ví, že při použití vícenásobné dědičnosti je nejlepší všechny zděděné metody předefinovat aby byly v base-line a šly v potomku předefinovat.
AAA.DLL:
class IFace1{
virtual void method0() { }
virtual void method1() = 0;
};
class IFace2{
virtual void method2() = 0;
virtual void method3() {
}
};
class CBaseObject : public IFace1, public IFace 2 {
void method1() {}
void method2() {}
};
BBB.DLL
class MyReusableComponent : public CBaseObject {
// předefinovat method0 je ok, protože je v base-line hierarchie dědičnosti
virtual void method0() {
///....
}
// předefinování method3 po té co bylo zkompilováno AAA.DLL, BBB.DLL a CCC.DLL
// poruší tabulku virtuálních metod v CCC.DLL objektu MyObject, i když method3
// už byla definována v předkovi CBaseObject...
// souborů jako CCC.DLL je několik set a proces vyžaduje otestování celé oblasti
// závislé na daném DLL, tudíž retestování celé aplikace, a na takový testing nejsou prostředky...
//
// moudrý ten, kdo neopoměl přidat dummy metodu do base line... málokdo to zná
void method3 () { CBaseObject::method3(); }
};
CCC.DLL
class MyObject : public MyReusableComponent {
// ....
};
-
..ani v jave, ani v pythone, ani v ruby...vlastne, kde inde *je*?
Vícenásobná dědičnost je v Javě 8 (až tedy vyjde), Scale i Ruby. Diamond není problém, pokud se to navrhne dobře.
V Javě 8 to vyřešili jednoduše tak, že v interfacech stále nesmí být fieldy a v případě kolize metod je třeba explicitně říct, kterou ze zděděných implementací chci.
Scala má naproti tomu jasnou specifikaci pořadí přimixování traitů, takže trait díky tomu umí v podstatě všechno co abstraktní třída (fieldy, protected dědičnost), jenom mu chybí kontruktor.
V pripade Javy a Scaly (Ruby neznam) to ale neni vicenasobna dedicnost. wiki:Multiple inheritance is a feature of some object-oriented computer programming languages in which a class can inherit characteristics and features from more than one superclass.
Trait ani interface neni trida.
Alternate methods of object composition not based on inheritance such as mixins and traits have also been proposed to address the ambiguity.
Mixins encourage code reuse and avoid well-known pathologies associated with multiple inheritance.
In object-oriented programming languages, a mixin is a class which contains a combination of methods from other classes. How such combination is done depends on language, but it is not by inheritance.
-
..ani v jave, ani v pythone, ani v ruby...vlastne, kde inde *je*?
Vícenásobná dědičnost je v Javě 8 (až tedy vyjde), Scale i Ruby. Diamond není problém, pokud se to navrhne dobře.
V Javě 8 to vyřešili jednoduše tak, že v interfacech stále nesmí být fieldy a v případě kolize metod je třeba explicitně říct, kterou ze zděděných implementací chci.
Scala má naproti tomu jasnou specifikaci pořadí přimixování traitů, takže trait díky tomu umí v podstatě všechno co abstraktní třída (fieldy, protected dědičnost), jenom mu chybí kontruktor.
V pripade Javy a Scaly (Ruby neznam) to ale neni vicenasobna dedicnost. wiki:Multiple inheritance is a feature of some object-oriented computer programming languages in which a class can inherit characteristics and features from more than one superclass.
Trait ani interface neni trida ...
To je ale jenom slovíčkaření. "Vícenásobná dědičnost" nemusí nutně znamenat, že dědím z více tříd. Můžu mít třeba pouze vícenásobnou typovou dědičnost (= klasické javovské interfacy). Traity, mixiny a spol. sice nejsou plnohodnotné třídy, ale to v zásadě nevadí, protože přece dědím typ (u dynamického Ruby tedy ne) i implementaci. A to většinou fakt stačí.
Scala jde u traitů tak daleko, že opravdu to jsou téměř plnohodnotné abstraktní třídy, pouze bez konstruktoru. Lze v nich definovat fieldy, abstraktní metody, konkrétní metody, dokonce lze i vynutit, že třída implementující daný trait musí zároveň být podtypem třídy XY. V podstatě 90% abstraktních tříd lze nahradit traitem. Kupříkladu scalovské collection API (které je ještě rozsáhlejší než Javovské) je implementováno hromadou traitů a jenom pár abstraktními a konkrétními třídami. To že se trait formálně nedá nazvat třídou, je ve výsledku jedno.
-
A je nějaký důvod, mimo jazykového fanatismu, proč by některé metody interface nemohly mít nějakou základní implementaci? Například sémantika nějaké metody je definovaná čistě pomocí jiných metod.
Když to bude mít implementaci, tak už to není interface ;)
static_cast moc nebezpečný není.
#include <algorithm>
class Base
{
};
class DerivedInt : public Base
{
public:
void init()
{
a = 0;
}
private:
int a;
};
class DerivedArray : public Base
{
public:
void init()
{
std::fill(array, array + sizeof(array) / sizeof(char), 0);
}
private:
char array[65536];
};
int main()
{
Base* base = new DerivedInt;
DerivedArray* derived = static_cast<DerivedArray*>(base);
derived->init();
delete base;
return 0;
}
Ukázkový přepis paměti:
g++ -Wall main.cc
./a.out
*** glibc detected *** ./a.out: free(): invalid next size (fast): 0x0000000002194010 ***
======= Backtrace: =========
/lib/libc.so.6(+0x71e16)[0x7f359d27fe16]
/lib/libc.so.6(cfree+0x6c)[0x7f359d284b8c]
./a.out[0x40066a]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f359d22cc8d]
./a.out[0x400579]
Neúspěšně ukončen (SIGABRT)
-
..ani v jave, ani v pythone, ani v ruby...vlastne, kde inde *je*?
Vícenásobná dědičnost je v Javě 8 (až tedy vyjde), Scale i Ruby. Diamond není problém, pokud se to navrhne dobře.
V Javě 8 to vyřešili jednoduše tak, že v interfacech stále nesmí být fieldy a v případě kolize metod je třeba explicitně říct, kterou ze zděděných implementací chci.
Scala má naproti tomu jasnou specifikaci pořadí přimixování traitů, takže trait díky tomu umí v podstatě všechno co abstraktní třída (fieldy, protected dědičnost), jenom mu chybí kontruktor.
V pripade Javy a Scaly (Ruby neznam) to ale neni vicenasobna dedicnost. wiki:Multiple inheritance is a feature of some object-oriented computer programming languages in which a class can inherit characteristics and features from more than one superclass.
Trait ani interface neni trida ...
To je ale jenom slovíčkaření. "Vícenásobná dědičnost" nemusí nutně znamenat, že dědím z více tříd. Můžu mít třeba pouze vícenásobnou typovou dědičnost (= klasické javovské interfacy). Traity, mixiny a spol. sice nejsou plnohodnotné třídy, ale to v zásadě nevadí, protože přece dědím typ (u dynamického Ruby tedy ne) i implementaci. A to většinou fakt stačí.
To je o spravnem pouzivani pojmu. Interface, trait, mixin - ty vsechny vznikly jako alternativy k vicenasobne dedicnosti (nejbezneji pouzivane v kontextu s tridami). Nazyvat trait vicenasobnou dedicnosti, kdyz vznikl proto, aby naopak neprebral negativni rysy vicenasobne dedicnosti mi prijde divne. Motorce taky nerikame auto, prestoze resi stejny problem. Stejne tak se mi nelibi, ze Java bude mit "interface" s implementaci (ale neprekvapuje me to, je to podobne doprasene jako generika - proste za kazdou cenu zachovat zpetnou kompatibilitu, i za cenu nesmyslu ci neefektivity).
PS: Ja nerikam, ze nelze dosahnout stejnych/podobnych vysledku pomoci traitu/mixinu/interfacu (napr. traity [a s tim spojene mixiny] ze Scaly se mi velmi libi). Jen zduraznuji, ze interface, trait ani mixin nejsou vicenasobna dedicnost, prestoze vysledek muze byt ekvivaletni.
-
To je o spravnem pouzivani pojmu.
S tím souhlasím. Abyste pojmy mohl správně používat, tak musíte vědět, co znamenají. A to je kámen úrazu. Podívejte se třeba na článek o dědičnosti (http://en.wikipedia.org/wiki/Inheritance_%28object-oriented_programming%29) na Wikipedii. Jak je tam dědičnost definována? Nijak, je to jen takové tlachání okolo.
-
Když to bude mít implementaci, tak už to není interface ;)
Psal jsem mimo jazykového fanatismu. No nic... Aspoň Waseihou poslal rozumnou odpověď.
-
Vychazel jsem ze specifictejsich clanku - Mixin (http://en.wikipedia.org/wiki/Mixin) a Trait (http://en.wikipedia.org/wiki/Trait_%28computer_programming%29), tam je pomerne jasne receno, ze mixin nevznika dedenim (takze nemuze jit o vicenasobnou dedicnost) a trait je mnozina metod, ktera umoznuje znovupouzivani kodu bez vicenasobne dedicnosti.
Bohuzel je pravda, ze se to asi hodne casto nepresne pouziva (i primo na wiki nektere vety pusobi sporne). Napr. o Scale jsem videl hodne clanku, ktere popisuji jak implementovala vicenasobnou dedicnost. Pritom na ofic strankach maji jasne: "Classes are extended by subclassing and a flexible mixin-based composition mechanism as a clean replacement for multiple inheritance."
Když to bude mít implementaci, tak už to není interface ;)
Psal jsem mimo jazykového fanatismu. No nic... Aspoň Waseihou poslal rozumnou odpověď.
Kdyz muzeme mit interface s implementaci, tak proc nezacit pouzivat pro konstantu pojem promenna? Meli ten interface prejmenovat, takhle to bude hodne matouci.
-
Javu rozhodně ne.
C++ 0x11 a 0x14 http://en.wikipedia.org/wiki/C%2B%2B14 (http://en.wikipedia.org/wiki/C%2B%2B14).
Hlavně na začátku jazyk používat. Pak:
- pořádně, ale opravdu pořádně, se naučit STL a boost.
- Vykašlat se na ukazatele
- Naučit se stack unwinding
- Podívej se v jakém jazyku se dá psát pro iOS, Android, Windows, Linux, BSD.
- Nešťourat moc do šablon (používat ano, vytvářet minimálně).
- Naučit se RAII
-
C++ 0x11 a 0x14 http://en.wikipedia.org/wiki/C%2B%2B14 (http://en.wikipedia.org/wiki/C%2B%2B14).
Hlavně na začátku jazyk používat. Pak:
- pořádně, ale opravdu pořádně, se naučit STL a boost.
- Vykašlat se na ukazatele
- Naučit se stack unwinding
- Podívej se v jakém jazyku se dá psát pro iOS, Android, Windows, Linux, BSD.
- Nešťourat moc do šablon (používat ano, vytvářet minimálně).
- Naučit se RAII
Dobry napad! Ale narazi na fatalni prakticky problem - z ceho se to naucit? Ja mam doma Stroustrupa, 3. vydani (kde je skoro C++ 0x11) a STL od Josuttise. Presto pochybuji, ze tyhle 2 knizky uci vsechno, co popisujes.
Jakou knizku (nebo prinejmensim dobre napsany zdrojovy kod ke studiu) bys tedy doporucil, co tohle vsechno uci? Pochybuji, ze zacatecnik bude postupovat tak, ze si nejdriv precte specifikaci.. Stejne tak lze tezko ocekavat, ze bude nejakym zpusobem "syntetizovat" protichudne informace z vicero ucebnic (ruznych stylu).
Rad bych se mylil, ale obavam se, ze takto v soucasnosti neni mozne zacatecniky C++ ucit, protoze neni jak a kde. Myslim, ze lide zkratka nemaji dost zkusenosti na to napsat knihu pro zacatecniky v tomto stylu.
A pak taky prichazi otazka, pokud se nekdo tohle nauci, jestli bude opravdu "umet" C++. Bude schopen pouzivat Qt (coz povazuji za jednu ze zasadnich vyhod C++ ekosystemu)? Bude schopen pracovat na "legacy" C++ projektu?
-
Také si myslím, že nikdo neudělá chybu, když si dá epizodu třeba s čistým C a ASM na nějakém jednochipu. Zjistíte, jak funguje procesor a jak řešit problém s velmi omezenými zdroji.
To su len zbozne priania nedocenenych ludi, ktori sa ucili programovat v 80tych rokoch.
Moorovo pravidlo prestalo platit. S tim prijde i vetsi duraz na neco... ted je otazka na co. Jestli reziji JVM nebo algoritmu. Nebo se to bude resit hrubou silou jako doposud vse v komercni sfere. Tedy hrubou silou velkych poctu (ARM).
-
To je o spravnem pouzivani pojmu.
S tím souhlasím. Abyste pojmy mohl správně používat, tak musíte vědět, co znamenají. A to je kámen úrazu. Podívejte se třeba na článek o dědičnosti (http://en.wikipedia.org/wiki/Inheritance_%28object-oriented_programming%29) na Wikipedii. Jak je tam dědičnost definována? Nijak, je to jen takové tlachání okolo.
Kamen urazu je v tom, ze zaklad nazvoslovi vznikal v dobe, kdy kazdy programator vedel jak kompilator interne reprezentuje to co zrovna napise. A kazdy programator tak premyslel v podstate v C/ASM/Fortranu a spol. A dnes? Staci se podivat na vybrane casti velkych projektu treba kernelu. Je to v C, ale chova se to jako objektovy jazyk. A aby nedochazelo k nesmyslum v obfuskovanem a obcas i mezi vybranymi jazyky nekomatibilnim koliznim nazvoslovi, tak kazdy explicitne vidi jak to funguje. Tech 40 radek co by schoval kompilator do svych utrob a zavedl kvuli tomu 5 novych klicovych slov a 15 validnich vyrazovych spojeni do kterych je lze usporadat. Nez si projit timto obfuskacnim peklem, ktere hazi klacky pod nohy a pri kazde razantnejsi zmene prostredku prepisovat narazove kusy kodu jen pro overeni, ze jiny pristup bude fungovat lepe tak se vyuzije moznosti sahnout do obnazenych vnitrnosti, ktere nikdo neschovava. Ano je to reznicina, ale spickova.
-
Moorovo pravidlo prestalo platit.
Jsi si jisty? Existuji dva duvody, proc si ja jisty nejsem:
- Stale jsme se nedostali na uroven lidskeho mozku, co se tyce pomeru spotreby a vypocetniho vykonu nebo pameti. Samozrejme, mozek funguje dobre jen na neco, ale tohle stale znamena, ze je patrne jeste mozne inovovat pocitacovou architekturu (a neurony jsou v realu obrovske, ve srovnani s mikrocipy).
- http://www.youtube.com/watch?v=QGw-cy0ylCc (http://www.youtube.com/watch?v=QGw-cy0ylCc)
-
Moorovo pravidlo prestalo platit.
- Stale jsme se nedostali na uroven lidskeho mozku, co se tyce pomeru spotreby a vypocetniho vykonu nebo pameti. Samozrejme, mozek funguje dobre jen na neco, ale tohle stale znamena, ze je patrne jeste mozne inovovat pocitacovou architekturu
Kolik matic za sekundu dokaze tvuj mozek vynasobit tak, aby si je dokazal sdelit dal? Tim co naznacujes vpodstate kopes hrob IT jak ho zname. To co si predstavujes bude resit odlisne ulohy na jinych principech.
Moorov zakon uz hori na vzdalenosti kterou urazi elektron za takt. Staci se podivat co se deje s frekvenci. Uz je na maximu soucasnych materialu. Zachrani to na par let jen supravodice pri pokojove teplote.
http://commonsenseatheism.com/wp-content/uploads/2013/05/Moores-law.png
http://www.saphana.com/servlet/JiveServlet/showImage/38-1752-2298/Screen+Shot+2013-04-18+at+6.40.54+AM.png
Moorov zakon byl spojovan s odpovidajicim prinosem vykonu. I kdyz to neni primo to co rika, tak je tim co se od nej ocekava. Jenze tenhle vyklad uz delsi cas jen "podvadeji" pridanim dalsich jader. Jenze cela historie civilizace stoji a pada napric obory na transakcich. Vykon dostupny pro transakci za jednotku casu nam uz nejaky ten rok preslapuje na miste. Ano daji se dilci podukoly transkace paralelizovat, jenze pri sebelepsi snaze pokazde narazis na minimalni hierarchicky celek, ktery musi probehnout a pro ten zadny prinos par let uz nic znatelneho nebylo. Ted se jen pridavaji dalsi jadra - zvysuje stadni pristup k poctu podukolu na transakci. Kde jeste vykon roste dobre jsou nesynchronizovane/netransakcni ulohy - bud lockless struktury a algoritmy, ktere ovsem zahrnuji znacnou miru neefektivity a obcas i nejistoty a nebo zcela bezintegritni ukoly typu herni mmo servery nebo podpora stadniho pristupu cim vic ovecek tim vic baca hlavne, kdyz se ty ovce nesouperi o prostredky a pasou se hezky kazda na svym.
Se spotrebou co si zminil narazi na problem s preslechy sumu, kdyz se bude technologie blizit kvantovym energetickym minimum.
A alternativy?
Na frekvencni strop beztaktove procesory? Uz se v podstate pouziva ve forme vykonavani instrukci mimo poradi. Takt uz ma od te doby jen polovicni vypovidaci hodnotu o vykonu.
Na mezni vzdalenost sireni signalu? Uz se v podstate pouziva pyramidoveho vrstveni drobnych podukolu do jedne instrukce ktera pokryje cele funkcni bloky (MMX,SSE)
skoro se da rict, ze cele odvetvi ted ceka na supravodice pri pokojove teplote a doufat, ze licencovani ARM a Power proslape cesticku zcela nove instrukcni sade navrzene primo s cilem obelstit soucasne meze.
-
Moorov zakon uz hori na vzdalenosti kterou urazi elektron za takt.
Konec Moorova zákona se prorokuje už od dob Pentia II 266 MHz, že už to nikdy rychleji nepojede :P
Na frekvencni strop beztaktove procesory? Uz se v podstate pouziva ve forme vykonavani instrukci mimo poradi. Takt uz ma od te doby jen polovicni vypovidaci hodnotu o vykonu.
Out-of-order není nic o beztaktovitosti, vše funguje při starém, vše je řízeno hodinovým signálem tak jako vždycky.
Na mezni vzdalenost sireni signalu? Uz se v podstate pouziva pyramidoveho vrstveni drobnych podukolu do jedne instrukce ktera pokryje cele funkcni bloky (MMX,SSE)
MMX a SSE není nic o podúkolech, je to o paralením provádění jedné stejné operace nad několika sadami dat. Zatímco standardní instrukce zpracuje najednou až 3x32/3x64 bitů, tak MMX instrukce až 3x64 bitů, SSE instrukce až 3x128 bitů, AVX až 3x256 bitů.
licencovani ARM a Power proslape cesticku zcela nove instrukcni sade navrzene primo s cilem obelstit soucasne meze.
ARM a Power zcela jistě neprošlape cestičku k vyšším výkonům a to kvůli architektuře RISC, jež je zcela nevhodná pro dnešní o dva řády zaostávající paměti. Proto se i do ARMů z velké nouze přidávají VLIW instrukce známé z x86 světa.
-
Out-of-order není nic o beztaktovitosti, vše funguje při starém, vše je řízeno hodinovým signálem tak jako vždycky.
no tak podle detailu dole to neni syndrom jednookeho mezi slepymi, ale proste jen terminologicka cistota nazvoslovi.
nez vysvetlovat vyvoj od sekvencniho zpracovani co instrukce to takt, pres sekvencni zpracovani pul a vicetaktkovych instrukci az k nesekvencnimu zpracovani, ale sekvencnimu vstupu a prezentaci/vystupu ... nez tak zdlouhave, tak je lepsi pouzit zkratku toho kam se to cele riti a kde uz zpracovani vzhledem k taktu je dnes - jen volne zavisle.
MMX a SSE není nic o podúkolech, je to o paralením provádění jedné stejné operace nad několika sadami dat. Zatímco standardní instrukce zpracuje najednou až 3x32/3x64 bitů, tak MMX instrukce až 3x64 bitů, SSE instrukce až 3x128 bitů, AVX až 3x256 bitů.
opet stejny pripad. n-iterace nahrazena n-arni operaci. m n-arnich operaci nahrazenych m paralelismem... je to jen o tom kde jestli to chce clovek videt cele panorama vyvoje nebo utrzek nejakeho stavu a o tom slovickarit.
ARM a Power zcela jistě neprošlape cestičku k vyšším výkonům a to kvůli architektuře RISC, jež je zcela nevhodná pro dnešní o dva řády zaostávající paměti. Proto se i do ARMů z velké nouze přidávají VLIW instrukce známé z x86 světa.
Vystouchnuti x86 instrukcni sady z monopolniho postaveni zpracovani "dennich vypocetnich ukolu" urcite prinese nejaky vyvoj. Jen se momentalne u Intelu ceka az bude vetsina zakazniku zmenu zadata a zacne hlasovat penezi. Dokud hlasuji pro zpetnou kompatibilitu, tak neni dvakrat velky duvod jim servirovat neco noveho..
Jinak ano moorov zakon neni mrtev tam, kde ho doposud nikdo neprotlacoval. viz treba http://4.bp.blogspot.com/-98RZFDXSVqQ/Ti6vLM04j2I/AAAAAAAAFOI/VcfM-mQExbk/s1600/03.jpg
A spojenim uloh do APU jeste nejaky ten patek prezije. I kdyz to pro nemalou cast lidi bude znamenat jen dalsi "podraz" jak udrzet mrtvou legendu pri zivote.
A mezi tim se while, loop, repeat a sekvence kodu stane optimalizacne nejdrazsi cast. V prekladacich se treba dockame rozpoznavani paralelizovatelnych prechodovych stavu a rozeznavani mist, ktere slouzi jako bariera. http://helix.eecs.harvard.edu/index.php/DAC2012
-
Nelíbí se mi zavádění nových zmatečných pojmů jako "beztaktový procesor", které nadělají víc škody než užitku. Říkejme prostě třeba procesor řady Core i7. Laikovi to stačí a odborník ví.
Jen se momentalne u Intelu ceka az bude vetsina zakazniku zmenu zadata a zacne hlasovat penezi. Dokud hlasuji pro zpetnou kompatibilitu, tak neni dvakrat velky duvod jim servirovat neco noveho.
Na to Intel čeká od roku 1985. Intel chtěl x86 zlikvidovat společně s ukončením výroby 80286 a chtěl přejít na i860, ovšem zákazníci si vynutili pokračování x86 a tedy 80386. Druhý pokus byl u příležitosti přechodu na 64-bit v roce 2001 s Itaniem, ovšem zákazníci to opět odmítli a vynutili si x86_64. Na základě tohoto vývoje je jisté, že x86 tady bude ještě velmi dlouho.
A mezi tim se while, loop, repeat a sekvence kodu stane optimalizacne nejdrazsi cast. V prekladacich se treba dockame rozpoznavani paralelizovatelnych prechodovych stavu a rozeznavani mist, ktere slouzi jako bariera.
O tom se mluví od vzniku P4 s HT, ale zjistilo se že jen poměrně málo běžných úloh se dá paralelizovat byť ručně, natož strojově. Tedy na tomto poli nelze očekávat zázraky, jako že třeba Word se prožene über-kompilátorem a bude najednou využívat 16 jader na 100 %.
-
Nelíbí se mi zavádění nových zmatečných pojmů jako "beztaktový procesor", které nadělají víc škody než užitku. Říkejme prostě třeba procesor řady Core i7. Laikovi to stačí a odborník ví.
A bude trvat na tom zanedbatelnem casovem useku minulosti nedavne az pritomnosti a nepodiva se ani zpet ani dal do budoucna. a just ne.
-
Osobně do budoucna fandím C++ (a kompilovaným jazykům obecně) před Javou. Boom platformně nazávislých jazyků typu Java apod.
je totiž pouze dočasný jev daný chaosem v hardwaru a neskutečným množstvím výrobců. Nicméně výroba stovek různých druhů procesorů a systému, a chaos který přináší nebude trvat navždy. Časem nastane řád. Je to tvrdě konkurenční prostředí, dochází k monopolizaci a většina vychcípe a zůstane jen několik velkých hráčů. Ať se nám líbí nebo ne, nejsilnější zvítězí. A když těch platforem nebude tolik jako dnes, tak jazyky typu Java nebudou mít moc smysl protože výhody která mají už nebudou tak zástadní a zůstanou jejich nevýhody. Jejich úspěch je pouze dočasný daný historickými okolnostmi roztříštěnosti výroby hardwaru. Toliko můj názor.
-
Ať se nám líbí nebo ne, nejsilnější zvítězí.
A proto všichi budou programovat v javě :)
-
hlavne sa kazdy zakope na svojom poli a bude mu tam dobre, tak ako to je teraz.
v jave sa nezacnu pisat masove gui aplikacie prave tak ako sa v c++ nezacnu pisat velke enterprise riesenia
aj ked sa mozno dockame dalsich wtf dejinnych zvratov typu "java ako dominantny jazyk na smartfonoch" alebo "velky navrat objective-c" budeme programovat v haskelli alebo co.
-
A proto všichi budou programovat v javě :)
To se hlásá od roku 1995 a pořád to nenastalo a s krachem SUNu je jasné že už to ani nenastane.
Je také docela možný návrat k nativním aplikačkám, protože BFU hodně používají mobilní zařízení a jsou nas*aní z malé výdrže na akumulátory a nativní aplikačka je reálná možnost k delší výdrži.
-
Je také docela možný návrat k nativním aplikačkám, protože BFU hodně používají mobilní zařízení a jsou nas*aní z malé výdrže na akumulátory a nativní aplikačka je reálná možnost k delší výdrži.
sprostost ... radsej vyrobia silnejsiu baterku ako by sa mali zaoberat nejakymi nativnymi aplikaciami, nezaplatil by sa tym vyvoj
-
Odpověď je už v otázce – před 'nebo' není čárka – učit se je oba a klidně i nějaké další, i třeba neprogramovací, i třeba jen základy. Vyplatí se to, i když nakonec budeš používat něco úplně jiného.
A pokud jde o ty nativní aplikace, tak mně žere na Androidu nejvíc displej a data/WIFI, dále GPS a poslech hudby. Něco by se asi ušetřilo, ale je otázka kolik. Víc než deset procent? Těžko.
-
Osobně do budoucna fandím C++ (a kompilovaným jazykům obecně) před Javou. Boom platformně nazávislých jazyků typu Java apod.
je totiž pouze dočasný jev daný chaosem v hardwaru
1. Java je kompilovaný jazyk, výstup překladače je virtuální strojový kód. Narozdíl od interpretovaných jazyků není možno kód měnit za běhu, není zde eval jako v javascriptu.
2. Java není jen o abstrakci HW (a taky OS), ale i o pohodlí programátora (garbace collector, výjimky, hlídání indexů).
Osobně fandím C++, protože má lepší šablony, makra, přetížení operátorů a hlavně strukturované typy (java classy nepočítám). C struktury jsou rychlejší a v některých případech zjednodušují deserializaci externích dat.
Jinak platilo a bude platit C++ jako lowlevel pro výkonově náročnou část aplikace a Java pro rychlou a zpravidla jednoúčelovou implementaci zákazkového systému. Pro krabicový desktopový SW je určitě vhodnější C++ než Java. Java je vhodnější na serverové aplikace s nízkým nárokem na výkon.
-
1. Java je kompilovaný jazyk, výstup překladače je virtuální strojový kód. Narozdíl od interpretovaných jazyků není možno kód měnit za běhu, není zde eval jako v javascriptu.
Neni pravda, viz ASM nebo Javassist (sice jde spis o generovani nez zmenu kodu, ale vyjde to nastejno; navic mam pocit, ze existuji nejake oracle VM-specific metody jak vymenit i uz nactenou tridu - tj. menit kod za behu).
Osobne fandim JVM, tj. Jave a hlavne Scale.
-
je také docela možný návrat k nativním aplikačkám, protože BFU hodně používají mobilní zařízení a jsou nas*aní z malé výdrže na akumulátory a nativní aplikačka je reálná možnost k delší výdrži.
bfu sa naucia pchat mobil do nabijacky na vecer + iphonacky ios je omnoho viac pri zeleze nez java a nevyzera to tak, zeby zdominoval trh alebo zeby vydrz bola dramaticky lepsia + (vid x14) najviac zere displej, 3g modul, wifi
k tej zmene kodu za behu - na roote bezi serial o javassiste, tam sa daju robit krasne zveriny, oracle java ma hotswap, kde sa moze vymenit pocas behu kompletny kod metody triedy, a taky jrebel umoznuje cez vlastny vm agent za behu menit cele struktury tried (pridavat / odoberat metody, menit ich kod).
-
v jave sa nezacnu pisat masove gui aplikacie prave tak ako sa v c++ nezacnu pisat velke enterprise riesenia
pobavil si. a nebo jen slovickarime na "nezacnou".
tech systemu co se jim pocita zdrojak v radech 10mil radek c++ kodu tu je z obdobi 1980-2000 pomerne dost a nikam se nechystaji.
-
legacy kod by som tu nespominal, lebo niekto spomenie cobol a vypwni celu tuto temu za velkeho rehotu
o platforme vela hovoria nove projekty, lebo tie ukazuju cestu.
ale tym som chcel len povedat, ze kazdy z tych jazykov ma svoju primarnu domenu, kde mu je dobre a ocakavania, ze zrazu C++ vymrie alebo ze Java vymrie, alebo jedno nahradi druhe, su totalne mimo reality - ale rad uvidim priklady zo zivota
-
legacy kod by som tu nespominal, lebo niekto spomenie cobol ...za velkeho rehotu...
8)
Ano, znalost COBOLu ta moze posunut do ineho platoveho levelu ako sa da dosiahnut s C++ a Javou.