On Thu, 18 May 2023 17:35:17 +0200, heby <h...@p...onet.pl> wrote:
> dobrze i bez absuradlnych błedów, jak z watku. Nie da się ich
> stosować w
> C,

Jak to się nie da, da się, wystarczy myśleć. C jest dla myślących.

--
Marek

do góry

On 18/05/2023 18:16, Marek wrote:
>> #define FOO_FLAG 1<<6
>> #define BAR_FLAG 1<<3
>> #define OUT_FLAG 1<<2
>> i funkcję:
>> void setFlags( int flags, int extra_flags );
> A może zaczniemy od tego by tak diodami nie migać, co?

Czyli jak proponujesz napisać ten kod w C aby stał się bezpieczny i nie
pozwalał na akcepację złej flagi do funkcji?

> bo jak ktoś tak miga diodami to później sam sobie tworzy (niesitniejace
> w innych sposobach) problemy, które później dzielnie musi rozwiązywać
> niczym socjalizm.

To jest cytat z nagłówka, dowolnego dostarczonego przez producenta CPU
zestawu funkcji. Na przykład do serii SAM7 Atmela, ale pełno tego wszędzie.

To nie ja piszę.

To tradycja embedded.

do góry

On 18/05/2023 18:11, Marek wrote:
>> Około 10 sekund na przeczytanie posta na usenecie, że jest std::size
>> zamiast sizeof.
> A z jakiego powodu ktoś miałby w ogóle wpaść na to żeby zamieniać
> sizeof.

Z prostych:
a) wie, że jest std::size. Ty już wiesz. Nie użyje sizeof. Po co miałby
to robić, przecież to do czego innego.
b) wcale nie potrzebuje sizeof. Potrzebuje [boost|std]::size bo taki
jest kontekst i cel użycia. To jest pierwotna potrzeba. sizeof to tylko
workaround sprzed 30 lat na brak size. Przyznaje, popularny do dzisiaj.

> jeśli ktoś w ogóle miałby świadomość że w C plus plus jest "lepiej" to
> używał by tego od samego początku.

Nie. Tutaj (w embedded) nawet jeśli ktoś wie, że jest lepiej, to nie
używa. Ideologia, z resztą typowo konserwatywna.

>  Žeby mieć taką świadomość użycia to niestety wcześniej musiałby się
> tego trochę nauczyć.

Właśnie się nauczyłeś. Za darmo. Zajęło to sekundy. Zostanie na całe życie.

Nawet jesli użyjesz tylko tej 1 konstrukcji, to dzięki temu, że masz już
C++ może nastepnym razem wpiszesz w google "jak zrobic w C++ takie coś"
i okaże się że jest to już załatwione w boost/std. Tam jest ogólnie dużo
rzeczy załatwione.

> Więc kosz nauki nie jest tutaj zerowy a tym
> bardziej ujemny.

Kosz błedu sizeof w debugu runtime wielokrotnie przekracza koszt kilku
sekund, które juz straciłeś na poznanie std::size.

do góry

On 18/05/2023 18:18, Marek wrote:
>> dobrze i bez absuradlnych błedów, jak z watku. Nie da się ich stosować
>> w C,
> Jak to się nie da, da się, wystarczy myśleć. C jest dla myślących.

Nie. C jest dla myślących o *wszystkim* na raz. C++ dla myślącym o celu
jaki chcą osiągnąć, zamiast wymyślaniu kwadratowych kół.

do góry

On Thu, 18 May 2023 18:29:02 +0200, heby <h...@p...onet.pl> wrote:
> Nawet jesli użyjesz tylko tej 1 konstrukcji, to dzięki temu, że
> masz już

W życiu tego nie użyję. Zawodowcy niech się bawią w takie herezje.


> Kosz błedu sizeof w debugu runtime wielokrotnie przekracza koszt
> kilku
> sekund, które juz straciłeś na poznanie std::size.

Nie mailem żadnego kosztu tego buga, bo jego obejscie zajęło sekundę,
po prostu wyłaczylem kod, gdzie występował. Proste i banalne. Nie
programuje zawodowo dla samego programowania. Programowanie u mnie
jest przykrą koniecznością uzyskania jakieś funkcjonalności. Robię to
zazwyczaj jednorazowo i więcej do tego nie wracam.

--
Marek

do góry

On Thu, 18 May 2023 18:30:20 +0200, heby <h...@p...onet.pl> wrote:
> Nie. C jest dla myślących o *wszystkim* na raz. C++ dla myślącym o
> celu

Nie widzę nic złego w myśleniu o wszystkim na raz. Cel można osiągnąć
bez C++, nie przesadzajmy, że C++ to jedyna droga do osiągnięcia
celu.

--
Marek

do góry

On Thu, 18 May 2023 18:19:24 +0200, heby <h...@p...onet.pl> wrote:
> Czyli jak proponujesz napisać ten kod w C aby stał się bezpieczny i
> nie
> pozwalał na akcepację złej flagi do funkcji?

Prosto.


> To jest cytat z nagłówka, dowolnego dostarczonego przez producenta
> CPU
> zestawu funkcji. Na przykład do serii SAM7 Atmela, ale pełno tego
> wszędzie.

Śmierć frajerom.

--
Marek

do góry

On 18/05/2023 18:44, Marek wrote:
>> Nawet jesli użyjesz tylko tej 1 konstrukcji, to dzięki temu, że masz już
> W życiu tego nie użyję. Zawodowcy niech się bawią w takie herezje.

Innymi słowy wybirasz kijek a nie siekierkę.

Masz prawo.

>> Kosz błedu sizeof w debugu runtime wielokrotnie przekracza koszt kilku
>> sekund, które juz straciłeś na poznanie std::size.
> Nie mailem żadnego kosztu tego buga, bo jego obejscie zajęło sekundę, po
> prostu wyłaczylem kod, gdzie występował.

To po co ten kod był skoro wyłączenie było możliwe?

> Proste i banalne.

Ale zdajesz sobie sprawę, że sizeof()/sizeof() to jest powszechnie
używany workaround i koszta jego obsługi są wieksze, niż w prostym,
hobbystycznym przykładzie?

Jesli to miganie diodami, dla potrzeb hobbystycznych, to nie ma
problemu. Uzywaj co uważasz za słuszne.

Problemy są w większej skali, gdzie takie konstrukcje kosztują konkretne
pieniądze po stronie firm, przepalane na debugowanie w kółko tych samych
błedów.

> Nie
> programuje zawodowo dla samego programowania.

Zawodowcy też nie programują dla programowania. Programują dla
pieniędzy. Dlatego szukają metod, aby ich programowanie było
efektywniejsze - wtedy zarobisz więcej. C++ to jedna z takich metod.

> Programowanie u mnie jest
> przykrą koniecznością uzyskania jakieś funkcjonalności. Robię to
> zazwyczaj jednorazowo i więcej do tego nie wracam.

Tym bardziej polecam ucieczkę z C do czegoś bardziej abstrakcyjnego.
Ostatnio popularny jest microPython.

do góry

On 18/05/2023 18:46, Marek wrote:
>> Nie. C jest dla myślących o *wszystkim* na raz. C++ dla myślącym o celu
> Nie widzę nic złego w myśleniu o wszystkim na raz.

Co jest biegunowo odległe od branzy języków programowania, które od
dziesiątek lat staraja się, aby programista nie myślał o wszystkim,
tylko myślał o celu, coraz to wymyslając nowe paradygmaty, składnie,
języki, coraz to bardziej abstrakcyjne.

C++ to pikuś w porównaniu z wieloma innymi abstrakcjami, jak Clojure.

> Cel można osiągnąć
> bez C++, nie przesadzajmy, że C++ to jedyna droga do osiągnięcia celu.

To myślenie to "Turing completeness". Jest typowym argumentem który ma
się nijak do rzeczywistości. Napisanie dowolnego algorytmu w dowolnym
języku jest możliwe. No i co z tego?

Problem w tym, że chcemy to robić wydajniej, szybciej, redukując błedy,
koszta itd itp.

Tak, wszystko można napisać w C. Prosze jednak, aby tego nie robić. Są
lepsze sposoby wqrwiania ludzi, niż wyciąganie trupa z szafy.

do góry

On 18/05/2023 18:47, Marek wrote:
> On Thu, 18 May 2023 18:19:24 +0200, heby <h...@p...onet.pl> wrote:
>> Czyli jak proponujesz napisać ten kod w C aby stał się bezpieczny i
>> nie pozwalał na akcepację złej flagi do funkcji?
> Prosto.

Nie da się w prosty sposób. Ten język nie dysponuje niczym na poziomie
kontroli składni kodu usera poza popsutym preprocesorem.

Widziałem zrobione to na makrach.

Nie działało dobrze, ale za to zajmowało kilkadziesiąt kB makr.

Wynajdywanie popsutego C++ jest typowym zagadnieniem w embedded.

>> To jest cytat z nagłówka, dowolnego dostarczonego przez producenta CPU
>> zestawu funkcji. Na przykład do serii SAM7 Atmela, ale pełno tego
>> wszędzie.
> Śmierć frajerom.

Mam najdzieję, że nie pracujesz zawodowo z czymkolwiek majacym nawet
odległy związek z programowaniem rzeczy niebezpiecznych.

do góry