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

On 23.05.2023 19:50, heby wrote: [...]

Tak. Ja używam, poza mną prawie nikt ze znanych mi żywych ludzi.

Dyskusja jest o tym jak udoskonalić swój warsztat zamiast trzymania się uporczywie konserwatywnej ideologii. Dotyczy to również programistów C++, często rozumiejących świat jako "klasa ma metody i styknie, dziadek tak programował".

...

Zagadnienie analizy tekstu nie ma nic do jego prezentacji. Możesz mieć urządzenie embeeded, które niczego nie wyświetla a tylko umie parsować łańcuchy znaków.

true/false to wartości logiki jaką wyraża język a nie kwestia sprzętu.

Nie bardzo. To jest kwestia właśnie tego, że język programowania niekoniecznie musi cokolwiek wiedzieć o konkretnych typach danych. Bo w środowisku embedded może nie być żadnych łańcuchów znaków i bibliotek do ich prezentacji. A w środowisku systemu operacyjnego raczej na pewno będą. Raczej nie ma sensu by język nie mógł wyrażać logiki. No ale to może tyle, że nie jest to kwestia jaką wartość numeryczną przypisujemy.

Ale to każdy typ danych może mieć niezdefiniowaną wartość. Z językowego puntu widzenia są odpowiednie konstrukcje językowe co raczej nie mapuje się automatycznie do sprzętu.

Interesujace to musi być urządzenie.

Szkoda, że nie pomyśleli o tym twórcy standardu C++. I o gotowych funkcjach do sterowania prodziżem. Też by się przydały.

A nie, czekaj, to dojdziemy do C#...

Istnieje miejsce, gdzie stan bitu, rejestru, przerwania może określać stan logiczny w kodzie. To miejsce zazwyczaj posiada adapter hardware<>software. Ten adapter jest niskopziomowy, mający pojcie o detalach implementacyjnych hardware. Pozostałą część kodu już nie musi go widzieć. To tak działa w każdym jezyku, ale C++ ma w ręku asa: dzięki templates (statyczny polimorfizm) to może być *bezkosztowe* dla generowanego kodu, produkcyjnego.

A jednak prawie wszystkie języki wysokopoziomowe, poza C, mają ściśle zdefiniowane typy. Nawe super-uniwersalna Java ma ściśle zdefiniowane typy.

Jedyny inny jaki kojarzę, z defektem braku ścisłych typów, to BCPL.

To artefakt tego, że C to tak naprawdę asembler, tylko o nieco innej składni. I jak każdy asembler - nie był wymyślony do bycia przenośnym bez pewnego wysiłku. Jego typy danych nei tylko zależą od architektury, ale nawet od flag kompilatora (w gcc-avr można zmienić inta aby miał 8 bitów jedną flagą kompilatora, co nie jest standardowe, ale widocznie komuś potrzebne).

Dzięki magicznym właściwościom C++ nigdy ich w takim embedded nie zobaczysz, bo C++ ma zerowy narzut na kod i produkuje tylko to, co niezbędne. Innymi słowy mamy balans: co prawda język zawiera w standardzie jakieś gotowce do strigów, bo tego potrzebuje 99% ludzi, ale dla tego 1% jest dobra wiadomość: nic to ich w kodzie wynikowym nie kosztuje.

Co innego ze sterowaniem prodziża. Potrzbuje go 1%, wiec dostarczany jest w postaci biblioteki, wiec ten 1% ma trochę więcej roboty.

Problemem jest, że w C nie wiadomo ile bitów ma char.

Zabawne, nie?

Nie. W C typy integer są zawsze zdefiniowane, mogą posiadać wartości w pełnej przestrzeni permutacji bitów. Istnieją stany niedozwolone w wartościach zmiennoprzecinkowych, ale to nie to samo co niezdefiniowane.

Są jezyki, gdzie mogą być niezdefiniowane (None w pythone), ale to wymaga dodatkowej informacji w postaci flagi. Przestrzeń każdego typu integer w C jest wypełniona w 100% poprawnymi wartościami.

Stąd programistów w C czesto przyłapiesz na:

#define UNKNOWN -1

Ale to tylko workaround wymagający zgody wszystkich w obrębie danego programu. To jest znowu nieprzenośne: taki kod jest niekompatybilny z kodem, gdzie inny aparat napisał #define UNKNOWN -127.

To jedna z przyczyn, dla któej powstał boost::optional<>. W tym przypadku wszyscy się zgadzamy co to jest niezdefiniowana wartość, bez nadeptywania sobie na palce.

Dlatego pisanie w C++ (w C też, tylko nikt nie stosuje) robi to warstwami. Logika "biznesowa" jest pisana na abstrakcjach, a do sprzetu masz adaptery.

W ten sposób nieprzenośne jest tylko kilka procent typowego kodu. W dodatku kod jest unit testowalny z definicji.

C++ daje gotowce do tego (np. statyczny polimorfizm). W C nie ma nic, a jeśli ktoś jest super-hackerem to potrafi zrobić "link time polymorphism" jako nie tyle workaround, co bardziej samobójstwo.

W dniu 24.05.2023 o 11:53, heby pisze:

Normalne urządzenie, sam takie popełniłem, konwerter sterowania drukarką z maszyny, nowa do etykiet ma inny język i trzeba było z tego co wypluwa maszyna wyłuskać interesujące informacje, opakować nowymi kodami i wysłać do nowej drukarki.

To zagadnienie w sam raz dla Pi z pełnym Linuxem. Gdzie jest Qt OOTB razem ze swoim QString.

Dlaczego musi być to w języku koniecznie a nie w biblitece?

Sraty taty, chodzi na atmedze8 bo akurat taka miałem, zajmuje całe 668 bajtów wszystkiego :) Wystarczyłby 2kilowy attiny :)

Nie rozumiem, możesz jaśniej?

Na 668 bajtach kodu nie ogarniesz szerokości znaku po Koreańsku.

Innymi słowy, masz zagadnienie zupełnie inne, niż ogarnianie ogólnego przypadku, o którym była mowa w dyskusji.

Masz zagadnienie ogarniania specyficznego przypadku. W dodatku trywialnego, sądząc po ilości kodu.

Troche, jak byś marudził, że C++ powinien mieć pełen support dla grafiki

Zarzut (io) był, że C++ nie wspiera unikodu. Nie musi, to niszowa funkcjonalność w zastosowaniach C/C++. Znacznie łatwiej osiągnąć to przez bibliteki poza standardem C++. Są wtedy dobrane dokładnie do zaganienia, a nie uniwersalne. Jak by C++ wspierał unikod, to zaraz było by biadolenie embedowców, że doinkludowanie std::string powoduje dolinkowanie 4MB kodu obsługi języka RongoRongo.

No wiec nie jest to potrzebne. Od tegą są biblioteki zewnętrzne, jak Qt. Chcesz to masz. Nie chcesz, to masz char* i rękodzieło. Dla każdego coś dobrego.