Sposób na lepszy przelicznik temperatur

Cześć macie pomysł na jakiś lepiej zoptymalizowany/bardziej odporny na błędy przelicznik temperatur?

using namespace std;
double celcjusze_na_faranhajty (double);
int main()
{

    double celcjusze ;

    cout << "Podaj stopnie Celcjusza do zamiany w Fahrenhaity: " ;
    cin>> celcjusze;
    
    
    double fahrenheit = celcjusze_na_faranhajty (celcjusze);
    cout<<"Zamienione temperatury:"<<celcjusze<<" stopnie Celsjusza = "<<fahrenheit<<" stopnie Farhrenheita";
    return 0;
}

double celcjusze_na_faranhajty (double sts)

{

return 1.8*sts+32;
}

Ale co ty tu chcesz optymalizować? Zależność jest liniowa i nic nie wymyślisz. Możesz co najwyżej stablicować wyniki, ale dla zależności liniowej to raczej nie ma sensu.
czy ktoś ci zarzucił że ten kod jest nieoptymalny czy żle zrobiony?

Jakie błędy chcesz naprawić, lub optymalizacje czego chcesz zrobić?

EDIT Jedyna oczywista rzecz jaka mi przychodzi do głowy to walidacja wejścia. Ile będzie wynosił Twój wejściowy double jeśli wpiszesz "mama" zamiast "15.5"?

1. Stopnie Celsjusza.
2. Stopnie Fahrenheita.
3. Jeśli chcesz maksymalnie uniknąć błędów w obliczeniach, to użyj typu bardzie dokładnego, niż double.

Spine napisał(a):

3. Jeśli chcesz maksymalnie uniknąć błędów w obliczeniach, to użyj typu bardzie dokładnego, niż double.

To nie ma sensu, dokładność double jest o rzędy wielkości większa niż przyrządów, którymi mierzymy temperatury.

Jedyne co widzę, co może być potencjalnie błędogenne, to to, że fundamentalnie i stopnie Celsjusza, i stopnie Fahrenheita, to u Ciebie double, więc kompilator się nawet nie zająknie, gdy dodasz jedne do drugich — albo nawet pomnożysz czy podzielisz.

Możesz tego uniknąć, robiąc własne klasy do tych dwóch typów, i odpowiednio przeciążając wybrane operatory. Możesz też dzięki temu zrobić limit na minimalną temperaturę, żeby nie dało się wpisać nonsensownych wartości, takich jak -1000.0 °C.

Ponadto, C++11 udostępnia definiowane przez programistę sufiksy, co pozwala pisać kod na modłę auto temp_c = 15_C; auto temp_f = 59_F; Trochę sztuka dla sztuki w typowych zastosowaniach, ale… można.

Może od razu uniwersalnie, z każdej na każdą?

#include <iostream>
#include <cctype>
using namespace std;

const struct { char code; double add,div; } Recalc[]=
{
	{'C',0,1},
	{'K',273.15,1},
	{'F',-32,1.8},
};

double recalcFrom(int index,double value) { return (value+Recalc[index].add)/Recalc[index].div; }
double recalcTo(int index,double value) { return value*Recalc[index].div-Recalc[index].add; }
double recalcFromTo(int from,int to,double value) { return recalcTo(to,recalcFrom(from,value)); }
int indexOf(char code)
{
	for(int i=0;i<sizeof(Recalc)/sizeof(*Recalc);++i) if(code==Recalc[i].code) return i;
	return -1;
}

int main()
{
	while(true)
	{
		cout<<"Podaj wartosc do przeliczania (0K C - przeliczy 0 kelwina, na celsiusze): ";
		double value;
		char from,to;
		cin>>value>>from>>to;
		int ifrom,ito;
		if((ifrom=indexOf(toupper(from)))<0) cout<<"Nieznana jednostka zrodlowa"<<endl;
		else if((ito=indexOf(toupper(to)))<0) cout<<"Nieznana jednostka docelowa"<<endl;
		else cout<<value<<from<<" = "<<recalcFromTo(ifrom,ito,value)<<to<<endl;
	}
}

Pasuje dla każdych liniowych przeliczników np długości: metry, futy, cale, itp

Jeśli chodzi o odporność na błędy to nie wiem czy w c++ się takie coś praktykuje ale czasem (zawsze?) zgodnie z DDD i 9 zasadami Object Calisthenics dobrze jest obudować typ prosty typu double konkretnym typem np Fahrenheit / Celsius. Obecnie obie wartości przechowujesz w typie "double", powiedzmy że to duża aplikacja oparta w dużej mierze o temperatury, pochodzące z różnych źródeł w różnych skalach i masz funkcję która przyjmuje double stopnie albo masz taką zmienną. W jakiej skali są te stopnie? Czy trzeba je przeliczyć czy są już przeliczone? Mógłbyś zawrzeć taką informację w nazwie zmiennej ale to nadal błędogenne - nie masz gwarancji że gdzieś dalej w kodzie temperatura stopnieFahrenheita nie zostanie przypadkowo przekazana do funkcji która wymaga stopnieCelsiusza. Osobne typy wymuszą na programiście poprawną obsługę na etapie kompilacji.
Oczywiście w tak prostej aplikacji jak powyżej to nie ma zbytnio sensu

https://wandbox.org/permlink/bSVuCXksPKBfjN97