On 18/05/2023 19:47, Marek wrote:
>> Więc nie zorzumiałeś po co to było.
> Trzabylo od razu powiedzieć, że u nas biją Murzynów. Chciałeś prosto,
> dostałeś.

Chciałem *bezpiecznie*. Może nie być prosto. Ja widziałem nieprostą
implementację w C na makrach.

> Po co komplikować proste do bólu  rzeczy?

Aby były *bezpieczne*.

Tego właśnie detalu nie pojmujesz. C++ robi rzeczy bezpieczniej niż C.
Te same i często bezkosztowo.

do góry

On Thu, 18 May 2023 19:58:38 +0200, heby <h...@p...onet.pl> wrote:
> Aby były *bezpieczne*.

Co jest niebezpieczne w moim przykładzie?
Niebezpieczne to jest właśnie przekombinowanie jak to zrobić
"lepiej".

--
Marek

do góry

On 18/05/2023 20:05, Marek wrote:
>> Aby były *bezpieczne*.
> Co jest niebezpieczne w moim przykładzie?

PA1 ^=1; ?

Wybrałeś sobie prymitywny przykład, więc niebezpieczeńśtwo jest mniejsze.

Mój był inny.

Może tak:

setupUart( F_UART_SINGLE_BIT_MULTIPLY | F_UART_CONTROL | UART_SPEED_9600 );

Ten kod zawiera błąd.

Jest - mniej więcej - podobny do faktycznego kodu w systemie, gdzie
szukałem kiedyś niedziałajacego UARTu, tylko tych flag było nascie o
bardzo różnych nazwach.

Wyjaśnię na czym polega problem:

#define UART_SPEED_9600 4
#define F_UART_SPEED_9600 (1<<UART_SPEED_9600)

Już rozumiesz? Funkcja zaakceptowała #define z i bez F_. A powinna tylko
z F_, bo tak jest zaimplemnetowana, ze przyjmuje maski a nie numery
bitów. Ta wiedza, maska czy numer bitu, nie istnieje nigdzie, bo to
prymitywny C. Ba, nawet nie wiadomo do której to fukcji są flagi. To
tylko nazwane numerki.

Nikt tego nie kontroluje, funkcja przyjmuje cokolwiek i jedyna nadzieja
w białku, które pisze kod, że się nie pomyli. Naiwna.

Takich funkcji w kodzie są setki.

> Niebezpieczne to jest właśnie przekombinowanie  jak to zrobić "lepiej".

Być może inaczej definicujesz słowo "niebezpiecznie".

Funkcjonalnośc została przerobiona tak, że nie dało się już podać flagi
bez F_ mimo, że obie były liczbami. Wymagało to napisania
kilkudziesięciu lini w C++ i zmiany z #define na class enum.

C++ pozwolił mi zatkać źródło błędu którego nie da się w sposób sensowny
zatkać w samym C z uwagi na prymitywizm wyrażania intencji.

Bezkosztowo. Podczas implementacji nie ucierpiał ani jeden mnemonik
asemblera a przy okazji znalazły się jeszcze dwa takie same przypadki
dla innych elementów systemu, gdzie pomylono flagi.

Po kilku latach pytałem jeszcze kolegi, mieli to w użyciu cały czas i
używali dla nowych funkcji.

Deklaracja dla klienta kodu zmieniał się z:
setupUart( int _flags )
na
setupUart( flags<UartFlags> _flags )

Gdzie UartFlags było wyliczniem co wolno za pomocą prostego template.
Całosc redukuje się do 1 liczby na kompilacji, jak dla C.

I tyle. Reszta nikogo nie interesowała.

Dzieki C++ jestem w stanie napisać teraz kod, który w wypadku pomylenia
flagi, zatrzyma kompilację, zamiast wesoło zrzucić problem na frajera z
debuggerem.

Rozumiesz już po co jest ten C++?

do góry

On Thu, 18 May 2023 20:23:56 +0200, heby <h...@p...onet.pl> wrote:
> PA1 ^=1; ?
> Wybrałeś sobie prymitywny przykład, więc niebezpieczeńśtwo jest
> mniejsze.

Miało być miganie diodą.


> Mój był inny.

O a teraz się wykręcasz czymś przekombinowanym na 2 strony
maszynopisu.

--
Marek

do góry

On 18/05/2023 20:30, Marek wrote:
>> PA1 ^=1;  ?
>> Wybrałeś sobie prymitywny przykład, więc niebezpieczeńśtwo jest mniejsze.
> Miało być miganie diodą.

Czyli nawet nie zrozumiałeś o co chodziło z tym "miganiem diodą".

Wyjasnie: "miganie diodą" oznacza tak prosty kod na uC, że jakakolwiek
technika napisania go jest dobra. To miejsce, gdzie C++ jest zbędny.
Całkiem sporo kodu embedded ma taki poziom komplikacji.

Co ciekawe, nawet Arduino wymusza pisanie w C++, tylko mało kto
zauważył. Uważam to za przezabawne.

Natomiast przykład, który zaprezentowałem przed chwilą i wcześniej,
dotyczy flag i ich grupowania w sposób pewny w argumentach funkcji, aby
uniemożliwić błąd.

Takich przykładów jest więcej, na przykład zwalnianie zasobów
sprzetowych z użyciem RIIA albo statyczny polimorfizm w celu testowania
kodu poza mikrokontrolerem bez utraty prędkości i kompromisów.

Do migania diodą C++ jest zbędny, choć i tak go używasz w Arduino.

do góry

W dniu 18.05.2023 o 13:29, Grzegorz Niemirowski pisze:
> Janusz <j...@o...pl> napisał(a):
>> No i co z tego, przecież to dwie osobne tablice i osobno się adresują
>> i chyba kompilator czy linkier nie ma tu błędu w adresacji?
>
> Niby osobno adresowane ale nie do końca, bo są w jednej pamięci. Jak
> wyjedziesz poza zakres jednej, to wpadniesz na drugą. To nie jest błąd
> kompilatora ani linkera ale uroki C. Błąd w kodzie polega na
> zapomnieniu, że sizeof() nie służy do zwracania liczby elementów
> tablicy. Można go użyć w tej roli tylko dla tablic o typie jednobajtowym
> (char, uint8_t itp) a nie short.
>
Aaa to o to chodzi, czyli funkcja sizeof jest po prostu do dupy i tyle.
To że są w jednej pamięci to wiem doskonale i wiem czym się kończy
nadpisanie zmiennych. Już trochę programów 'popełniłem'.

--
Janusz

do góry

W dniu 18.05.2023 o 13:05, Marek pisze:
> On Thu, 18 May 2023 12:44:11 +0200, Janusz <j...@o...pl> wrote:
>> No i co z tego, przecież to dwie osobne tablice i osobno się adresują
>> i chyba kompilator czy linkier nie ma tu błędu w adresacji?
>
> Chodzi o to, że BT namierzyłem z mapy linkera bo było zaadrasowane tuż
> przed tamtą, więc stała się podejrzaną o przepełnienie. Błedne użycie
> sizeof() powodowało przepełnienie w tym for() i wjazd na tą drugą.
Nie, ty go dobrze użyłes tylko funkcja jest źle napisana, ma błędy.
Akurat ja sie na niej nie naciąłem bo używałem swojej :) a była ona
częścią funkcji specyficznie formatującej ciąg.

> Jak widzisz wiek ma jednak  znaczenie  ;)
Nie ma, liczy się wiedza i doświadczenie, jak już będziesz miał sklerozę
taką jak ja to sie nauczysz żyć z przypominaczami.

--
Janusz

do góry

W dniu 18.05.2023 o 13:08, Dawid Rutkowski pisze:
> czwartek, 18 maja 2023 o 12:44:14 UTC+2 Janusz napisał(a):
>> W dniu 18.05.2023 o 12:18, Marek pisze:
>>> On Thu, 18 May 2023 08:55:51 +0200, Janusz <j...@o...pl> wrote:
>>>> Dla mnie trochę dziwny jest ten fragment, reason-nie wykorzystana
>>>> zmienna a komunikat (z tablicy) dwa razy wywołujesz ten sam, zmienna
>>>> status.
>>>
>>> Kod na potrzeby posta trochę uprościłem. Znalazłem dziada:
>>>
>>> unsigned short BT[300];
>>> int i;
>>>
>>> for (i=0; i<sizeof(BT);i++)
>>> BT[i] = getval(i);
>>>
>>> Analizując mapę linkera widać, że BT była umieszczona tuż przed tamtą
>>> tablicą ze wskaźnikami do stringów.
>> No i co z tego, przecież to dwie osobne tablice i osobno się adresują i
>> chyba kompilator czy linkier nie ma tu błędu w adresacji?
>
> Wykonaj kod na kartce to się dowiesz.
Guzik się dowiem, funkcja jest skopana i tyle.

> To nie turbo pascal
Wiem pisałem w nim.

> tylko C na uC - i tak się dziwię,
Cały czas teraz właśnie w nim piszę, C na małe procki.


że OP pisze tu o jakichś wyjątkach, może to w wersji mips pod jakimś
unixem.
> A chwalisz się tym asemblerem Mery 9150 - nie ma to jak używać terminala
> jako komputera, stąd się przecież wziął bodajże 8008 ;P
Masz na myśli monitor od mery? czy pulpit operatorski bo to z niego
wklepywało się te kilka komend w asemblerze. Owszem był jakiś kompilator
asemblera obsługujący monitory ale to do czegoś wiekszego się nadawało a
ja przy naprawach takich potrzeb nie miałem.

--
Janusz

do góry

czwartek, 18 maja 2023 o 21:12:57 UTC+2 Janusz napisał(a):
> W dniu 18.05.2023 o 13:08, Dawid Rutkowski pisze:
> > czwartek, 18 maja 2023 o 12:44:14 UTC+2 Janusz napisał(a):
> >> W dniu 18.05.2023 o 12:18, Marek pisze:
> >>> On Thu, 18 May 2023 08:55:51 +0200, Janusz <j...@o...pl> wrote:
> >>>> Dla mnie trochę dziwny jest ten fragment, reason-nie wykorzystana
> >>>> zmienna a komunikat (z tablicy) dwa razy wywołujesz ten sam, zmienna
> >>>> status.
> >>>
> >>> Kod na potrzeby posta trochę uprościłem. Znalazłem dziada:
> >>>
> >>> unsigned short BT[300];
> >>> int i;
> >>>
> >>> for (i=0; i<sizeof(BT);i++)
> >>> BT[i] = getval(i);
> >>>
> >>> Analizując mapę linkera widać, że BT była umieszczona tuż przed tamtą
> >>> tablicą ze wskaźnikami do stringów.
> >> No i co z tego, przecież to dwie osobne tablice i osobno się adresują i
> >> chyba kompilator czy linkier nie ma tu błędu w adresacji?
> >
> > Wykonaj kod na kartce to się dowiesz.
> Guzik się dowiem, funkcja jest skopana i tyle.

sizeof() to nie funkcja tylko operator.
Użycie nawiasów nie oznacza wywołania funkcji, for oraz if też je mają.

> > To nie turbo pascal
> Wiem pisałem w nim.

I wiesz, że sprawdza zakresy tablic w runtime, a C nie?

> > tylko C na uC - i tak się dziwię,
> Cały czas teraz właśnie w nim piszę, C na małe procki.

Na duże jest tak samo. Różnicę wnosi OS + ochrona pamięci.

do góry

W dniu 18.05.2023 o 21:29, Dawid Rutkowski pisze:

> sizeof() to nie funkcja tylko operator.
A tego to nie wiedziałem.

> Użycie nawiasów nie oznacza wywołania funkcji, for oraz if też je mają.
A nie sa czasami elementami składni?

>
>>> To nie turbo pascal
>> Wiem pisałem w nim.
>
> I wiesz, że sprawdza zakresy tablic w runtime, a C nie?
Dlatego pisałem że pisałem w nim, ale to też można było wyłączyć.

>
>>> tylko C na uC - i tak się dziwię,
>> Cały czas teraz właśnie w nim piszę, C na małe procki.
>
> Na duże jest tak samo. Różnicę wnosi OS + ochrona pamięci.
No nie różnic jest więcej, ale to tu bez znaczenia.

--
Janusz

do góry