eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaDziwny problem z kodem w C (gcc mips/pic32)
Ilość wypowiedzi w tym wątku: 171

  • 161. Data: 2023-05-23 19:15:32
    Temat: Re: Dziwny problem z kodem w C (gcc mips/pic32)
    Od: heby <h...@p...onet.pl>

    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.


  • 162. Data: 2023-05-23 19:28:57
    Temat: Re: Dziwny problem z kodem w C (gcc mips/pic32)
    Od: "Grzegorz Niemirowski" <g...@g...net>

    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/


  • 163. Data: 2023-05-23 19:50:12
    Temat: Re: Dziwny problem z kodem w C (gcc mips/pic32)
    Od: heby <h...@p...onet.pl>

    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ć?


  • 164. Data: 2023-05-24 00:42:01
    Temat: Re: Dziwny problem z kodem w C (gcc mips/pic32)
    Od: JDX <j...@o...pl>

    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? :-)


  • 165. Data: 2023-05-24 07:27:09
    Temat: Re: Dziwny problem z kodem w C (gcc mips/pic32)
    Od: heby <h...@p...onet.pl>

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


  • 166. Data: 2023-05-24 11:16:31
    Temat: Re: Dziwny problem z kodem w C (gcc mips/pic32)
    Od: io <i...@o...pl.invalid>

    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.


  • 167. Data: 2023-05-24 11:53:48
    Temat: Re: Dziwny problem z kodem w C (gcc mips/pic32)
    Od: heby <h...@p...onet.pl>

    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.


  • 168. Data: 2023-05-24 12:45:08
    Temat: Re: Dziwny problem z kodem w C (gcc mips/pic32)
    Od: Janusz <j...@o...pl>

    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


  • 169. Data: 2023-05-24 12:46:47
    Temat: Re: Dziwny problem z kodem w C (gcc mips/pic32)
    Od: heby <h...@p...onet.pl>

    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?


  • 170. Data: 2023-05-24 13:38:25
    Temat: Re: Dziwny problem z kodem w C (gcc mips/pic32)
    Od: Janusz <j...@o...pl>

    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

strony : 1 ... 10 ... 16 . [ 17 ] . 18


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: