ord napisał(a):
W embedded unika się alokacji dynamicznej jak ognia, a już szczególnie realloc zwiększającej obszar. Można to uznać za błąd i to kardynalny.
A co to za jakieś teorie spiskowe - używa się używa i to każdej funkcji i do alokacji i do realokacji - tylko jak wszystko w C zawsze trzeba "z głową" i pamiętać o odpowiednim zwalnianiu. Więc to jest totalnie zła porada i podpowiedź.
------------------------ [ Dodano po: 8 minutach ]MarekSz napisał(a):
Intencją było to, abyśmy nie skupiali się, jakie pola zawiera ww struktura lecz tylko jak ładniej zapisać dostęp do jej pól.
Ty masz intencje a innym robisz zagadki, już w ramach takiego typu złożonego możesz popełnić babole, więc dalsza szczegółowa analiza reszty kodu pod tym względem szczególnie z alokacją i realokacją nie ma sensu kompletnie
MarekSz napisał(a):
Czy mógłbyś przybliżyć temat? Zamiast uint8_t używam unsigned char ponieważ środowisko IDE jakiego używam podpowiada mi te typy (Microchip Studio), a uint... muszę z palca zawsze wpisywać. Czy uint8_t nie odpowiada unsigned char? Zaglądałem do stdint.h i tam znalazłem:
To daj sobie spokój z tym MEGA KOCIM tragicznym środowiskiem, które zostało totalnie bezlitośnie przerobione i to na wariackich papierach pod procki atmelowskie AVR z AVR GCC - to jest kolejny etap szaleństwa - właśnie te podpowiedzi unsigned char - ale jak chcesz to oczywiście się męcz - kto ci zabroni.
Zamiast tego badziewia używaj Eclipse z AVR GCC - no chyba że korzystasz z tych najnowszych procków hybryd majkerczipa z atmelem wtedy ok - rozumiem, nie masz wyjścia i musisz się męczyć z majkerczipowym super kocim środowiskiem.
generalnie GCC uporządkował typy i stąd są mega jasne i czytelne
uint8_t
int8_t
uint16_t
int16_t
uint32_t
int32_t
no i
char który domyślnie jest kompilowany tak że wpisywany sam jako char jest zamieniany na unsigned char żeby właśnie nie trzeba było tyle tego durnego pisania "uuuunsssigneed char" zamiast tego KRÓTKO "char" tyle że typ char stosujemy do zmiennych przechowujących kody ASCII a nie Qurczę do wartości liczbowych - to oczywiście nie wymóg a styl dobrego pisania programów i aż się dziwię że o to pytasz skoro w podpisie na forum masz info że masz wszystkie moje książki to skąd takie podejście jak twoje - ja wciąż w książkach i mówię o typach i pokazuję setki przykładów i kodów źródłowych
------------------------ [ Dodano po: 9 minutach ]MarekSz napisał(a):
Czy uint8_t nie odpowiada unsigned char?
oczywiście, że odpowiada - ale zanim zabrniesz dalej to przeczytaj co wyżej napisałem i sam się troszeczkę chociaż zastanów - po choinkę GCC wprowadziło uint8_t - tak dla zabawy wg ciebie ?
------------------------ [ Dodano po: 14 minutach ]MarekSz napisał(a):
Tu też bym poprosił o rozwinięcie myśli. Nie mam pojęcia jak bez użycia programowania obiektowego stworzyć zmienną,
hmmm to wg ciebie ty programujesz obiektowo ????? zaraz zaraz - mówimy o języku C czy C++ bo to jest ogromna różnica i niestety albo nie wiesz co to znaczy programowanie obiektowe i dlatego używasz niewłaściwego określenia - albo może ty jednak zadałeś pytanie o swój kod pisany w C++ ???? chociaż w to wątpię - ale może się mylę to wyjaśnij
w C nie ma programowania OBIEKTOWEGO - to musisz sobie zapamiętać
MarekSz napisał(a):
stworzyć zmienną, którą będę używał np. w 2 funkcjach. W powyższym przypadku jest ona wyciągnięta do globalnej, gdyż planuję jej w innej funkcji modułu obsługi LED.
Tu nie masz co się martwić - na razie zaczynasz przygodę z programowaniem i dlatego masz prawo jeszcze tak do tego podchodzić żeby nadużywać zmiennych globalnych ale uwierz mi będziesz musiał jak najszybciej tak pisać programy żeby się ich pozbywać albo ograniczać do niezbędnego minimum.
------------------------ [ Dodano po: 17 minutach ]poza tym jak dajesz specyfikator static takiej zmiennej:
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
to już nie do końca można nazwać ją globalną - poczytaj chociaż w Bluebooku co robi specyfikator static z takimi zmiennymi i dlaczego używa się go do hermetyzacji zmiennych wewnątrz bibliotek żeby właśnie nie mogły być globalne dla całego projektu.
------------------------ [ Dodano po: 22 minutach ]MarekSz napisał(a):
Domyślam się, że chodzi o to, że tracimy kontrolę nad ilością rezerwowanej pamięci, więc istnieje możliwość wyjścia poza limit? Czy jeszcze o coś?
Poza "limit" jak to nazywasz to można i wyjść nawet bez używania dynamicznej alokacji i realokacji - wystarczy właśnie nie dbać o typy szczególnie zmiennych automatycznych wewnątrz funkcji, o złe działania na tablicach itp itd.... tego zawsze w C trzeba mega pilnować.
Pisałem wyżej że ta porada od Ord jest totalnie bez sensu i wcale się nie unika ani alokacji ani realokacji w embedded - to wręcz jakaś fantasmagoria. Oczywiście, że się używa tylko trzeba rozumieć po pierwsze jak to działa? co to jest sterta (heap) a w przypadku niektórych mikrokontrolerów o nieliniowym adresowaniu pamięci ram trzeba również na to uważać - jest to szeroki temat - ale kompletnie nie do omówienia na tak prostym przykładzie. W takim prostym kodzie jak najbardziej można używać tylko też trzeba sprawdzać wynik działania funkcji malloc a szczególnie!!! realloc czyli czy przypadkiem zwracany wskaźnik nie jest pusty NULL .... dużo szerzej mówię o tym w moim Kursie języka C Online którego ci polecam a przy okazji którego zapoznasz się i polubisz ECLIPSE
zajrzyj sobie na stronę:
https://akademia.atnel.pl/ale też poczytaj komentarze uczestników w internecie tego kursu
koniecznie obejrzyj sobie i ten filmik:
https://www.youtube.com/watch?v=UnG-dgVgdMQi poczytaj komentarze pod nim