printf() u C++ - svetogrđe?

Ovo je pomenuto u raspravi o razdvajanju C i C++ u posebne forume, pa nisam hteo da stvaram šum u toj temi, zato sam otvorio drugu.
Nisam dugo u svetu C/C++ programiranja (možda nekih 2,3 godine), tako da se nisam toliko obazirao na neke razlike u C i C++ programiranju. Mislio sam - ako mi je potreban objektni kod, to je C++, ako nije, onda je to C. Međutim, sada čitam neke stvari koje me pomalo čude, pa bih voleo da čujem neki dobar savet, da bih znao u kom smeru da se učim ispravnim radom u C++u.

Da li je zaista tolika greška korisiti printf(), char*, malloc u C++, ili je to samo pitanje nekog bontona i konvencije pisanja čistih C++ programa?
Meni je nekako uvek bilo zgodnije da koristim char* umesto stringa, lakše da koristim formatizovan input printf-a nego cin, itd. Da li je to greška, tj. da li se treba po svaku cenu prebaciti?

Potpis

ex. trooper
Oh goody... it's my Illudium PU-36 Explosive Space Modulator!
Softversko Inženjerstvo
♪♫♪

Da citiram B. Stroustrupa ("Design and Evolution of C++"):



Znači, kad smatraš da je bolje koristiti printf, malloc, char*, koristi ih i nemoj da te grize savest. Međutim, grehota bi bilo da ignorišeš moderne C++ tokove čisto iz navike ili tvrdoglavosti. Standardna biblioteka, kao i druge moderne C++ biblioteke (Boost i sl) umeju jako da olakšaju posao i moje ubeđenje je da jedino takav "modernizovani" C++ ima budućnost u razvoju aplikacija. Baratanje sa char*, pointer aritmetika i druge lepote C-a i dalje imaju svoju primenu u specifičnim okolnostima, ali u opštem slučaju mislim da ih ima smisla koristiti samo kad moderne varijante iz nekog razloga ne vrše posao ili ih je nemoguće primeniti (npr kernel-mode programiranje).

Potpis

IOCC

A sto mislis, da su C++ ucinili kompatibilnim s C samo tako, jer im je bila volja?
Naravno, da se ne prelazi na novi jezik, ali i C ima svoje prednosti.
Meni, osobno, vise se svidja printf jer mrzim manipulatore u cout.

Mislim da nije svetogrdje, ali ... Recimo, zasto bih ja koristio nizove u C++, ako mi vektori resavaju problem. A sta dobijam time: ne moram da razmisljam o dealokaciji (i alokaciji) memorije, smanjuje mi se mogucnost greske itd. Pogledaj http://www.elitesecurity.org/tema/73781

Program prvo treba da bude ispravan, pa tek onda brz.

IMHO nijedno programersko društvo ne kontrira principima dobrog softverskog inženjerstva više od C programera koji su bućnuli u C++ vode. Nikad neću shvatiti zašto bi neko, umesto da odradi stvar u dva reda kao u gornjoj poruci, pisao svoje rutine za učitavanje znakova, sagubio bar pola sata na trebljenje slučajnih grešaka i posle par meseci se iznenadio pošto je sasvim slučajno ugradio i buffer overrun bag u svoj program.

f

Inace , scanf i printf se koristi (bar na natjecanjima) jer se osjete razlike u vremenu ako imas dosta ucitavanja ...Npr kod ucitavanja ogromnih nizova i matrica...Pozdrav

Moj savjet ti je da sto je moguce vise postujes pravila igre, a to znaci ako pises programe u c-u onda koristi printf i dr., a kada pises programe u c++-u onda koristi cout i dr.

Medu prvim stvarima na predavanjima iz c++ je bilo da se sto prije rijesimo printfa i scanfa, i to je stvar na kojima bi gubio puno bodova na ispitu i to ne iz nekog hira profesora, vec zato sto je tako ispravno.

Ako krenemo od pretpostavke da je c++ nastao poslije c-a i to na nacin da su zadrzane sve stvari koje su dobre u c-u, a one koje nisu toliko dobre su poboljsanje, pritom direktno mislim i na printf i scanf.

Nema ispravno i neispravno. Prije ili poslije ces se iz C++-a morat linkat na neki C library u kojem neka funkcija u svom argumentu ocekuje FILE*. Onda hoces-neces moras koristiti C-ov stdio, pa fopen, printf, scanf i ekipu.. a posto je bezveze u istom programu mijesati dvije vrste I/O.. po inerciji ces napravit fallback na Cov stdio :)

Jos jedan razlog zasto mi se C++ streamovi ne svidjaju je to sto ne mozes znati sto je poslo po krivu. Mozes ti rec fstream i("nekifajl.txt"), ali recimo da to ne uspije. I ti nemas pojma zasto (a ima hrpa mogucih razloga - nema memorije, fajl ne postoji, nemas dozvole za pristupiti fajlu, dio patha nije direktorij... itd). U C-u razlog greske mozes procitati u errno globalnoj varijabli (i pokusati nesto drugo napraviti, javiti smislenu gresku korisniku itd..), a u C++-u se mozes slikat.


printf() i scanf() su funkcije koje odlicno sluze svojoj svrsi.

Jedan od razloga zasto se islo u dizajn C++ streamova je to sto se u compile-timeu ne mogu provjeriti da li se argumenti printfa i scanfa slazu sa formatom. Po meni je to bezveze razlog jer i C i C++ neukom programeru ionako nude bezbroj nacina da se upuca u nogu.

Drugi razlog je sto printf i scanf ne mozes prosirivati novim formatima. A ljudi su htjeli zapisivati objekte u fajlove (npr. ne mozes napisati fprintf(f, "%o", pointer_na_moj_objekt), a nekoga je bolilo kad je morao pisati fwrite() za svoje structove, a fprintf() za tekstualne podatke. Pa kad su vec overloadani operatori.. eto neka budu streamovi i << i >> za sve.

Kad sam vec kod ovoga - u C++-u je jako tesko mijesati binarne i tekstualne podatke u jednom fajlu. Jos ide kod pisanja, ali kod citanja...

E sad C++ streamovi su JAKO daleko od onoga sto bi bilo stvarno korisno, a to je serijalizacija objekata koju moras sam pisati i namuciti se ko pas da to napravis ispravno (ili uzet gotov library.. i vidjet kolko je to zapravo komplicirano).

Ukratko, ne vidim opravdanje za postojanje tog dijela C++ libraryja: kompliciraniji je i nudi manje mogucnosti za detekciju runtime gresaka.

Mozda nesto dobijes tek kad ides pisati svoje streambuf klase pa npr. imas on-the-fly kompresiju na streamu (ja napisao tako nesto).. ali imas C libraryja (npr. sfio) u kojima isto to mozes napraviti na puno jednostavniji nacin...

IMHO, C++ streams su jedan veliki promasaj.

Pa ajde ovako da kazem, nije sve sto je novije da je odma ujedno i bolje, pre svega printf je bio i ostao majka jer nema tako lakog i elegantnog nacina da formatiramo izlaz uz pomoc ios i njenih nasledjenih klasa, pa onda moras u pomoc da pozivas boost biblioteku i klasu format. Za neke stvari ios moze da posluzi ali kada je u pitanju teska masinerijia, prednost ide printf familiji funkcija.

Potpis

http://speedy-order.com

Hehehe, vidi se odmah ko je učio prvo C, pa onda prešao na C++. I ja sam bio u toj situaciji, pa vas razumem, mada je meni printf uvek bio nesimpatičan - podseća me na Fortran.

Nego, kažite vi meni koliko linija koda sa stdio bibliotekom treba da bi se postigla ova prosta stvar:



Da ne bude nesporazuma, nije unapred poznato kolika se dužina stringa očekuje.

Potpis

IOCC

Ali sta cemo kada nam treba brzina programa, a ne elegantnost koda? :)

Naravno, postoje situacije u kojima je kritično da UI bude maksimalno brz. Lično, u takvim slučajevima direktno koristim OS specifične funkcije, kao što je CreateFile na Windowsu, jer se tako dobija brži kod nego da se koristi C biblioteka.

U primeru koji sam dao, program čeka na korisnika da unese string i razlika u brzini između cin i scanf nema nikakav značaj.

Nego, ozbiljno, hoće li neko da proba da uradi u C-u one dve C++ linije? Ili da odmah dam rešenje?

Potpis

IOCC

Pa poznato je da je C brzi, a ti uvek mozes da se spustis na neki nizi nivo, nije u tome poenta ovde.

Pa u čemu je poenta po tvom mišljenju? Ja kažem da su iostream biblioteke najčešće bolji izbor od stdio biblioteka jer se kod lakše piše i čitljiviji je a i mogućnosti grešaka su manje. U situacijama kad je neophodno imati maksimalno brz UI, stdio opet nije optimalan izbor, već je često bolje ići direktno na API operativnog sistema.

Sve u svemu, ne koristim printf/scanf 5-6 godina i uopšte mi ne nedostaju. Jedini problem mi je bio da se otarasim stare navike u početku, i upravo to je suština primedbi na streamove koje vidim ovde.

Potpis

IOCC

@Dragi Tata - nije potrebno mnogo linija koda:

Kada brzina nije presudan faktor privremeni fajlovi se mogu koristiti u date svrhe. U ovom slucaju koristimo privremeni fajl zbog osobine "rastegljivosti". Prikazan kod demonstrira idejno resenje. Resenje primenjivo u praksi iziskuje dodatna poboljsanja.

Potpis

O_o

Ajde ti reci koliko je linija koda potrebno sa iostreamovima za sljedece:



Slozit cu se, kod formatiranog IZLAZA su stdio i iostreams koliko-toliko ravnopravni ako gledas prakticnost koristenja. Za parsiranje ulaza, iostreamovi imaju prednost.

E sad za tvoj konkretan primjer: rijetko kad mi tako sto treba u praksi, a ako mi bas to zatreba skinuo bih i kompajlirao SFIO:

http://www.research.att.com/sw/tools/sfio/

portabilan je, napredniji od stdio (mozes stavljati ulazno/izlazne discipline u layerima i isto tako imati npr. on-the-fly kompresiju i sl.), imas direktan pristup ulaznom bufferu od datoteke, automatski radi mmap() fajla u memoriju ako zna kako na danoj platformi.. i ne bih se vise patio sa stdio nego bih koristio sve mogucnosti SFIO. Eh da, odgovor na tvoje pitanje uz SFIO:

Svaka cast na rjesenju - zbog ideje temp fajla. fajl koji generira tmpfile() se automatski obrise kad ga zatvoris ili program zavrsi pa je to jako prakticno. Uvijek sam tu stvar rjesavao sa realloc() itd.. ali ovo je puno elegantnije rjesenje.

@blaza

Stvarno duhovito rešenje, ali pošteno kaži da li uopšte ima smisla porediti ga sa one dve linije koda koje sam dao? Kolika je mogućnost da napraviš grešku, kolika je čitljivost takvog koda?

@zvrba

Nije ti u praksi potrebno da uneseš string proizvoljne dužine iz nekog toka u memoriju, ali ti je u praksi potrebno da radiš sscanf(whatever, "%13[0-9]%d%64[a-zA-Z]", buf1, &i, buf2) ? Čime se ti baviš u stvari?

Uglavnom, nemam nameru da dozvolim C vs C++ ratove u ovom forumu. Ko želi takvu raspravu neka izvoli na Advocacy.

Potpis

IOCC