Dziwny problem z kodem w C (gcc mips/pic32)

Te fakty to schizofreniczne łaczenie kropek na osobnych kartkach.

Pojmuję. Dlatego że pracowałem od ~20 lat nad oprogramowaniem, w którym responsywnośc i szybkosc były *krytyczne*, włącznie z Twoim ukochanym UI. I programowanie nowoczesne (funkcyjne, obiektowe, szablonowe, abstrakcyjne) było niezbędnym elementam uzyskania tego efektu.

Wiem więcej o programowaniu responsywnego UI niż może Ci się wydawać. I wiem, że to nieosiągalne w C bez absultnie iditycznego poziomu szamba jaki by wygenerowało. Ilość skomplikowanych rozwiązań jest przytłaczająca jak na jezyk do pisania dupereli.

Podpowiem: jest dużo kiepskich programistów. Wina języków typu C++ jest tu niewielka. Dużo większa wina języków klikalnych, kieposkiego kształcenia i wsysania na stanowiska programistów byle kogo z ulicy.

Byłem w procesie rekrutacyjnym jako kandydat i jako manager teamu. Jestem "rekrutowany" prawie codziennie (absolutnie nie przesadzam). Byłem częscią procesu edukacji ludzi z dyplomami informatyków. Można powiedzieć, że widziałem wszystko, z każdej możliwej strony.

Ludzie, przyjmowani na stanowiska programistów, są kiepscy. W dużej większości. I nie chodzi tu o znajomośc wyszukanych algorytmów. O zwyczajną intuicję, talent i umiejętności poza edukacyjne.

Wiesz ilu, w ostatnich 5 latach, widziałem ludzi po studiach, kandydujacych na stanowisko programisty, mających hobby z choć z okolicy informatyki? Zero.

Tu szukaj przyczyny, dla której niektóre aplikacje są napisane źle. Ba, przytłaczająca większość.

Wnikasz. Poprzednie wypociny to było narzekanie na to, że UI jest nieresponsywne bo obiektowe.

Już się wycofujesz w panice?

Ma.

Idiotą można być w dowolnym jezyku.

Natomiast Ty pondniosłeś konkretną, nieistniejącą korelację. Tak naprawdę jesteś tylko następnym konserwatystą który usilnie stara się zrzucić problem na rzeczy, których nie pojmujesz.

Wina Tus^M^M^Mobiektowości.

Przed chwią wyjasniłeś czym jest ten czynnik, że to "obiektowe badziewie". Nawet ekran poplułeś. Czyli jednak ucieksza w panice od własnej argumentacji?

Co ma wspólnego obiektowe pisanie z kipeskim kodem. Nie wyjaśniłeś, ale pewnośc już masz.

Dostosowujemy. Dlatego embedded trzyma się C. Miganie diodą czasami jest krytyczne istotne, a wiadomo, że ludzie w embedded to nie idioci i nigdy błedów nie popełniają. W końcu ta dioda to może być silnik respiratora. Trzeba się skupić i pisać porządny kod, od razu, bez błedów i najlepiej na produkcji.

Natomiast reszta ludzi, świadomych swoich ograniczeń, spodziewa się języków bezpiecznych, utrudniajacych popełnienie błędu. Język C++ bezpieczny nie jest, ale jest *bezpiczeniejszy* od C. I za darmo. Jeśli ktoś nie bierze tego darmowego obiadu, bo ma kretyński konserwatyzm we krwi, to nic nie poradzę. Musi nastapić zmiana pokoleniowa i uszczelnianie szamba po obecnym pokoleniu programatorów C. Tak jest od ponad 20 lat z miejsca, gdzie widzę to na żywo. I jeszcze długo będę widział, bo skumbrii w tomacie wśród programistów nie brakuje, wbrew obiegowej opinii to nie tylko ludzie otwarci na nowości.

Może wtrącę od siebie 3 grosze:

Parę lat temu używałem... przepraszam... próbowałem używać na smartfonie interfejsów typu 3D: jakiś pseudo pokój ze ścianami, szufladami itp. Było to o tyle ciekawe, że pisane było w Javie, C++ i bóg wie czym jeszcze.

Pierwsze projekty były oczywiście toporne i oferowały ograniczone interakcje, potem przyszły takie które - można powiedzieć - nadążały za użytkownikiem kosztem ograniczenia funkcjonalności samego shella.

Obecnie to już totalna nisza, bo nikt przy zdrowych zmysłach widząc jak w szybkim postępie liniowym bateria urządzenia jest drenowana przez taką "nakładkę" po prostu tego nie używa.

Z drugiej strony widziałem również kilkanaście lat temu demo projektu ShellCube na Amigę 500/1200 gdzie respons widoczny przynajmniej na tym filmie był nie większy niż kilkadziesiąt milisekund. I to mi się spodobało.

Stawiając te projekty obok siebie: Gdzie w przypadku programistów ARM tkwił błąd ? Procki szybkie, wielordzeniowe, ze sporymi zasobami... a tu coś co miało kilkaset MHz, jeden "rdzeń" i ledwie ...naście mega pamięci...

Przypomniała mi się również tzw "scena" gdzie prawdziwi mistrzowie w pliku o wielkości 64KB byli w stanie zmieścić obraz, dziwięk midi i miało to czasem po 7 minut.

Tak - tęsknię za czasami, gdzie można było napisać surowy kod - nieobarczony całym tym gwónoszitem UI i można było w kompilatorze włączyć (lub nie) optymalizacje kodu i faktycznie robiło to "robotę". Z pliku wynikowego np 200-300 kb robiło 80-120 kb - i był tam kod pracujący naprawdę dobrze.

Teraz też chciałbym aby młodzi byli w stanie znaleźć i umieli używać optymalizacji...

vel ostatni wypust samsunga S23 Ultra i jego ROM o wilekości - o ile dobrze pamiętam - 62,3 GB ??????

Puściłem ostatnio kompilację z PiC C Compiler na PICa 32MZ, jakieś 80 KB kodu, a kompilator z MPLAB zrobił z tego blisko 323 KB bo zadeklarowałem, że będę używał 17 bibliotek wbudowanych.

Nie ma UI, jest tylko wewnętrzna prosta obsługa bieżąca.

I coś co każdy "widzi na codzień" - pierwszy windows: na kilku dyskietkach, obecny: na kilkunastu DVD się nie zmieści...

Pierwszy robił co miał robić - obecny... właściwie nie wiadomo co robi...

W dniu 21.05.2023 o 20:52, heby pisze:

Coraz gorętsza dyskusja, to pozwolę sobie trochę obok tematu, ale o tej responsywności.

Jak można zbudować system, który tak kiepsko działa, nikt tego nie testuje przed odbiorem? A mam na myśli np. biletomaty Apcoa. To, że przycisk wandaloodporny pojemnościowy działa po dotknięciu za 4-5 razem, to pominę, może jest uszkodzony. Ale od momentu naciśnięcia do pojawienia się jakiejkolwiek reakcji na wyświetlaczu mija kilka sekund, po których pojawia się info o druku biletu i następne kilka sekund na reakcję drukarki.

Albo wpłatomat. Komunikat, że brak papieru, czy chcesz kontynuować. Tak chcę, po zakończonej wpłacie komunikat... weź potwierdzenie, które jest dowodem... ale przecież nie ma papieru.

To nie są jakieś darmowe apki z Google Play, tylko systemy za grubą kasę.

Robert

Byłem programistą na Amidze. Zarówno grzebiącym w hardware i piszącym "efekty" jak i używajacym wielu aspektów OSa. Powiedzmy, że wiem jak to działało w bardzo wielu płaszczyznach.

Więc tutaj muszę Cie zmartwić: Amiga, z OS od wersji 2.0, miała obiektowy interfejs. BOOPSI. Używałem go, bawiłem się nim, pisałem w nim aplikacje. Był szybki, bardzo łatwy w użyciu i powstała masa upraszczaczy, w tym najsłynniejszy MUI, który był znakomity. nie miał się czego wstydzić względem podobnych rozwiązań na innych OSach.

Prawdopodobnie przeciwnikom obiektowośc żyłka pęknie na samą myśl, że Amiga 500+ miała (częściowo) obiektowy system operacyjny.

Doszukiwanie się problemów w samej obiektowości jest, w obliczu tego przykładu, naiwne.

No więc ja wiem jak to było, od kuchni.

a) Efekty nie mogą mieć dużo kodu, bo nie miałby go kto wykonać w spodziewanym czasie. Kod był często generowany w czasie rzeczywistym z innego, włącznie z parametrycznym generowaniem danych wymaganych przez "efekt". To są pojedyncze kB. b) Muzyka MIDI jest bardzo skompresowana. W przypadku Amigi często wavetables (sample) były wytwarzane parametrycznie. Sama jakość układów dzwiękowych Amigi nie była aż tak super, aby te sample były też super. Przeciętny "moduł", czyli muzyka z dema, to kilkadziesiąt kB z samplami. To kwestia kreatywności muzyka. c) Jeśli przejrzysz jeszcze niższe demka 8-bit, zazwyczaj jest to powtarzanie tych samych efektów, często z tymi samymi danymi graficznymi, po wielokroć w pętlach. Dema rozbudowane, często ładują dodatkowe elementy z dysku, bo się nie mieszczą w 64k.

Obecnie też pracuje dobrze.

Obecnie też możesz pisać wydajne apliakacje.

Obecnie GUI jest zarąbisto szybkie, ale musi przerzucać 32 bitowy kolor z przezroczystością i rozmywaniem. I tak jest zarąbiście szybkie.

To wszystko to tylko problem z jakością programisty, nie narzędzi.

Typowy problem w GUI typu "zamrażanie, bo coś robię" to bezpośrednia konsekwencja niedzielnych programistów Drag'n'drop z Delphi. Oni nie potrafią pisać inaczej, niż logika biznesowa w onklikach. To się propaguje na współczesne języki, Delphi było tylko źródłem wszelkiego zła.

Optymalizacja, szczególnie automatyczna, jest ostatnią rzeczą jaka jest ważna.

Zdecydowanie więcej zysku uzyskując prawidłowo pisząc algorytmike, niż z optymalizacji na poziomie kompilatora. Ba, nieudolne próby optymalizacji kodu mogą zniweczyć efekt przyszłych refaktoringów.

Zauważyłeś jak skomplikowane i rozbudowane jest obecnie API windowsa, względem powiedzmy wersji 95? Zauważyłes, jak wiele jest obecnie mediów zawartych w samym systemie? Zauważyłes, że ogólnie ilość wymaganych funkcji OSa wzrosła wielokrotnie, z reszą na życzenie userów?

make.

I do klientów.

Znam firmę, która to robi na codzień. Kiedyś gadałem z jednym z programistów. Zapytałem jak testują. Zostałem nazwany idiotą. Oni piszą tak, że nie trzeba. Dobrze, znaczy. Koleś ma tak pod 60kę. O unit testach, testach integracyjnych itd słyszał, ale to tylko nowoczesne gówno. Oni tego nie potrzebują. Jak coś się spieprzy, to się naprawi i tyle.

Kamyczek w ogródek embedded

Mam zmywarkę hotpoint. Wciśnięcie "power on" powoduje 4sek pauzę, po której zmywarka wstaje i ożywa.

W czasie tych 4 sekund, przeciętny user, w tym ja, w pierwszym zderzeniem z tą zmywarką, wciśnie ten przycisk 6 razy.

To jest przykład, że imbecyl-programista to również rzecz spotykana w embedded.

Wcześniejsza wersja miała reakcję natychmiastową. Bo przycisk był mechaniczny.

Odpowiedź brzmi: te system nie są odbierane przez wolny rynek. One są odbierane przez urzędniczych pustaków, którym wystarczy wyjaśnić, że "komputer myśli". Ale za to są kolorowe ikonki. Widziałem kiedyś taki odbiór na żywo. Straciłem spory kawałek mózgu starając się logicznie ogarnąc argumentację producenta. To bez znaczenia z resztą, system został wdrożony i przez wiele lat przyczynił się do depresji i ataków zaniku logiki wielu petentów pewnego urzędu.

W dniu 21.05.2023 o 22:52, titanus pisze:

Z powodu baterii, jak można używać urządzenie na zasilani bateryjnym???

Czemu już nie produkują Amigi?

No to powinno pójść na większych. Czy nie.

No przecież o tym właśnie mowa, hebe, zasadniczo słusznie, twierdzi że można to zrobić za pomocą C++ zamiast assemblera i C bez straty tej optymalizacji a z potężnym zyskiem w postaci jasności kodu.

No i czemu nie ma urządzeń z mniejszym?

Bibliotekom Arduino nie pomaga nawet to, że są pisane w C :-)

Windows IoT mieścił się na 2GB to chyba nie tak źle na system, który już jakoś sam działa.

Dobra, ale czemu w takim razie nie używasz tych prostych rozwiązań.

...

Czytnik grup Mozilli też mi się jakoś zamraża. Pewnie niedzielni programiści Delphi :-)

Nie bardzo. A właściwie to wcale. Użytkownicy w ogóle nie oczekują funkcji systemu operacyjnego. Funkcjonalność postrzegają jako cechę programów. Programistycznie też nie widzę by jakoś bardzo się ten system operacyjny rozwinął. Wręcz się programistycznie uprościł ze względu na obiektowe API dotnetów.

W dniu 21.05.2023 o 22:57, Robert Wańkowski pisze:

No ale kto te systemy zamawia.

Tam było źródło problemu kiepsko napisanych apliakcji GUIowych. Narzędzie powodowało, że ludzie preferowali złe praktyki i tak im już zostało do dzisiaj. Mam ciągle do czynienia z ludzmi, robiącymi w onkliku pętlę o nieznanej złożoności. Codziennie.

Ogólnie dużo teoretycznej i praktycznej wiedzy z lat 60-70 zostało zgubuione podczas rewolucji informatycznej 80-90, gdzie w użyciu było pełno guano w rodzaju BASIC, Delphi czy C. Odtwarzamy to mozolnie w nowoczesnyc językach programowania, ale opór konserwatywnej materii jest ogromny i jak widać da się go rozwiązać tylko na drodze zastępowania pokoleń.

Oczekują. MS pododawał masę ficzerów, takich jak np. kompleny system firewalla/antywirusa, bo tego oczekiwali tumaniści. Dodał ogromny subsystem DirecX bo tego oczekiwali gracze. Dodał kilkanaście równległych wersji engines .NET bo tego oczekiwali niedzielni programatorzy. Dodał nowe sposoby aktualizacji oprogramowania, bo może tym razem zadziała. Dorzucił animowane menu, bo i kretyn powinien się cieszyć. Itd itp.

Pojawiło się dużo funkcji systemowych i bibliotek, zintegrowanych z OSem. Nie musisz ich widzieć bezpośrednio, ale pośrednio widzi je jako niezbędne do odpalania programów i funkcjonowania w tym nowym, internetowym świecie.

Windows jest obecnie jak odkurzacz, wsysa do OSa wiele rzeczy, niektóre potrzebne a niektóre to tylko artefakty debilnego planowania MS. A notatnik jest tak samo gówniany, jak był. Pewne rzeczy, dobrze wiedzieć, są niezmienne.

Prawidłowy rozmiar w bajtach. Nie w ilosci elemntow tablicy.

Prawidłowa jest (sizeof(BT)/sizeof(unsigned short)) lub (sizeof(BT)/sizeof( BT[0]))

A i to z ograniczeniami.

No i co z tego, ze nie chcesz? Tobie może starczy, inni będą mieli G11, czy 12, i twoja znajomość W7 może się okazać niewystarczająca :-)

W dodatku update'y są, i W7 teraz, to nie to, co było na początku.

J.

Ehm ... ciekawe stwierdzenie, szczególnie jak sie ambitnie przeciąży obiekty a jeszcze bardziej operatory.

J.

W dniu 22.05.2023 o 13:14, J.F pisze:

Dla mnie jest wystarczająca :) inni mnie nie obchodzą bo używam dla własnych celów.

I dlaczego uważasz, że to są właśnie przykłady przejrzystości C++?

uważam wręcz odwrotnie, więc polemizuję z tą przejrzystością :-)

J.

To cherry picking. Wybierasz złe konstrukcje, aby udowodnić tezę, że C++ jest nieprzejrzysty.

To nieuczciwe dyskutowanie.

std::size() jest znacznie bardziej przejrzysty, niż sizeof/sizeof i to wystarczy dla podniesienia jakosci i bezpieczeństwa. Takich konstrukcji jest wiele w C++ i nie operaja się one o jakieś trudne do ogarnięcia mechanizmy. Są wręcz trywialne.

Nikt nie nakazuje używania skomplikowanego dziedziczenia czy operatorów. Nikt. To kwestia wyboru przez programistę. Mądry programita nie wybierze ich tylko dla beki. A na niemądrych jest lint i code review.

Użytkownika interesuje firwall? Co Ty gadasz.

Co gracza obchodzi jakiś subsystem? To jest co najwyżej zapotrzebowanie programistów tych gier, które to gry są oczekiwane przez graczy. Gracze w ogóle nie widzą potrzeby istnienia systemu operacyjnego choćby ten system w jakimś małym stopniu miał sens. I tak to funkcjonowało w czasach DOS tylko producent miał ambicje by zgarnąć tych wszystkich programistów co zresztą w przypadku Windows Phone źle się dla niego skończyło.

Programiści nie pasują? Ależ bzdury. Powielenie? Tak funkcjonują systemy operacyjne od zarania. Bo jak inaczej by to miało funkcjonować? Biblioteki rozwijają się aż ktoś mówi stop kompatybilności i sobie taka wersja zostaje.

Jakie? MZ nie dostarczył normalnego instalatora tylko narzędzie do instalacji siebie i swoich zaufanych aplikacji.

No tak, na całym świecie są ludzie, którzy uważają że umieją to zrobić lepiej.

Jak nie pasuje C++ to możesz sobie wziąć Netduino :-)

Zalezy na jakiego programistę trafisz :-)

A zwraca wynik w bajtach, w elementach, czy to się po prostu wie? :-)

Chyba, ze złośliwy programista przedefiniuje, bo może :-)

No nie wiem, czy zauważy, ze size() działa w danym obiekcie inaczej, albo ze "+" oznacza teraz odejmowanie :-)

J.

Zwraca rozmiar.

Dla różnych typów zachowa się to jak zahardkodowana stała, zawołanie metody obiektu albo zostanie policzone na etapie kompilacji. Dzięki magii C++ wybór implementacji jest automatyczny.

Ale to bez znaczenia, piszesz na poziomie na którym interesuje Cie

To jest właśnie wysokopoziomowe określenie potrzeby.

W dodaku działa tak samo dobrze dla tablic i dla znacznie bardziej skomplikowanych kontenerów czy nawet głupich stringów. Czyli Twój kod staje sie bardziej generyczny i łatwiejszy w analizie. Do tego stopnia, że templateowa funkcja, w której jest std::size(), działa dla szerokiego zakresu danych wejściowych.

To samo może i w C.

Widziałem kod gdzie było:

#define TRUE 0

Zostawione w 1 pliku cpp na złość, przez niemiłego kodera-hackera. Gdybym nie miał tego pliku w historii to bym uznał to za jakas anegdotkę, a jednak kosztowało to kogoś dzień debugowania. Tak, trafiają się w tym zawodzie idioci, schizofrenicy, hackerzy, zarozumialcy, złośnicy. Mamy skuteczne metody ich eliminacji i utrudniania takich sabotaży.

Nie, ponieważ: a) programiści w zespołach nie są względem siebie złosliwi w normalej sytuacji. A jak są, drzwi otwarte. b) sami ustalają co można, a co nie, używać i z czym czują się komfortowo. c) świadomośc tego jak coś działa w detalach jest przeciwieństwem współczesnego pisania wysoko abstrakcyjnego kodu d) są do tego unit testy, aby pilnować takich dupereli e) istotą size() jest to, aby działało w kazdym obiekcie/typie tak, jak tego się spodziewasz po słowie "rozmiar".

Jedną z najtrudniejszych sztuczek jakie miałem w swojej karierze, jako osoba ucząca nowych członków zespołu, to była potrzeba wyplenienia z nich potrzeby wiedzy o tym jak coś działa w środku. Przestawienie programisty C z asemblera na myślenie abstrakcyjne jest nadludzkim wysiłkiem i nie w każdej sytuacji udało się. Wielu z nich nie potrafi inaczej myśleć niż pointerami, przez co współczesny kod C++ traktują dokładnie tak jak połowa ludzi w tym wątku - z wyparciem i urojeniami na temat jego wydajności.