Függvény visszatérési értéke legyen változó, vagy inkább képlet?
Stabilabb a kód, ha a változó kerül a return után? Gyorsabban fut le? Változó futásidőket mutat, mindkettőnél 11 és 15 ezredmásodperc között.
float valtozo1(float a, float b)
{
return sqrt(pow(a,2) + pow(b,2));
}
float valtozo2(float a, float b)
{
float e = sqrt(pow(a,2) + pow(b,2));
return e;
}
int main()
{
float a;
float b;
cout << valtozo1(a, b);
return 0;
}
Szebb, ha a változót adod vissza. Sebességbeli különbség nem szabadna, hogy legyen.
Különben szerencséd van, mert van float overload az sqrt() függvényre, de ha a C90 korát élnénk most, ott még csak double-t tudott visszaadni. Már csak ezért is érdemes explicit változót adni rá, mert nem biztos, hogy olyan adattípust kapsz vissza, amilyet szeretnél.
Sebességbeli különbség lesz? Valószínűleg igen, mert létrehozol egy új változót. Viszont ez a sebességkülönbség egyáltalán nem számít, és soha ne próbáld az átláthatóság rovására "gyorsítani" így a kódot. A számítógép meg se fogja érezni még azt se, ha 1 milliószor játszod el ezt egy programon belül és egyszerre lefut az összes.
Persze biztos vannak sebességkritikus hardwarekhez sebességkritikus szoftverek, ahol az ilyen trükközgetésnek lehet értelme, de nem hiszem hogy ez lenne a célod, és biztos, hogy nem tartasz még ott.
Hogy melyik szebb? Igazából mindegy, amelyik neked jobban tetszik. Persze nem szép dolog egy 10 soros számítást returnölni, ilyenkor mindenképpen átláthatóbb, ha felbontod, sőt ilyenkor érdemesebb, ha több függvényre szeded szét ha lehet. Ilyen rövid számításnál viszont mindegy, nyugodtan returnöld a képletet.
A típus nem fog változni, és talán ez verte ki nálam az elsőnél a biztosítékot a legjobban. Nem véletlenül van a visszatérési érték float típusra állítva.
Csináltam egy gyors tesztet, habár kotlinban. Változókat hoztam létre és tettem bele egy listába.
100 ezer és 1 millió változó között én nem éreztem semmi különbséget sebességben, kevesebb, mint 1 másodperc alatt lefutott. Ez nem azt jelenti, hogy nincs különbség, de a cél az, hogy a felhasználó belátható időn belül megkapja az eredményt úgy, hogy ne érezzen lassulást.
10 millió változó létrehozása és a tömbbe rakásáért már várnom kellett 3-4 másodpercet.
Na most te 1 változót hoztál létre.
g++ már -O1 optimalizációs szinttől ugyanarra az assembly kódra fordítja a két lehetséges kódot ("g++ -O1 -S"-el), és feltehetően minden más kompetens fordító így tenne, tehát teljesítménybeli különbség nem lesz. Továbbá remélem nem úgy tesztelted le, hogy egyszer lefuttattad, mert ilyen apró kódokat, mint felettem is írták, amúgy is milliónyi iteráció lefuttatásával lehet csak mérni.
Tehát mivel sebességbeli eltérés nem lehetséges, így csak attól függ, mi az olvashatóbb. Nekem személy szerint ilyen rövid "képletnél" csak felesleges sor a változó deklarálása, hosszabb kódot persze már több sorba érdemes/kéne írni.
"Nem véletlenül van a visszatérési érték float típusra állítva."
Hol? Ha az sqrt() egész számot adna vissza, akkor b.ja a float-ot, mert a tizedesrésze elveszik. Én erre gondoltam.
ma 15:35
Bármire is gondoltál verd ki a fejedből.
Mit verjek ki a fejemből? Az sqrt csak azért tud visszaadni float értéket, mert overloadban benne van ez is (C++98 verziótól):
Ugyanitt láthatod azt is, hogy ha float-ot akartál a számítás végére, akkor régebben (C99 alatt) még az sqrtf()-et kellett használnod helyette, annál is régebben csak double értéket tudott visszaadni.
Klasszikus példa, amikor a kezdő programozó char-t akarna, de stringet visszaadó függvényt használ rá és utána elkezdi össze-vissza konvertálgatni. Ez pontosan ugyanaz a helyzet, csak float vs double.
És egyébként sebességkülönbség nem lesz az új változó bevezetése miatt, nem akkora, hogy ki fogod tudni mérni, nyugodtan próbáld ki.
off
"vagy inkább képlet"
Csak kis pontosítás: Azt kifejezésnek szokták mondani. (expression)
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
Ha kifogással szeretne élni valamely tartalommal kapcsolatban, kérjük jelezze e-mailes elérhetőségünkön!