On 23/05/2023 15:35, Grzegorz Niemirowski wrote:
> heby <h...@p...onet.pl> napisał(a):
>> C nie wspiera typu bool.
> Wspiera, <stdbool.h> się kłania.

To jest martwy C99 a nie C.

>> Różne OSy różnie definiują TRUE/FALSE.
> OSy nie są od definiowania elementów języka.

A jednak robią to z uporem maniaka.

https://learn.microsoft.com/en-us/windows/win32/winp
rog/windows-data-types

#ifdef FALSE
#undef FALSE
#endif
#define FALSE 0

#ifdef TRUE
#undef TRUE
#endif
#define TRUE 1

typedef int BOOL, *PBOOL, *LPBOOL;

do góry

heby <h...@p...onet.pl> napisał(a):
>> Wspiera, <stdbool.h> się kłania.
> To jest martwy C99 a nie C.

Kto Ci powiedział, że to C99? Bo akurat w C99 ten typ się pojawił? Przecież
nie znikł i w nowszych wersjach też występuje.

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

do góry

On 23/05/2023 16:11, Grzegorz Niemirowski wrote:
>>> Wspiera, <stdbool.h> się kłania.
>> To jest martwy C99 a nie C.
> Kto Ci powiedział, że to C99? Bo akurat w C99 ten typ się pojawił?

Tak. Pojawił się w C99. Programiści C niespecjalnie mają oficjalny
dostęp, ale bez problemu mogą sobie taki sami napisać. I piszą. W
milionach wersji. TRUE, True, true, T_, OK, STATUS_OK, itd itp. Można by
powiedzieć, że C to ostatnia ostoja wolności.

> Przecież nie znikł i w nowszych wersjach też występuje.

C99 i następne, jako koncept, są martwe.

Przez całe lata clang nie posiadał na przykład varrays z C99. Dodali
niedawno. Psa z kulawą nogą to nie obchodziło, czy są, czy nie varrays.
Kogo niby obchodzi jakiś C99?

Nastepne wersje C są tylko życzeniem:

https://clang.llvm.org/c_status.html

do góry

heby <h...@p...onet.pl> napisał(a):
> C99 i następne, jako koncept, są martwe.

Bez znaczenia co sobie uznasz za martwe. C jest używany przez miliony ludzi
i mają oni do dyspozycji typ bool od lat. Typów char i int też nie ma w C bo
jest według kogoś koncepcyjnie martwym językiem?

> Przez całe lata clang nie posiadał na przykład varrays z C99. Dodali
> niedawno. Psa z kulawą nogą to nie obchodziło, czy są, czy nie varrays.

Bo nauczono sobie radzić bez tego, podobnie jak bez typu bool. Tylko co z
tego ma wynikać? Fakt bez znaczenia.

> Kogo niby obchodzi jakiś C99?

Nie wiem, to Ty z nim wyskoczyłeś. Ja tylko napisałem, że typ bool jest w
języku C.

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

do góry

On 23/05/2023 16:35, Grzegorz Niemirowski wrote:
>> C99 i następne, jako koncept, są martwe.
> Bez znaczenia co sobie uznasz za martwe. C jest używany przez miliony

C czy C99? Dla embedowca to krytyczna różnica. Jeden koszerny, drugi to
lewackie fanaberie.

> ludzi i mają oni do dyspozycji typ bool od lat. Typów char i int też nie
> ma w C bo jest według kogoś koncepcyjnie martwym językiem?

Ależ one są. Bo nie umarły w C++. Cały C nie umarł w C++. Natomaist C99
i następcy umarli. Już dawno.

Świat w pewnym momencie poszedł w dwie strony. Jedni podążyli drogą
"lubie pisenki, które już raz słyszałem" i od wielu lat dreptają w kółko
na dziedzińcu Cxx od czasu do czasu odkrywając, że można czasem zmienić
krok na centymetr dłuższy i nazywaja to "rozwojem". Inni poczekali dość
długo, ale ostatni ow tempie eksresowym poznają znacznie ciekawszy język
programowania jakim stał się C++. Co bezczelna, C++ oakzał się tak samo
dobry do liczenia wybuchów jądowych, co do migania diodą.

Oba są turing complete.

Oba można użyć do dowolnego zastosowania.

Ale jak patrzysz na to wydeptane kółeczko na dziedzińcu, to ciężko
porzucić te lata kręcenia się w kółko. Ja to doskonale rozumiem. Ludzie
nie lubią zmian. Ja też nie lubię. Zmieniłem ostatnio pracę właśnie po
to, aby nie znaleźć się za nastepna 20 lat 5m w dole jakiegoś dziedzińca.

>> Przez całe lata clang nie posiadał na przykład varrays z C99. Dodali
>> niedawno. Psa z kulawą nogą to nie obchodziło, czy są, czy nie varrays.
> Bo nauczono sobie radzić bez tego, podobnie jak bez typu bool.

Mamy standard, ale nie mamy użytecznej współcześnie implementacji. Oh well.

Co do bool używam od zawsze. W zasadzie od połowy lat 90 na Amidze,
gdzie był SaSC i miał on kulawy, ale jednak C++.

> Tylko co
> z tego ma wynikać? Fakt bez znaczenia.

Wynika pogłebiające się, wydeptane kółeczko, kiedy reszta odjechała
pociągiem goniąc postęp.

>> Kogo niby obchodzi jakiś C99?
> Nie wiem, to Ty z nim wyskoczyłeś.

Nie. Wyskoczył razem z pojawieniem się bool w C i okazało się że to nie
C tylko C99. Argumentacja z gatunku "Forth jest znakomitym językiem, bo
w Fortranie..." i liczenie na to że nikt nie zauważy różnicy.

> Ja tylko napisałem, że typ bool jest
> w języku C.

W C99. A to ważne, bo C99 nikogo nie obchodzi, wliczajac w to twórców
współczesnych kompilatorów. Być może ma istotne znaczenie archeologiczne
i w zasadzie to mogło by pasować do tematu dyskusji.

do góry

heby <h...@p...onet.pl> napisał(a):
>> ludzi i mają oni do dyspozycji typ bool od lat. Typów char i int też nie
>> ma w C bo jest według kogoś koncepcyjnie martwym językiem?
> Ależ one są. Bo nie umarły w C++.

Tak samo bool nie umarł w C++, więc nie wiem skąd to zaprzeczanie jego
istnieniu w C.

> Nie. Wyskoczył razem z pojawieniem się bool w C i okazało się że to nie C
> tylko C99.

C99 to też C. Tak samo C++ ma kolejne wersje.

> Argumentacja z gatunku "Forth jest znakomitym językiem, bo w Fortranie..."
> i liczenie na to że nikt nie zauważy różnicy.

Czyli tylko K&R C to jest C, a kolejne wersje to już nie jest C?

> W C99. A to ważne, bo C99 nikogo nie obchodzi, wliczajac w to twórców
> współczesnych kompilatorów. Być może ma istotne znaczenie archeologiczne i
> w zasadzie to mogło by pasować do tematu dyskusji.

W C99 i kolejnych, współcześnie używanych. Uparcie zawężasz temat do C99.
Chodzi o to, że nowszych wersji nie używają ci mityczni embeddowcy więc
wersje te się nie liczą?

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

do góry

W dniu 2023-05-21 o 23:19, heby pisze:
> On 21/05/2023 22:52, titanus wrote:
>> 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...
>
> 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.
>
Ależ mi nie chodzi o obiektowość, czy rodzaj interfejsu UI, czy nawet
nie chodzi o to w jakim języku go napisano...

Chodzi o to, że na tamten sprzęt "skrojono" programowo niemal wszystko
"na wymiar", a "embedowcy" potrafili wycisnąć z niego niemal siódme
poty. Jednym zdaniem: soft skrojony do hadware'u.

Teraz do oprogramowania - NIEZALEŻNIE JAKIEGO - dorzuca się rzeczy
zbędne, wrogie użytkownikowi a czasem tak bzdurne, że szkoda słów.
I nie myślę tu tylko o OS'ach, ROMACH czy aplikacjach. Dzisiaj kod jest
przeważnie śmietniskiem i wylęgarnią wszelkiego crapu.

>> 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.
>
> 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.
>
>> 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.
>
> Obecnie też pracuje dobrze.
>
Pozwolę się nie zgodzić: eskalacja kodu jest pomiędzy tamtymi a obecnymi
czasami już nie liniowa a logarytmiczna - i to nie w dobrym kierunku.

> 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.
>
No nie - to problem sprzętu nienadążającego za stale rosnącymi
zapotrzebowaniami oprogramowania.

> 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.
>
>> Teraz też chciałbym aby młodzi byli w stanie znaleźć i umieli używać
>> optymalizacji...
>
> 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.
>
>> I coś co każdy "widzi na codzień" - pierwszy windows: na kilku
>> dyskietkach, obecny: na kilkunastu DVD się nie zmieści...
>
> 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?
>
Owszem, ale osobiście uważam, że ponad 60% kody obecnego windowsa
SPOKOJNIE można by z niego wyrzucić ujmując mu najwyżej 5%
"zajebistości". Kolejne 15% skierować na elementy niezwiązane z systemem
w postaci dołączanych plików, które użyte przez usera byłyby może raz
lub w ogóle. Reszt to aktywnie działający system.

Tak go widzę.

--
Pozdrawiam - titanus

do góry

On 23/05/2023 17:21, Grzegorz Niemirowski wrote:
>>> ludzi i mają oni do dyspozycji typ bool od lat. Typów char i int też
>>> nie ma w C bo jest według kogoś koncepcyjnie martwym językiem?
>> Ależ one są. Bo nie umarły w C++.
> Tak samo bool nie umarł w C++, więc nie wiem skąd to zaprzeczanie jego
> istnieniu w C.

Bo w C go nie ma. Jest w C99 lub C++. Przy czym ten w C99 to takie
śmieszne coś.

https://c-faq.com/bool/booltype.html

Konfuzja programatorów w C sięga daleko:

https://c-faq.com/bool/bool2.html

Niejaki Pan Linus, twardogłowy konserwatysta siedzący z kilometr na
prawo od Korwina, jesli chodzi o wszelkie nowości, też ma przemyślenia
na temat tego boola (i jego bliźniaka z C++) i wychodzi mu, że jednak
napisanie go w asemblerze jest najlepszym pomysłem:

https://lkml.org/lkml/2013/8/31/138

Jak wiec widzisz, to wojna na ideologie. Marudzimy z której strony
obierać jajko, kiedy programiści C wymyślają swoje kwadratowe koła
codziennie, niezmiennie od dziesięcioleci i pełni szczęści i
satysfakcji, jakie daje napisanie swojego hackerskiego boola, który nie
jest kompatybilny z niczym. Śmierć frajerom od reużywania kodu. Mój bool
jest mojszy.

>> Nie. Wyskoczył razem z pojawieniem się bool w C i okazało się że to
>> nie C tylko C99.
> C99 to też C. Tak samo C++ ma kolejne wersje.

I dlaczego należy wybrać Cxx zamiast C++xx? Masz jakieś merytoryczne
argumenty?

>> Argumentacja z gatunku "Forth jest znakomitym językiem, bo w
>> Fortranie..." i liczenie na to że nikt nie zauważy różnicy.
> Czyli tylko K&R C to jest C, a kolejne wersje to już nie jest C?

Kolejne wersje nie są tutaj dyskutowane, drogi Sherlocku.

Była mowa o przejściu z C na C++ bo to akurat nie jest ślepa uliczka.

Jeśli będziesz chciał przejść z C99/11 na C++ to proszę bardzo. Musisz
się jednak liczyc z faktem, że ponieważ Cxx nikogo nie obchodzi, to i
wsparcie niektórych konstrukcji z Cxx w C++ istnieje tylko przypadkiem o
ile w ogóle (bo nie musi). clang ma je w nosie i są robione w 4
kolejności. Clang zaś, na chwile obecną, jest nie do zignorowania w
embedded.

Można wybierać mądrze, ale można też ideologicznie.

>> W C99. A to ważne, bo C99 nikogo nie obchodzi, wliczajac w to twórców
>> współczesnych kompilatorów. Być może ma istotne znaczenie
>> archeologiczne i w zasadzie to mogło by pasować do tematu dyskusji.
> W C99 i kolejnych, współcześnie używanych.

Kolejne to tylko sterta papieru. Ich wsparcie jest zupełnie niepotrzebne
z powodu ujemnej ilości kodu planowanego w tych standardach, zerowego
zainteresowania przemysłu i niejasnych "ulepszeń", których kiedyś
szukałem i nie znalazłem w jakiś oczywisty sposób. Dreptanie w miejscu
typu "dodajmy jeszcze jedną literę do fopen, to rozwiązuje połowę
problemów ludzkości".

> Uparcie zawężasz temat do
> C99. Chodzi o to, że nowszych wersji nie używają ci mityczni embeddowcy
> więc wersje te się nie liczą?

A używasz C17? I jakie problemy z rozmiarem liczonym przez sizeof
zostały tam rozwiązane? Albo w ogóle jakieś inne?

O ile dobrze kojarzę, to w najnowszym standardzie planują dodać głównie
operacje na bitach.

Zaś w poprzednich (C11) jest wiele rzeczy z C++, tylko zrobionych inaczej.

Po co ten ezoteryczny język komukolwiek potrzebny? Wychodzi na to, że
nie tylko ja zadaje sobie to pytanie, sądząc po ilości przemysłowego
kodu napisanego w C++xx vs Cxx.

do góry

On 23/05/2023 17:26, titanus wrote:
>> 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.
> Ależ mi nie chodzi o obiektowość, czy rodzaj interfejsu UI, czy nawet
> nie chodzi o to w jakim języku go napisano...

Mimo to Amiga OS jest obiektowy, przynajmniej częściowo. I to, co
najzabawniejsze, w ogóle nie zależnie od języka programowania. W asm też
się dało pisać z BOOPSI obiektowe aplikacje. W tym momencie embedowcom
trzeba chyba podawać tlen.

> Chodzi o to, że na tamten sprzęt "skrojono" programowo niemal wszystko
> "na wymiar", a "embedowcy" potrafili wycisnąć z niego niemal siódme
> poty. Jednym zdaniem: soft skrojony do hadware'u.

Amiga OS jest już na granicy OSa uniwersalnego, gdzie abstrakcja na
hardware jest prawie kompletna.

Z każdą nastepna wersją stawał się coraz mniej skrojony na miarę a coraz
bardziej uniwersalne. Amiga bez problemu obsługiwała tym samym OSem inne
karty gfx, dzwiękowe, dodatki typu MMU itd itp. Nie, ten system nie był
skrojony na miarę, był na granicy takiego.

> Teraz do oprogramowania - NIEZALEŻNIE JAKIEGO - dorzuca się rzeczy
> zbędne, wrogie użytkownikowi a czasem tak bzdurne, że szkoda słów.
> I nie myślę tu tylko o OS'ach, ROMACH czy aplikacjach. Dzisiaj kod jest
> przeważnie śmietniskiem i wylęgarnią wszelkiego crapu.

Dobrze wiedzieć.

I dobrze też przeciwdziałać. Zamiast produkować tony krapu w C można
najzwyczajniej napisać przejrzysty kod w wyższym poziomie abstrakcji.
Czy to będzie C++ czy Rust, to drugorzędne.

Krap można pisać wszędzie. Są jezyki w których robi się to trudniej.
Obecny zwrot z C(++) do Rust świadczy o tym, że w głowach wielu ludzi
zaczeło kiełkować, że jednak uniwersalny asembler to niekoniecznie
najlepsze narzędzie do pisania aplikacji z tysiącami kloc.

Prawdopodobnie wynika to z odchodzenia starych ideologów C na emeryturę.
Bo z własnej woli Rust'a by nie tknęli kijem.

>>> 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.
>> Obecnie też pracuje dobrze.
> Pozwolę się nie zgodzić: eskalacja kodu jest pomiędzy tamtymi a obecnymi
> czasami już nie liniowa a logarytmiczna - i to nie w dobrym kierunku.

Wyjaśnij przyczynę.

Mogę migać diodą w C++ w takiej samej ilości instrukcji asm kodu
wynikowego co w C. Nic tu nie rośnie.

Co rośnie i dlaczego?

>> 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.
> No nie - to problem sprzętu nienadążającego za stale rosnącymi
> zapotrzebowaniami oprogramowania.

Sprzęt, w szczególności układy specjalizowane grafiki, są obecnie
wielokrotnie szybsze niż przeciętnej karty Trident czy amigowego
Blittera. Biorąc w poprawkę cały postęp w rozdzielczości i głebokości
kolorów.

Hardware jest super szybkie.

A natywne bibliteki, jak Qt, korzystają z tego całymi garściami.

Sugeruje odpalić demka z Qt, płynnośc i responsywnośc wgniata w podłogę.

Oczywiście do pierwszego imbecyla robiącego "for (;;)" w onkliku. Tutaj
szukaj przyczyny. Nie ilość danych, nie język, a najzwyczajniej
niepojmowanie jak się pisze aplikacje responsywne, powoduje wrażenie
spowolnienia.

do góry

heby <h...@p...onet.pl> napisał(a):
> Bo w C go nie ma. Jest w C99 lub C++. Przy czym ten w C99 to takie
> śmieszne coś.

C99 to też C. Możesz go uważasz za śmieszny, ale taki standard języka C
został wydany. Podobnie jak zarówno C++98 i C++23 to C++.

>> C99 to też C. Tak samo C++ ma kolejne wersje.
> I dlaczego należy wybrać Cxx zamiast C++xx? Masz jakieś merytoryczne
> argumenty?

Nic nie pisałem o wybieraniu więc nie mam czego argumentować. Ale skoro to
poruszasz, to wolę C++ niż C.

> Kolejne wersje nie są tutaj dyskutowane, drogi Sherlocku.

Widzę, że tak sobie wymyśliłeś, ale nie wiem dlaczego.

> Kolejne to tylko sterta papieru.

Ale jest to tak samo C jak C90, C11 i inne wersje.

> A używasz C17?

Tak, używam.

> I jakie problemy z rozmiarem liczonym przez sizeof zostały tam rozwiązane?
> Albo w ogóle jakieś inne?

To nie ma znaczenia. Ja nie dyskutuję która wersja jest lepsza. Z jakiegoś
powodu wybrałeś sobie jakąś wersję C (nadal nie wiadomo nawet którą i
dlaczego) a inne arbitralnie odrzucasz bo tak.

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

do góry