C i C++ i dalje nemaju zamene.

Pascal mi je i dalje omiljen - jezik koji vas uci da pravilno razmisljate

Python

P.S. Nema smisla otvarati istu temu na vise foruma. Na ES postoji ova lepa opcija da vidis poruke u poslednjih nekoliko sati.

Lisp.

Pojam najkorisnijeg jezika zavisi od namene, a odgovor je uvek isti - C++.

C++ je nakjorisniji pre svega zbog najjačeg legacy-ja, naročito za zahtevne stvari.

Brzina je veća kada se radi u C-u, nego u asembleru, jer kompajler bolje optimizuje od čoveka. Asember ima smisla samo za delove nisu pokrivene C-om, kao što je iskorišćavanje mogućnosti novih skupova instrukcija.

Ima dugme "Build & Run", a čekanje na kompajliranje je značajno samo za veće programe.

Zašto? Zar ne može da bude html fajl sa JavaScript kodom u sebi i da se otvara brauzerom?

Ako imam instalirano C/C++ okruženje, može da mi bude brže to, nego da tražim po netu online kompajler.

Naravno, shell.

There is more Unix-nature in one line of shell script than there is in ten thousand lines of C

Naravno Prolog! Ma zezam se, PHP.

C brate, da ceo svet razume.

Depends whether You need to open the jar, see sharp, increment your efficiency of programming in C, or PerHaPs You want to change your application so often by making little adjustments that building and deployment would require too much hassle and time.

JavaScript može u html fajl. Pravio sam takve čačkalice.

Ako imam matrični štampač od pre 30+ godina, baciću ga i kupiti novi.

Ne mozes znati da li je odluka dobra ili losa stvar bez sire slike. Mozda ne da nije lupanje nego pametna poslovna odluka da se ne rade takve stvari.

Klijentu nekad ne samo da moras reci ne, nego nekad moras i prekinuti saradnju - ako zelje klijenta nisu strateski uravnate sa tvojom firmom ili ako se jednostavno ne isplate. Moze klijent biti spreman da plati sve to ali ako tvoja radna snaga moze raditi na necemu profitabilnijem od tih zahteva, dzaba im.

Posto nema sire slike moz’ bude bilo sta, pa je predlog za otkaz preuranjen a mozda i potpuno pogresan.

Pre bih se bojao za stolicu onoga ko donosi odluke naprasno bez minimuma neophodnih informacija.

Tačno! Koliko firmi (sw i hw) ne podržava Linux, a jedan broj korisnika kuka zbog toga? Imaju pravo da nešto nemaju u ponudi.

Bio tako jednom oglas: "Dva mladića, pouzdana kao Švajcarska, neuništiva kao nuklearni otpad, rade sve vrste poslova. Posao nije bitan, samo novac.". Ostavili su broj telefona. Takvi prihvataju "sve". Ostali, ne baš.

Blage veze ti nemas s kapitalizmom. Tacnije, nagledao si se suvise losih americkih filmova ... :-))) Mada, taj manir ponasanja je vise svojstven nasima nego Amerima.

U kapitalizmu firma je ta koja procenjuje da li joj se isplati da se aka s tehnologijom od pre 50 godina ili da taj posao ustupi drugome. A konsultant koji radi za tu firmu je taj koji MORA da klijentu saopsti to isto sto i Nedeljko. Doduse, ne bas tako brutalno, ali da mu objasni da ce ga odrzavanje stare tehnologije kostati iz godine u godinu sve vise. Da mu nacrta lep grafik porasta troskova tokom vremena i ubedi ga u to da obnovi malo svoj hardver. Da mu objasni da u jednom trenutku nece vise biti ni rezervnih delova za taj njegov hardver, cijim crkavanjem bi mu bila naneta ogromna steta u poslovanju.

Ako nema drugog resenja, tada je na firmi da odluci zeli li da udje u taj posao ili ne. Ako je u pitanju njihov dugogodisnji klijent od koga ce imati koristi u buducnosti tada ca uposliti nekog kontraktora od 70+ koji jos uvek moze da napravi softver za taj stampac, ako treba i u kobolu, makar morao da se izvrsava i na PDP-u. :-) Postoje ljudi koji to znaju. Samo, nisu jeftini. Ni kod stare babe ne moze za dzabe. Stavise,, takav razvoj bi klijenta kostao taman toliko da bi on na kraju ipak verovatno poslusao Nedeljka.

A sto se otkaza tice, radno mesto na kome se inzenjeru/programeru za iskazivanje misljenja daje otkaz na licu mesta bez prava zalbe je toksicno radno mesto ... i svaki cak i prosecan developer ce se na to samo slatko nasmejati, za nedelju dana ce naci mnogo bolji posao i zauvek zaboraviti te idiote. Mladji barem. A neki stariji lik kome bi tako uradili bi im doveo advokate i zapretio tuzbama za sve i svasta. ... Matorim radnicima bas zato retko daju nogu bez debelog paketa i potpisane izjave da nece ici na sud, oko cega se pregovara.

Kao sto rekoh, ne veruj svemu sto vidis na filmu. :-)

Ma, koja god da je lova u pitanju, nisi dužan da nudiš neku vrstu usluge. Ne baviš se time, nije ti u programu i to je to.

Naravno, to se u email-u napiše ovako:

E, da, mogu se klijentu predložiti neka rešenja, po mogućstvu koja ta firma nudi.

HasoMuka

Jeste, Bil Gejts se obogatio tako što je svakome izlazio u susret i nije imao svoje "ne".

Direktor će da primi zahtev i da ga razmotri sa svojima zaposlenima. Nakon toga će da odgovori klijentu.

Ukoliko je odgovor zaposlenog čudan, pitaće i ostale stručnjake za istu oblast na istom sastanku. Ako nema nikoga drugog za to, tražiće od zaposlenog da napiše mišljenje na papiru, pa će to da nosi nekom proverenom stručnjaku za oblast da se izjasni o tome.

Pitanje nije bas na mestu.

1. Programski jezici nisu sladoled pa probas vanilu, probas cokoladu, probas nesto trece i kazes koji ti se najvise svidja. Proces upoznavanje sa ukusima sladoleda traje 5-10 minuta.
Proces upoznavanja sa vise programskih jezika traje decenijama. Kada se pocne profesionalno raditi u jednom programskom jeziku vise se nema vremena za profesionalno usavrsavanje na drugim programskim jezicima jer posla ima preko glave.
Ne poznajem nekoga da je radio profesionalno u nekom jeziku i da je presao na neki drugi jezik isto tako profesinalno da radi. Za tako nesto je potrebno vreme, a programeri nemaju vremena.
Jedino ako neka firma veruje da ce brzo savladati programski jezik , recimo za godinu dana, i spremna je da ga placa dok ne nauci.
Mnogi malo opipaju druge programeske jezike ali se ne udubljuju.

2. Dolazimo i do primene. Sta je bolje, kamion ili auto? Ako ides da letujes na more onda je bolji auto, ali ako hoces da se preselis na more onda je bolji kamion.

3. Koji auto je bolji, mercedes ili BMW? Pa zavisi koji model gledas, koliko para imas, a tu pored ima jos puno puno licnog ukusa i afiniteta.

4. Ja sam se zaljubio u mercedes, stedeo godinama, analizirao potrosnju, odrzavanje, udobnost i 1000 drugih stvari i napokon kupim taj mercedes i ti dodjes i pitas me da li je bolji mercedes ili BMW.
Kolega je isto tako analizirao i hoce BMW i ti dodjes i postavis mu isto takvo pitanje.
Koji odgovor ocekujes?

Da postoji konkretan i dobar odgovor koji je programski jezik najbolji onda bi svi radili u tom najboljem i po istom kriterijumu svi bi ljudi vozili iste automobile, imali iste kuce, isto se oblacili.

I na kraju, ovo je takvo pecanje... Postavljen referral link da bi postavljac teme osvojio $1000 i bas ga briga kakve ce odgovore dobiti ovde.

Pa da, ali pitanje i nije koji je najbolji nego koji ti je omiljeni :)
No, slazem se da ce obicno ljudima biti omiljeni onaj u kojem najvise rade.

Abarth.

@HasoMuka,

Ako pricamo o softveru, imas mnogo poslovnih modela ali se sve to moze svrstati u sledece kategorije:

1. Rentiras radnu snagu --> u ovom slucaju klijent odredjuje sve, IP ostaje klijentu - ti si prakticno administrator (plate, HR, ...) i minimalni posrednik
2. Izradjujes projekte za kupce --> klijent i dalje odredjuje vecinu stvari, IP - zavisi kako kada, ti imas malo vecu kontrolu ali se i dalje klijent najvise pita
3. Licenciras tvoj softver klijantima --> klijent moze da zahteva promene/unapredjenja/adaptacije ali se to testira u odnosu na proizvodnu strategiju koja je tvoja (firmina) odgovornost - ti se pitas

Naravno ima "hibrida" kao i "lakih" i "teskih" varijanti svega ovoga (nisam racunao stvari tipa build-operate-transfer, da ne komplikujemo previse).

Pristup koji ti pominjes vazi za vecinu varijanti koje upadaju u #2 - u #1 se ti (firma) i ne pitas sta se radi.

Ako se radi o #3 - to ne da ne vazi, nego moze biti stetno.

Evo ti jednostavan primer - stara verzija tvog proizvoda je podrzavala matricne stampace.

Nova verzija prelazi na neki Cloud, raspisao si je u JS-u, Go-u stagod... UI je sada browser i... prc, nema stampanja na matricni (ili skeniranja sa nekog praistorijskog skenera, stagod).

Sta ces da radis?

Pa videces prvo ko je kupac koji trazi kompatibilnost, koliki je njegov udeo u profitu tvoje firme, koja je buducnost sa tim kupcem, koliki im je pain-point da promene resenje, da li ti konkurencija ima to, da nije mozda bolje da se fokusiras na druge kupce i... da li postoji neka alternativa, itd. itd..

Jako cesto ce se desiti da u sklopu firme tipa #3 moras da govoris "ne" kupcima. Na lep nacin, ono "hvala na predlogu - ali na zalost, trenutno nije na planu".

Ako to ne uradis, imas rizik da ti sopstveni proizvod bude zakocen i neodrziv. Ne mozes uciniti sve srecnim a tvoj posao je maksimizacija tvog profita pre svega.

Ivan Dimkovic


Firma se uglavnom pita i u #1. Kažeš mi da ti izorganizujem let na Mars, a ja to ne mogu ili se time ne bavim i šta onda? Onda ti lepo kažem da ja to ne mogu.

Ili posrednik sam, a klijent ima nerealna očekivanja od radne snage ili treba da plati za ispunjenje nekih uslova, koji su ispunjeni, a traži još za iste pare. Posrednik je onda nekakav sudija.

Prema tome, taj pristup koji HasoMuka pominje ne važi ni za #1, ni za #2.

OK, iz ugla narucioca usluge naravno - da, mozes da zakupis i otpustis bilo koga i insistiras da nekome ko ce da uradi tacno ono sto trazis.

@Nedeljko,

U slucaju organizacije posla po #1, firma nudi, recimo, "C++ programere" na kilo, i samo posreduje oko legalnih stvari i uzima %. U tom slucaju se narucilac pita sta hoce.

U tom slucaju ja kao kupac te necu pitati da mi organizujes let na Mars, nego da mi iznajmis XYZ inzenjera.

HasoMuka


Biće da tebi javascript/html nije jača strana. Html fajl može da sadrži i css i javascript. Pravio sam takve stvari po potrebi.

Ako ne želim da se bavim opremom od pre 30+ godina, za kloju ne samo da nema ni podrške ni rezervnih delova, nego ni repromaterijala za normalno korišćenje, to ne znači da meni javascript/html nije jača strana, nego da tebi logika nije jača strana.

Za mene oprema za koju je istekla podrška ne postoji. Najstarija verzija Windows-a koja za mene postoji je 8.1. Nemam ja ništa protiv da neko gaji XP ili sedmicu, sve dok ne krene da kuka i traži da se ceo svet okreće oko njega.

Takođe, hoćeš da se zanemari tvoje iznošenje netačnosti da se u kapitalizmu dobija momentalan otkaz za odbijanje klijenta? Hteo bi to da pravdaš nekom tvojom nadrilogikom.

Kao što i druga strana može da odbije naručioca, pa neka traži to negde drugde. To je takođe u redu i ne podrazumeva da je zahtev naručioca nerealan. Odbijanje može da ima sasvim druge razloge i da bude dobra odluka.

To je nešto nalik na freelancing sajtove, gde posrednik vrši ulogu sudije. Pitaju se obe strane - kako onaj koji nešto traži, tako i oni koji se nude da odgovore zahtevu, a posrednik je sudija.

Ako ti treba neka količina inženjera na kilo i obratio si se meni, a ja držim do ugleda i želim da imam bolju ponudu od svoje konkurencije, onda je to slično sa freelancing sajtovima.

Ako je baš matrični štampač, zašto bi kupovoa LX-350, kad LX-300 iz 90-ih još uvek radi bez problema? I nema tu nikakvog održavanja, ako se pokvari, baci se i kupi taj novi LX-300, jer je potreban ako klijent zahteva štampu na matričnom štampaču - recimo, tako se štampaju uplatnice, većina je prešla na elektronske uplate, ali možda neko još uvek štampa uplatnice na papiru i treba mu takav štampa.
Potom, postoji stari softver koji štampa samo na matričnim štampačima i koštalo bi mnogo više da se preradi tako da štampa na laseru ili inkdžetu. Ako je samo jedno mesto za štampu, nije problem.

Da je tek tako lako promeniti softver i način rada, ne bi onolika frka bila oko Y2k, jer su računari već duže vremena podržavali četvorocifrenu godinu, problem je bio softver koji je pisan tako da radi sa dvocifrenim godinama.

Ma, nemam ja ništa protiv da se time bavi ko hoće, samo je problem izjava da se u kapitalizmu dobija šutka ako nećeš.

I to - nije jednostavno.

Nije im jednostavno, jer imaju bazu podataka urađenu u kliperu ili VB 2.0 ili svejedno čemu, ali koju su naručili bez izvornog koda, jer zaboga "to im radi i nisu oni budale". I onda idu problemi sa migracijom.

Sad lepo čekaju da im to otkaže iz bilo kog razloga, a sve se haba, pa da jednom postane nemoguće.

Zašto, pa zato što ih nikad nije bilo briga za it rešenja. To su nekako otaljavali samo "da ima" i onda je sve problem.

Scenario br2: Nekada su naručili zajedno sa izvornim kodom, ali to "i dalje radi", pa čekaju da se to promeni, odnosno da prestane ra radi, tako da zbog otkaza opreme migracija podataka postane nemoguća, jer ih više neće biti. Dok "radi", problem je da se bilo šta preduzima.

I dobro, takvi su kakvi su. Da li sam ja dužan da se zezam sa tim? Jok vala. Ko hoće, samo napred.

Nece te tuziti, srecan je sto te je napustio i nasao normalno radno mesto. :-) A i ja sam ti dao otkaz i posao za njim, hahaha ... Cak sam i trubace doveo, vidi:




Niko ovde nije osporio da matricni stampaci imaju i dalje svoju ulogu. Stavise, jos uvek se izradjuju i imaju svoje musterije, cak i u normalnim zemljama u kojima su "uplatnice" odavno poslate na smetliste istorije. Recimo, matricnjake vidjam vrlo cesto po aerodromima, zato sto je npr. spiskom putnika koji se daje kabinskom osoblju mnogo lakse rukovati ako ga dobiju u vidu listinga, nego da se muce jos i sa nekim heftalicama. A isto tako, osoblju na pisti koje je lakse da dobije tehnicke check liste na perfo papiru nego da im se pogube papiri dok rade svoj posao.

Ja sam u ovoj diskusiji matricne stampace video kao metaforu za stare tehnologije za koje je cesto potreban dodatni razvoj. Da, sam matricni stampac se resava ne za 5, vec za jedan jedini minut. Cesto se i ne resava, vec drpis neki open source ili nesto gotovo sto radi, zbudzis ga sa vec postojecim, testiras i to je to. Isto vazi i za sve ostale periferije koje se kace na serijski ili paralelni port. To niko ne spori ovde.

Medjutim, postoje isto tako problemi koje se ne resavaju bas tako jednostavno i brzo i koje ne mogu da resi neke priuceni programeri, a bivsi pekari ili poslasticari Rajesh ili Ahmed. Primer - neki prastari slozeni softver koji radi na nekom mainframe-u (ili nekoliko slicnih sistema) i jos uvek nije "prepevan" na bilo sta modernije, a cija kompleksnost prevazilazi Rajeshovo i Ahmedovo znanje. Pa i tvoje i moje. :-) E tu vec moras da klijentu stavis do znanja da je odrzavanje te starudije rizicno za biznis i da ce ga to iz godine u godinu sve vise kostati.

Da nije mozda tacan odgovor na ovo pitanje:

"Zavisi .... od okolnosti, firme, oblasti, problema itd.... "

HasoMuka


Ne, posao još uvek imam. Otkaz nisam dobio. Možeš da ga uručiš samo nekome koga zapošljavaš, što ja nisam.

Čuj, neko će da plati 100 megadolara za it rešenje, a do sada nije prepravio to rešenje za mnogo manje pare.

Kada su se matrični štampači izbacivali, nekima su trebali zbog štampe preko indiga, da dobiju kopiju. To laseri, pljuckavci, kao i LED štampači (šta je to?) nisu mogli.

Međutim, uplatnice su odavno digitalizovane. Postoje digitalni potpisi i sertifikati. Za tim jednostavno nema realne potrebe, kao ni za AES kalkulatorima, ali eto... neko i to pravi



Koliko vidim, još uvek ima u Gigatronu i ComtradeShopu da se kupi matričnih štampača. Svi su epsonovi. Zašto ne bi bilo windows drajvera za njih? Da li su HP, Canon, Kyocera i ostali koji ih ne prave propali zbog toga što nemaju matrične štampače u ponudi?

@ssi,

https://www.elitesecurity.org/p4012696

Ali se prica nastavila dalje.

Linus Torvalds je rekao zašto C za sistemsko programiranje.

1. Sve što C++ nudi za sistemsko programiranje, nudi i C.
2. Ako je odbijanje budala sa projekta jedina korist od C-a, ta korist je dovoljna.

Od sporednih razloga

3. C se mnogo brže kompajlira.

Toliko o tome koliko je tebi programiranje "jača strana". Ti si od onih kojima se programiranje svodi na pozive funkcija i noso video ništa zaista kreativno.

Meni su generic(i) dosta bitni u svakom jeziku, a template klasa to omogucava u c++.

Evo sta je Bjarne Stroustrup uradio sa C++ jezikom kako bi bio upotrebljiv u programu vojnog aviona:

https://www.stroustrup.com/JSF-AV-rules.pdf (JOINT STRIKE FIGHTER AIR VEHICLE C++ CODING STANDARDS)

Ok, OS koji pokrece racunare mozda nije takvih zahteva, ali C++ definitivno nije najbolji izbor kada je najnizi sistemski softver u pitanju (firmware, OS, drajveri) i tu se potpuno slazem sa Linus-ovim komentarom.

Neki podskup C++-a bi radio posao svakako, ali onda se dolazi do kobnog pitanja: a koji podskup. Zbog toga je vise verovatno da ce pre neko napraviti novi sistemski jezik poput Rust-a (sto se i desilo) nego da padne neki dogovor oko C++.

C++ ima sve... ali to mu je upravo i najveca mana, zato sto ga dizajnira komitet koji se trudi da ugodi svakom. To je jako lepo za svakog od tih korisnika, ali je za pisce kompajlera horor na zemlji.

Zašto? Razumem zamerke poput onih da zahtevaju više vremena za kompajliranje, debagovanje je komplikovanije, ali mi nije jasno zašto ti se čini da su templejti "saranili programersku kreativnost". Ja baš mislim suprotno, da omogućavaju programeru da reši problem na kreativan način i izbegne dupliranje koda.

Ne, Ivane, nedostatci jezika C++ je što nije koherentan, nego mešavina raznih koncepata, koji nisu prirodno uklopljeni u njemu, kao i što je težak za učenje. Ako ima nešto što nekome ne treba, to nije nedostatak. Sekundaran nedostatak mu je sporo kompajliranje.

Vrline su mu je najjači legacy za zahtevne stvari i sloboda izražavanja koju nudi, upravo zbog toga što ima svašta.

C-ovska zamena za template je pretprocesor. Postoje parametarski makroi.

U cemu je problem da ovo uradis sa multi-linijskim makroom u C-u? Cak ne moras da kucas FORCE_INLINE :-)



Zavisi, ali cak i da nije, memcpy() implementacije danas imaju rani test i beg iz petlje za kratke nizove.

Sve dok je uzimanje i stavljanje u memoriju izvedeno uz pomoc SIMD instrukcija, ono malo ovehead-a oko petlje ne znaci nista (u momentu testiranja petlje se i ovako i onako ceka na memorijski sistem)

Nije samo sporo prevodjenje problem (ali jeste veliki) - vec i gomila stvari koje ne zelis u sistemskom softveru nizeg nivoa a koje su deo modernog C++-a.



Zasto bi to radio? Ako je sw. u C++-u tu ga i ostavi. Ako bas moras, nije nikakav problem sintetisati C kod iz C++ bez gubitaka performansi, ali sa losijem izgledom i jasnocom.

A neke drajvere ili drugi kernel-mode / bare-metal kod i ovako i onako neces pocinjati u C++



Niko se ne sali sa C++ kompajlerima. Ceo jezik je takva zver da samo kompajler mozda moze postati samo-svestan jednog dana.

Kao ruznu posledicu toga se jako cesto ima situacija u velikim projektima: kompajliranje koje traje celu vecnost i zauzima bog-te-pita-koliko RAM-a.



Nedostaci su sve to sto si naveo, ali i ono sto sam ja naveo - samo su bitni razlicitim grupama ljudi.

Uzmi automobilsku industriju, recimo, ovde je norma da se koristi AUTOSAR-ov MISRA standard za kritican kod - to je super-struktura pravila i eliminacija stvari iz C++-a koje smatraju opasnim.

To je dodatni trosak, neko je to morao da smisli prvo - pa onda natrenirati ljude, itd.

Mi pricamo o potpuno razlicitim stvarima.

Ti objasnjavas optimizacione mogucnosti C++ kompajlera dok ja objasnjavam probleme koji C++ cine neoptimalnim u sistemskom programiranju.

Te stvari nemaju veze jedna sa drugom osim nekih dodirnih tacaka.

To naravno mozes, ali sumnjam da neko dovodi u pitanje mogucnosti C++ kompajlera.

C++ ima kletvu da bi bio najbolji programski jezik, samo kada bi se resio legacy djubreta - problem je sto je to nemoguce + sto svakom neki deo legacy djubreta znaci puno.

Đubre nisu legacy C++ komponente/biblioteke/alati, nego prethodne verzije jezika C++, a pre toga i C sa kojim je trebalo održati kompatibilnost unazad. C je super sam za sebe, ali je C++ preko kompatibilnosti s njim nasledio koncepte koji nisu objektno orjentisani.

Rezultat je navedena nekoherentnost, koju ne treba zvati legacy đubretom, već balastom kompatibilnosti.

Legacy čine razne moćne biblioteke i alati, kakvi ponekad ne postoje za druge jezike. Po tome je izuzetno moćan.

Kome se ne sviđa takav nekoherentan C++, a može bez moćnog legacy-ja, ima D na raspolaganju.

Legacy djubre ili balast kompatibilnosti - svejedno, mislimo na mahom iste stvari (veliko preklapanje).

Ali nije samo nekoherentnost problem - evo samo jedan: Linus ga je pomenuo: sa C++ nikad nisi siguran sta se desava kad uradis neku npr. aritmeticku operaciju, zato sto je mozda operator overload-ovan i bog te pita sta se desava ispod haube.

U vecini slucajeva u userspace-u je ovo dobra stvar, kod je jasniji, manji, laksi za odrzavanje - ali u sistemskom domenu ovo moze biti gadna stvar.

Sto se D-a tice, rekao bih da je trenutno trend vise migracija ka Rust-u - mada sa tim stvarima se nikad ne zna kako ce izgledati u sledecih N godina.

Pa, u OO jezicima (u koje C ne spada) je poenta u tome da kada pozoveš neku metodu, da se poizdešava sve šta treba za to i da programiranje na taj način bude lakše.

D je nastao kao "ono što je C++ bez balasta kompatibilnosti trebao da bude", a ne kao inovativan jezik.

Rust je nastao kao inovativan jezik orjentisan prema "zero cost solutions".

Inače, tačno je da C program radi ono što je programer napisao, dok u jezicima višeg nivoa program radi svašta drugo što programer nije napisao, da bi bilo moguće ono što je programer napisao i da se preklapanjem operatora proizvodi efekat koji je Ivan naveo. Da li je taj efekat problem, zavisi od konteksta.

Neko pominjao templejte. :)

https://pbs.twimg.com/media/FB...md6R?format=png&name=large

Ne samo da postoji taj problem, nego njihovo korišćenje usporava C++ programe.

Ako se napravi kršten template, onda nema pada performansi, ali su bibliotečki sve samo ne to. Budženi za preširoku klasu slučajeva, pa dok se uđe da se proveri ovo o ono, odoše ciklusi.

ali u kapitalizmu je dobro sto on stalno propada i stalno se dize. Propao je do sada veec 20 puta i ljudi dobiju nekoliko puta otkaz ili im propadne firma i obet nadju drugi posao. Komunizam propao jednom zauvek i ljudi ostali u vecnoj komi: buhuuu 20 godina place kako mu je trnzicija unistila voljenu fabriku a mogao je 20 puta pokrenuti biznis.

ELEM...

ne znam koji mi je jezik najomiljeniji, ali mi je java totalno odvratna. Skarabudzotina samo takva. Osim sto ni HelloWorld nemozes napisati kako treba ima jos i taj JVM nterpreter me nervira.

u Americi uvek fali radnika i otkaz se uglavnom daje. Za vecinu poslova dovoljno je da znas basic Inglis i da dises.

Otkaz dobija uglavnom menadzment kad mu income statment ne bude dobar LALALALA

Da, ali ovde na forumu i na mnogo mesta imas situaciju da ljudi forsiraju npr. inline funkcije da bi dobili malo na brzini.
E' sad nisam "fluent" u c++, ako se dobro secam u toj situaciji parametri f-ije ce zavrsiti u main bloku umesto na stack-u i zar to nije rizicno za vece i kompleksnije funkcije sa "masnim" varijablama. U ostalom da je to ok, onda bi kompajler sve smestao u main blok.

Hocu da kazem da redosled ciljeva (uz naravno izuzetke) nije brzina na prvom mestu, vec robusnost, re-usability, citljivost pa onda brzina.

Ne, nije rizično nizakakve varijable. Međutim,


1. inline funkcija se implementira u zaglavlju, a ne u c/cpp fajlovima, što je nepodesno za pravljenje zatvorenih biblioteka, mada postoje rešenja za to.

2. Kada bi se sve pravilo kao inline, opteretila bi se zaglavlja u pogledu čitljivosti.

3. Dobi su beznačajni, osim za kratke, jednostavne funkcije.

4. exe će onda biti veći zbog redundanse u binarnom kodu.


Naravno, exe ne zna šta je to main. On zna samo za JMP, CALL, MOVE i slično. Niko te ne sprečava da sve implementiraš u main funkciji, ali je vrlo nepraktično, osim za vrlo male programe.

@Nedeljko
Da probam zarad teme:

Pod 1) i 2):
Ne znam da li je to profi praksa ili code standard da ide u h fajl, ali inline f-iju mozes da implementiras i u cpp fajlu.

Poda 3) i 4):
Da to mi je jasno.

Mene zanima sta se tacno desava u memoriji. Ono imamo code block, stack i heap(koji ovde nije tema).
U code block-u imamo main f-iju, a inline f-ija se inseruje u main putem kompajlera onoliko puta koliko ima poziva te inline f-je(ako razumem)

Eh sada ne znam da li se varijable tih inline f-ija smestaju kao globalne u kod bloku ili idu na stack kao segment main f-ije ili kao kod obicnih f-ija idu na stack kao normalna f-ija..

Kad smo vec u debeloj digresiji, secam se da sam davno citao u nekoj analizi americke ekonomije o nekakvom 'bankrot index-u' (ovo sklepao po secanju).
Otprilke, radi se o procentu novoosnovanih firmi koje bankrotiraju u prvoj godini, i valjda bese i u trecoj godini.
Navodno, visok 'bankrot index' je koristan, jer pokazuje da se resursi (kapital i ljudi) obrcu, odnosno nisu zarobljeni u neperspektivnim firmama i/ili projektima.

Onda neće biti vidljiva van tog cpp fajla.

Ne može prototip u h fajl, implementacija u cpp fajl, pa da se zaglavlje uključi u cpp fajlove u kojima treba, a da linker to posle poveže. U slučaju da nije inline, takvo razdvajanje je moguće. U C-u se umesto inline piše static. C++ isto dozvoljava da se za globalne funkcije piše static kao sinonim za inline.

_{[Ovu poruku je menjao Nedeljko dana 14.10.2021. u 12:17 GMT+1]}

Fajl lib.h


Fajl lib.cpp


Fajl a.cpp


Fajl b.cpp


U slučaju da je funkcija s(int) inline, fajla lib.cpp nema, a fajl lib.h glasi ovako:

C ekvivalent bi bio


ili



C++ rešenje je lepše i napisao ga je HasoMuka



Međutim, tu se stiže do problema o kojem je Linus govorio - na kraju ne znaš šta se zapravo poziva. Jeste to jednoznačno, ali ne mora uvek biti očigledno.