On 23/05/2023 19:00, Grzegorz Niemirowski wrote:
>> I jakie problemy z rozmiarem liczonym przez sizeof zostały tam
>> rozwiązane? Albo w ogóle jakieś inne?
> To nie ma znaczenia.

Rozmiem. Dyskutujesz po prostu przez zwykłe czepialstwo detali.

do góry

heby <h...@p...onet.pl> napisał(a):
> On 23/05/2023 19:00, Grzegorz Niemirowski wrote:
>>> I jakie problemy z rozmiarem liczonym przez sizeof zostały tam
>>> rozwiązane? Albo w ogóle jakieś inne?
>> To nie ma znaczenia.
> Rozmiem. Dyskutujesz po prostu przez zwykłe czepialstwo detali.

Zaciekawiła mnie Twoja wypowiedź więc pytam. Co w tym czepialskiego?
Niestety zamiast odpowiedzi dostaję wywody o C++, o rozwiązywanie problemów,
opowieści o Linusie, marudzenie na embeddowców, rozważania o clangu i
mnóstwie innych rzeczy, które właśnie nie mają znaczenia dla tej jednej
prostej kwestii.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 23/05/2023 19:28, Grzegorz Niemirowski wrote:
>>>> I jakie problemy z rozmiarem liczonym przez sizeof zostały tam
>>>> rozwiązane? Albo w ogóle jakieś inne?
>>> To nie ma znaczenia.
>> Rozmiem. Dyskutujesz po prostu przez zwykłe czepialstwo detali.
> Zaciekawiła mnie Twoja wypowiedź więc pytam. Co w tym czepialskiego?

"Jeśli założyć, że Fort to to samo co Fortran, to w C jest bool, bo jest
w C99".

Po prostu czepiasz się dla samego czepialstwa. Nie dziwie się. To usenet.

A przypominam że odpowiadsz na narzekania wytwarzania #define TRUE w
milionie przypadków programistów C którym C99 zwisa tak samo jak C++, bo
oba to lewackie fanaberie, wliczając w to permutacje z poglądami o
TRUE/FALSE przez OSy.

Liczba ludzi z Cxx/C++xx w kodzie jest śladowa i nie ma w ogóle
śladowego statystycznego znaczenia dla dysputy. Po prostu znalazłeś rysę
na argumentacji wynikającej z uogólnień oraz wycinania cytatów i
wczepiłeś się wszystkim pazurami aby coś wykazać. Ch... wie co.

> Niestety zamiast odpowiedzi dostaję wywody o C++, o rozwiązywanie
> problemów, opowieści o Linusie, marudzenie na embeddowców, rozważania o
> clangu i mnóstwie innych rzeczy, które właśnie nie mają znaczenia dla
> tej jednej prostej kwestii.

Której kwestii?

Że Cxx ma boola z którego nikt, poza szumem ciekawskich i kilkoma
członkami komisji z zielonym suknem miało okazje użyć?

do góry

On 23.05.2023 19:50, heby wrote:
[...]
> Liczba ludzi z Cxx/C++xx w kodzie jest śladowa i nie ma w ogóle
> śladowego statystycznego znaczenia dla dysputy.Znaczy się że np. constexpr z C++11
mało kto używa? :-)

do góry

On 24/05/2023 00:42, JDX wrote:
>> Liczba ludzi z Cxx/C++xx w kodzie jest śladowa i nie ma w ogóle
>> śladowego statystycznego znaczenia dla dysputy.Znaczy się że np.
>> constexpr z C++11 mało kto używa? :-)

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

do góry

W dniu 22.05.2023 o 22:29, heby pisze:
> On 22/05/2023 21:30, J.F wrote:
...
>
>>>>> W dodaku działa tak samo dobrze dla tablic i dla znacznie bardziej
>>>>> skomplikowanych kontenerów czy nawet głupich stringów.
>>>> stringa powiadasz ... bajtowego, unicode, utf-8 ? :-P
>>> C++ nie wspiera UTF-8. Nie wspiera też Mazovii ani ATASCI.
>> Ale programy wymagają UTF-8.
>
> 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.

>
>>> U mnie true i false są zdefiniowane przez standard.
>> W C/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.

>
>>> Patrz, jeszcze jeden powód żeby porzucić guano C.
>> Przeciez w C tez są zdefiniowane przez standard.
>> Tylko trochę słabo.
>
> C nie wspiera typu bool. Różne OSy różnie definiują TRUE/FALSE.
> Napisanie w tym bałaganie generycznego/przenośnego algorytmu jest
> utrudnione.
>
> 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. 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.


>
>> Albo lepiej niz w C++, bo brak wartosci nieokreślonych :-)
>
> A są jakieś nieokreslone wartości bool?
>
> Jak chcesz świadomie, to w boost jest tribool. On ma trzecią wartość,
> niezdefiniowaną.

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.

do góry

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.

do góry

W dniu 24.05.2023 o 11:53, heby pisze:
>> 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.
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.

--
Janusz

do góry

On 24/05/2023 12:45, Janusz wrote:
>>> 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.
> 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?

do góry

W dniu 24.05.2023 o 12:46, heby pisze:
> On 24/05/2023 12:45, Janusz wrote:
>>>> 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.
>> 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.
Sraty taty, chodzi na atmedze8 bo akurat taka miałem, zajmuje całe 668
bajtów wszystkiego :) Wystarczyłby 2kilowy attiny :)

>
> Dlaczego musi być to w języku koniecznie a nie w biblitece?
>
Nie rozumiem, możesz jaśniej?

--
Janusz

do góry