On 24/05/2023 11:16, io wrote:
>> I dlatego możesz wybrać Qt, które używa natywnie UTF-16 i potrafi,
>> jesli potrzebujesz, policzyć ile jest tam *znaków* jak również
>> przemieszczać się między UTF-8. Tylko że od razu mówię, że policzenie
>> ilosci znaków w UTF to zagadnienie na habilitację. Nie bez powodu jest
>> skomplikowane a zdaje się że w kilku wypadkach (bodaj Koreański) mocno
>> mętne. QTextBoundaryFinder.
>> Innymi słowy, jeśli masz zagadnienia związane z tekstem UTF, to masz
>> zagadnienia związane z jego wyświetlaniem, a to jest cecha biblitek
>> graificznych, nie C++. C++ nie posiada w standardzie nic [G]UIowego.
> 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.

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#...

>>> A to moze być np program do komunikacji z czytnikiem kart bankowych.
>> Wtedy masz połaczenie z hardware i wtedy piszesz translator z
>> hardwarowego true na softwareowy true.
>> Reszta algorytmini nie powinna nic wiedzieć o jakims hardware, a
>> prawidłowo napisana powinna dać się uruchmić i przetestować bez hardware.
> true/false to wartości logiki jaką wyraża język a nie kwestia sprzętu.

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.

>> Prawie każda przenośna bibliteka, z korzeniami w C, redefiniuje
>> wszstko. To świadczy o tym, jak kiepski to język, skoro nawet
>> podstawowe typy nie mają sensownie okreśonych sizeof i trzeba to łatać
>> ręcznie.
> Nie bardzo. To jest kwestia właśnie tego, że język programowania
> niekoniecznie musi cokolwiek wiedzieć o konkretnych typach danych.

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).

> Bo w
> środowisku embedded może nie być żadnych łańcuchów znaków i bibliotek do
> ich prezentacji.

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.

> 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.

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

Zabawne, nie?

https://stackoverflow.com/questions/437470/type-to-u
se-to-represent-a-byte-in-ansi-c89-90-c/437640#43764
0

I to jest używane w embedded, do grzebanai w rejestrach o ścisłych
szerokościach. Nazwał bym to kipeskim żartem, gdyby nie to że to
standard przemysłowy.

>> Jak chcesz świadomie, to w boost jest tribool. On ma trzecią wartość,
>> niezdefiniowaną.
> Ale to każdy typ danych może mieć niezdefiniowaną wartość.

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.

> Z językowego
> puntu widzenia są odpowiednie konstrukcje językowe co raczej nie mapuje
> się automatycznie do sprzętu.

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.