Żeby dopowiedziec i zakończyć odnogę wątku nt języków i standardów.
albertb napisał:
Doświadczony programista przy kodzie o wielkości mieszczącej się na Atmega8? Hmm.
Coś sugerujesz, co można odczytywać na wiele sposobów.
Że doświadczony programista nie będzie się zajmował A8? A dlaczego? Że uP nie warto oprogramować porządnie (izolacja kodu, moduły współużywalne, założenia prowadzenia kodu, tu sprzęt, tam logika, etc etc)? Zapewniam Cię, że można i warto. Do flasha się zmieści kilka tysięcy linii, zdecydowanie warto to dobrze zorganizować. Argument
"milion much nie może się mylić"*), niestety mnie nie bierze.
nawet jeśli to
C z klasami, czemu nie
GrzegorzKostka napisał: JacekCz napisał:
poddaję pod medytację cztery literki itoa
Te literki, które poddałeś pod medytację nie są nawet częścią standardu. Odnośnie samej funkcji sprintf to istnieją różne implementacje. Najmniejsza zużywa mniej niż 1kB kodu na avr. Jeśli chodzi o wydajność to również jest całkiem nieźle i do 90% zastosowań (nawet ma MCU) ta funkcja jest wystarczająco wydajna. Naprawdę nie wiem o co Ci chodzi. Nikomu tej funkcji nie polecam jak pisze na ATiny albo Atmege8. Jeżeli już się ma do dyspozycji np 32kB FLASH to zawsze można rozważyć użycie tej funkcji.
Widzisz ... powołujesz się na (dla mnie nieco mityczne) standardy C, że nie przywołują itoa() po czym wspominasz o niestandardowych podmiankach funkcji standardowej, co w ogóle z filozofią programowania wg standardów nie ma wiele wspólnego (głęboka zmiana semantyki funkcji). Nie neguję, w realnym programowaniu jest to OK, sam to z rzadka robię, ale nie łączmy tego w jednym zdaniu z szacunkiem dla standardu. To jest jak z zasadami "trzeba je znać by czasem łamać"
Nieliczni teoretycy programowania C emocjonują się kolejnymi standardami, podczas gdy cały tzw przemysł myśli
"de facto standardami". Jeśli dwa kompilatory używane przez zespół (i trzeci który mógłby być używany) mają jakiś wspólny feature, to jest ważniejsze niż pińcet standardów.
Takie są realia, C/C++ zawsze miało problem ze standaryzacją, genialnym (naprawdę) facetom w kraciastych koszulach nigdy nie udało się zrozumieć co i jak a propos standardów chce tzw przemysł. Dawno temu odpowiedział mi ktoś ważny
"dlaczego standard C++ nie ma typu numerycznego do obliczeń biznesowych" -
"bo nie chcieliśmy programiście zabierać wolności" . To jest właśnie ten tok myślenia. Zasadniczo świat C++ nie umie wypromować, wymusić standardu, historycznie i obecnie (typ String w arduino). "Nasz string" szybszy o ileś nanosekund
(autentyczna wypowiedź członka zespołu znanego parsera C++) od std::string - a że na współpracy bibliotek trzeba to przepakować tracąc RAM i milisekundy? Chore, popełnione przez wykonawców, ale ja za to winię standaryzatorów C/C++
Słabość standaryzacyjna C/C++ jest jednym z powodów zmniejszania się roli języka. Na mojej "liście chwały" najwyższe miejsce za standaryzację zajmuje Java, liczne w pełni kompatybilne, w pełni niezależne implementacje.
Akurat itoa() jest wspaniałą funkcją "de facto standardu"
dziwnym trafem dokumentują ją uniwersalne podręczniki C. Równoważniki mają Pascal, Arduino i wszystkie podobne środowiska
GrzegorzKostka napisał:
...sprintf...
Zanim zaczniesz pisać tego typu bzdury to otwórz sobie przykładowo źródła avr-libc albo newlib i obejrzyj sobie implementację tej funkcji. Jeżeli umiesz to lepiej zrobić to wrzuć tutaj kod, który będzie lepszy i będzie miał co najmniej taką samą funkcjonalność.
Dziękuję za "bzdurę".
Wiesz, funkcje z grupy va_args to ja modyfikowałem (kastrowałem) czy pisałem od zera, jak wielu z tu obecnych nie było na świecie, wyciskając z tego bajty. Mam o tym "lekkie pojęcie". Założenia choć na pececie (von Neumann) były w zasadzie podobne do Atmegi (harward): ostre limity RAM, absolutnie kontrolowane zużycie stosu, praca w przerwaniach itd
Aha. Tak przy okazji, oprócz zużycia stosu poza świadomością programisty, które mi się przypomniało, sprintf & Co nie jest typesafe, dodatkowy argument aby tego nie promować. Zgodzę się, statystyka popełnionych błędów w aplikacjach nie jest tak tragiczna (defaultowe zachowania typów czasem bronią przed strzeleniem w stopę) jak w sscanf (fatalnie!!!) ale i tak są, można sobie conieco postrzelić. "Nieszczęsne" itoa() jest bezpieczne co do typów.
*) złota czcionka z sąsiedniego wątku, rzecz pochodzi nie od elektrodowicza, a z noty kontrolera: #define uint unsigned int