makro PSTR ma taką postać:
Kod:
# define PSTR(s) (__extension__({static const char __c[] PROGMEM = (s); &__c[0];}))
i już nie ważne czy z const czy bez const, jest to niejako instrukcja zakończona średnikiem, co oznacza, że jeśli jest w postaci definicji czy deklaracji to jest OK, jeśli zaś wystąpić ma w postaci argumentu funkcji to rzeczywiście z punktu widzenia syntaktyki zdaje się C++ jest to instrukcja, która NIC NIE ROBI (statement has no effect). Niestety gdyby to był C czy C++ stosowany na PC to nigdy z taką sytuacją byśmy nie mieli do czynienia ponieważ tam nie ma takich hocków-klocków z jakimś PROGMEM ... i całymi sztuczkami jakie trzeba robić w avr gcc żeby dopasować niejako C na potrzeby procków. Więc coś za coś - udało się to sprytnie za pomocą tego makra ominąć i kompilator AVR GCC sobie z tym radzi bo przecież nie zgłasza żadnych warningów! a to jest najważniejsze - więc możemy być pewni że z punktu widzenia AVR GCC jest wszystko ok
owszem jak się pracuje w eclipse to te podkreślenia (szlaczek żółty i to oznaczenie po prawej na pionowej belce) mogą drażnić bo po kompilacji zawsze wydaje się że pozostał jakiś warning, więc jeśli często posługujemy się czymś takim, to może to prowadzić do sytuacji, że wciąż będziemy musieli skrupulatnie od nowa przeglądać każdy przypadek i oceniać czy to coś złego czy nie....
więc znowu - można ponarzekać a można poszukać przyczyny ale i rozwiązania problemu. OK przyczynę już widać gołym okiem - za te szlaczki odpowiedzialne jest samo Eclipse i to akurat ta wersja - bo w innych tego nie ma. Czy to oznacza, że z tak błahego powodu ja miałbym np nie próbować nadal korzystać ze sporo lepszego Juno ????
Nie nie - można szukać dalej i znaleźć rozwiązanie - nie może być tak że coś tam się dzieje i nic nie da zrobić, no chyba że wykryjemy BUG'a w eclipse
Ja poszedłem tym tropem, że jak się najedzie kursorem myszki na to podkreślenie, to pojawia się:
hmmm w takim razie zamiast się martwić - może kliknę ten klawisz F2, żeby zobaczyć co mi się dalej pokaże:
Oooo! moim oczom ukazuje się podpowiedź: "
Configure Annotation Preferences"
czyli będzie można to gdzieś ustawić w preferencjach - coś tam musi być takiego i to może jeszcze coś czego nie ma w innych wersjach Eclipse. No to bach na tapetę bierzemy kilka poprzednich wersji Eclipse i tę najnowszą - sprawdzamy.... skanujemy.... sprawdzamy.... skanujemy....
i ciach! okazuje się że w Juno mamy dodatkowo taką pozycję w drzewku jak niżej:
czyli pojawiło się: "
Code Analysis" !!! a co w nim mamy po prawej ???
"
Statement has no effect" !!!
generowane przez Eclipsa i możemy to pięknie wyptaszyć .... więc odptaszkowujemy tę opcję i pseudo-warningi z takich instrukcji znikają a nasze oczęta nie są drażnione.
Można byłoby się obawiać no że hmmm no ale co teraz jeśli tego typu błąd tzn ostrzeżenie wystąpi gdzieś w kodzie na prawdę ? to co - może tego nie zauważymy ???? ....
O nie nie - spokojnie to już byłoby ostrzeżenie kompilatora a nie Eclipsa więc po pierwsze pojawiłoby się w konsoli po kompilacji a jednocześnie nie wyobrażam sobie aby na taki Warning od kompilatora miał nie zareagować Eclips. No i proszę mam rację - zasymulujmy sobie w kodzie C wyrażenie które wygeneruje nam Warniga prawdziwego w konsoli można to zrobić tak:
i co widzimy że teraz nawet Eclips pokazuje obydwa ostrzeżenia nieco inaczej. To wygenerowane przez kompilator oznaczył standardowo trójkątem ostrzegawczym, a to wynikające z jego "Code Analysis" jakąś pchłą .... (bo znowu włączyłem PTAKA) przy tej opcji. A zatem teraz go wyłączam i proszę jak to wygląda:
czyli podkreślenia z domysłów eclipsa (code analysis) zniknęły bezpowrotnie natomiast warningi z kompilatora tak jak miały być tak pozostają.
KONIEC TEMATU
Kanał - ATNEL tech-forum
Zaloguj
Zarejestruj
Informacje o cookies
FAQ
Szukaj
