Kezdőoldal » Számítástechnika » Programozás » Miért van az, hogy egyesek...

Miért van az, hogy egyesek streamek helyett printf-et és scanf-et használnak C++-ban?

Figyelt kérdés

2020. aug. 27. 14:57
 1/7 anonim ***** válasza:
83%

Hát ennek elég sok oka lehet.

- valamilyen okból nem kapcsolhatják ki a C streamekkel való szinkronizációt (ez esetben lassabb lenne az iostream)

- nem tudják, hogy kikapcsolhatják a C streamekkel való szinkronizációt (ami által ugyanolyan gyors lenne az iostream, mint a printf/scanf)

- C-ről váltottak C++-ra és ezt szokták meg

- Adott inputot/outputot egyszerűbb/rövidebb printf/scanf-fel megvalósítani

- így tartja kedvük

- nem értenek a C++-hoz

stb.


Nehéz megmondani, ha nem tudjuk pontosan, hogy ki írta a kódot, milyen céllal, milyen környezetben stb.

2020. aug. 27. 15:10
Hasznos számodra ez a válasz?
 2/7 anonim ***** válasza:
Megszokták C-ben, és minek váltsanak másra, ha ez is tökéletesen működik? (Igen, tudom, az iostream rengeteg többletfunkcionalitással bír, de ha erre nincs szükség, akkor miért lenne "kötelező" használni?)
2020. aug. 27. 15:23
Hasznos számodra ez a válasz?
 3/7 anonim ***** válasza:

Emlékeim szerint a printf-et nem szereti a visual studio, helyette a printf_s-t javasolja.


Egyébként formázni sokkal egyszerűbb a printf-el, ezért használják cout helyett.

2020. aug. 27. 23:08
Hasznos számodra ez a válasz?
 4/7 anonim ***** válasza:

1. Lehetnek teljesítmény-okai; még ha az első válaszoló által írt szinkronizáció ki van kapcsolva, akkor is lassabb az iostreams. Persze általában nem ettől lesz egy program lassú, de emiatt sokan idegenkednek tőle. (Főleg aki pl. versenyprogramozásból jött.)


2. Az iostreams sok szempontból bonyolultabb, bizonyos formázásokat macerás megcsinálni, nehezen olvasható lesz a kód, sokan jobban szeretik a format stringeket


3. Lehetnek mindenféle technikai akadályai: az előző cégemnél pl. saját memory manager volt, ami felüldefiniálta a new/delete-et, és ez valahogy összeveszett a cin/couttal. (Stringstreamet pl. lehetett használni)


4. Plusz, ahogy korábban is írták, megszokás/lustaság.


Egyébként én se nagyon szeretem az iostreamset, bár a printf-nek is látom a hibáit - az {fmt}-t még nem próbáltam élesben, de valószínűleg az lesz az igazán frankó megoldás.

2020. szept. 6. 08:50
Hasznos számodra ez a válasz?
 5/7 anonim ***** válasza:

"még ha az első válaszoló által írt szinkronizáció ki van kapcsolva, akkor is lassabb az iostreams"


Van erről megbízhatóbb benchmark azoknál, amiket stackoverflow-n posztolgatnak? Mert ott egyáltalán nem lassabb az iostream, sőt, sok esetben gyorsabb.

Kompetitív programozásban is többen használnak iostream-et a top versenyzők közül, mint printf/scanf-et (tourist is pl., aki ugye jelenleg a legjobb kompetitív programozó a világon).

2020. szept. 6. 09:42
Hasznos számodra ez a válasz?
 6/7 anonim ***** válasza:

Nálunk a cégnél (az általunk célzott platformokra) készült ilyen benchmark, DE:

- nem nyilvános

- kb. 8 évvel ezelőtt készült

- már akkor sem a legmodernebbnek számító eszközökkel (hülye platformokra dolgozunk, volt, ahol pár éve sikerült elhagyni a VS2005-öt)

Szóval abszolút elképzelhetőnek tartom, hogy manapság már ne legyen igaz az állítás. Akkoriban egyértelmű különbség volt a két módszer között.


Régebben kompetitívek között sem volt jellemző a streamhasználat, de lehet, hogy ez változott - én már pár éve nem versenyzek aktívan, nem ismerem az aktuális trendeket.


Tudsz esetleg te mutatni benchmarkot, amiben a streams nyer? (kikapcsolt synckel)

2020. szept. 6. 09:58
Hasznos számodra ez a válasz?
 7/7 anonim ***** válasza:

Én csak azokat tudom, amiket Google kidob, pl.:

[link]

[link]

Ezért kérdeztem, hogy te tudsz-e valami megbízhatót, ami alapján kijelentetted, hogy lassabb az iostream.

2020. szept. 6. 10:24
Hasznos számodra ez a válasz?

Kapcsolódó kérdések:





Minden jog fenntartva © 2024, www.gyakorikerdesek.hu
GYIK | Szabályzat | Jogi nyilatkozat | Adatvédelem | Cookie beállítások | WebMinute Kft. | Facebook | Kapcsolat: info(kukac)gyakorikerdesek.hu

A weboldalon megjelenő anyagok nem minősülnek szerkesztői tartalomnak, előzetes ellenőrzésen nem esnek át, az üzemeltető véleményét nem tükrözik.
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!