zamiana BCD na DEC w C++

Sławek5 · Postautor: **Sławek5** » 19 paź 2005, o 13:51

Macie może jakieś funkcjie do konwersji BCD na DEC dla liczb 8-bitowych w C.

Napisałem jedną ale przyznaję że nie jestem z niej zadowolony, a może macie lepszą.

Sławek.

a_antoniak · Postautor: **a_antoniak** » 19 paź 2005, o 14:39

dawno temu napisałem takie cuś (przetestowane):

Kod: Zaznacz cały

unsigned char Dec2bcd(unsigned char dec)
{
    unsigned char bcd;
    bcd=(dec/10)<<4;
    bcd+=dec%10;
    return bcd;
}

unsigned char Bcd2dec(unsigned char bcd)
{
    unsigned char dec;
    dec=10*(bcd>>4);
    dec+=bcd&0x0F;	
    return dec;
}

Teraz jestem mądrzejszy i napisałbym tak:

Kod: Zaznacz cały

unsigned char Dec2bcd(unsigned char dec)
{
    return (dec/10)<<4+dec%10;
}

unsigned char Bcd2dec(unsigned char bcd)
{
    return 10*(bcd>>4)+bcd&0x0F;
}

Sławek5 · Postautor: **Sławek5** » 19 paź 2005, o 18:51

Dzięki.
Co profesjonalista to profesjonalista. Daleko mi do tego.

Mi wyszłao nie jedna linijka tylko 8!!!

a_antoniak · Postautor: **a_antoniak** » 19 paź 2005, o 19:24

jak widać z czasem liczba linii kodu programu wykonującego okreslone zadanie spada

bis · Postautor: **bis** » 20 paź 2005, o 09:34

Ilość lini programu można jeszcze dalej "profesjonalnie"zmniejszyć zapisując kod obu funkcji w jednej linii. Jakość kodu wyrażana w liniach nie jest miarą profesjonalizmu. Sposób zapisu funkcji w "C" może mieć duży wpływ na ostateczną jakość kodu maszynowego powstającego po kompilacji kodu w "C". Tę jakość można definiować na różne sposoby. Może to być wymóg np. najmniejszej objętości albo największej szybkości. To już jest domena jakości optymalizatora kodu w kompilatorze. Nie ma jednej, "najlepszej", metody zapisu kodu w "C" tak aby wynik kompilacji był optymalny. W różnych kompilatorach stosowane są różne strategie optymalizacji. Silnie zależą one od zestawu możliwych kostrukcji w języku maszynowym docelowego procesora. "Krótki" zapis zaproponowany przez a_antoniaka jest jedną z metod pozwalających na zmiejszenie objętości kodu wynikowego dla prostych kompilatorów ze słabą optymalizacją. Na wielu kompilatorach kod wynikowy będzie identyczny dla obu zapisów, ale pierwszy zapis jest dużo CZYTELNIEJSZY.
Każdemu kto zaczyna programować polecam pisanie kodu CZYTELNEGO i samokomentujaącego się w możliwie najwyższym stopniu.
Optymalizacja jest następnym krokiem, ale wyłącznie na kodzie którego działanie zostało już dokładnie przetestowane.
Z czasem, poznając szczegóły działania danego kompilatora (tu pomaga oglądanie kodu w asemblerze produkowanego przez kompilator) nabiera się nawyku stosowania odpowiednich konstrukcji w "C" tak aby uzyskać najlepszy kod. Dotyczy to różnych aspektów kodowania. Może to być sposób zwracania wartości z funkcji, sposób przydzielania rejestrów do zmiennych, operacji na wskaźnikach, implementacji konstrukcji "swich()- case:" itd. itp. Temat rzeka po prostu.

a_antoniak · Postautor: **a_antoniak** » 20 paź 2005, o 16:54

Zasada jest prosta:
dobry programista - mało kodu, dużo treści
słaby programista - dużo kodu, mało treści.

Oczywiście jakośc kodu określa funkcja celu, którą mogą być różne rzeczy (np. objętość kodu skompilowanego itp.). Czytelnośc kodu jest zawsze jedną z najważniejszych funkcji celu. Ale mylisz się mówiąc, że pierwszy spośród zaproponowanych przeze mnie zapisów jest lepszy ze względu na czytelniość. Jest gorszy, no chyba, że ktoś ma kłopoty z wyobraźnią, ale to już jego problem. Dla tych którzy nie mają, zapis drugi jest czytelniejszy bo mniej rozwlekły.

Oczywiście prawdą jest, że nadmierne "upychanie" kodu zmniejsz czytelność w drugą stronę. Kod należy rozdzielać "na kawałki" ale przy rozsądnym poziomie atomizacji. To taka równowaga pomiędzy inteligencją analityczną a syntetyczną. Wyobraźmy sobie, że ktoś pisze duży program i każdą pierdółkę (jak np. konwersja BCD < - > DEC) rozwleka. Powstały kod będzie nieczytelny bo zbytnio rozwlekły. Jeśli ktoś przesadzi w drugą stronę to kod stanie się nieczyelny bo zbyt zwięzły.
Oczywiście można mieć różnie poglądy na "rozsądny poziom atomizacji". Z czase zaczyna to się po prostu czuć.

Przesadą jest np. to:

int x;
x=b;
x+=8;

bo każdy głupi zrozumie int x=b+8;

Przesadą w drugą stronę jest np.

int x =((a+b&0xAB)*3-5|4-(c|2>>3))*7-1;

bo jest zbytnio zwięzłe.

Sprawa druga: pisanie kodu pod konkretny kompilator celem zmniejszenia objetosci kodu po kompilacji jest obecnie w wiekszosci przypadkow bez sensu i moze prowadzic do zbytniego "przywiazania sie" do danego kompilatora. Moze to miec jedynie sens we fragmentach programu krytycznych szybkosciowo (jesli chcemy uniknac wstawek asm). Tak np. bylo w moim SLA.

zamiana BCD na DEC w C++

Kto jest online