W dniu 2022-07-21 o 15:06, Janusz pisze:

> Szablony tak, ale polimorfizm dynamiczny już nie, tzn pójdzie bo będzie
> de fakto statyczny czyli stałe procedury wygenerowane na każdą
> okoliczność wsadzone w rom.

Nie wiem co się dokładnie kryje pod pojęciem polimorfizmu dynamicznego,
ale funkcje wirtualne w kasach w C++ to na tyle na ile to rozumiem to
zawsze są generowane na każdą okoliczność i wkładane do programu nawet
jak jest to program na komputer a nie na mikrokontroler.
Chyba, że kompilator widzi, że żaden obiekt danej klasy pochodnej nigdy
nie jest tworzony to wtedy takie opisane w kodzie źródłowym funkcje tej
kasy mogą nie wejść do programu wynikowego.

> Tyle że ten sam efekt osiągam pisząc sobie sam specjalizowane funkcje na
> każdy rozdzaj argumentu, więc po co sie kopać z koniem czyli
> kompilatorem i wymyślać mu szablony czy przeciążenia argumentów? Co ma
> sens dla dużych procków i zespołów ludzi niekoniecznie ma sens dla
> małych i pojedynczych autorów.

W okolicy 1990 nie znając jeszcze C++ pisałem (mały zespół - 1 ludź)
program do naszego programatora GALi (ten sam co opisałem jego wnętrze z
Forth) i tak bardzo potrzebowałem wołania pod tą samą nazwą różnych
funkcji bo najpierw się wybierało rodzaj programowanego obiektu, a potem
dla każdego były wywoływane te same funkcje (programu, odczytaj, skasuj,
blankcheck) które dla każdego trzeba było inaczej zrealizować że
zaimplementowałem to za pomocą wskaźników na funkcje.

Jak potem po raz pierwszy czytałem o C++ (mój pierwszy kontakt to
książka Stroustrupa z 91 roku w oryginale) to widząc funkcje wirtualne
pomyślałem - dokładnie to było mi potrzebne.

Więc nie zgodzę się z Tobą, że pewne rzeczy pozwalające czytelniej
napisać program są tylko dla dużych.
Ale nigdy nie nauczyłem się używać templates. One jakoś są dla mnie
mniej czytelne niż klasy.
P.G.

do góry

On 21/07/2022 15:01, Piotr Gałka wrote:
> To wiem. Ale mógłbyś mieć więcej tolerancji gdy ktoś się walnie i potem
> nie umie się z tym pogodzić.

Przyjmuje do wiadomości.

> Brat niedawno nie zostawiał suchej nitki na jakimś przykładowym
> programie USB dla tego Silabsa. Jak pisałeś o metodach znanych od lat
> 80-tych oddzielenia kodu od hardware'u to miałem wrażenie, że ten
> program co mu się tak bardzo nie podobał to pewnie był napisany według
> tych metod.

Zakładałeś, że mógł nie zrozumieć idei?

Codziennie muszę walczyć z takim podejściem w sobie: wydaje mi się że to
jest źle napisane. Ale jednoczesnie wiem, nie pisali tego idioci. Na sam
koniec zazwyczaj okazuje się, że nie rozumiałem i jak zrozumiałem, to
już się takie nie wydaje.

Ten pierwszy odruch "przeciez to jest źle!" należy w sobie zdusić ;)

> swój kawałek do którego przydzielone są np. 3 nogi i program pisze tak,
> jakby pozostałych nóg nie było. Pewnie użył jakąś bibliotekę gdzie ktoś
> zdefiniował jakąś abstrakcję obejmującą te 3 linie i ma w dupie co się
> dzieje naokoło - Jak można tak pisać !!

Tutaj dam ci kontrprzykład:

Taki kod: Foo = 1<<BAR;

Jaką masz pewnośc, że BAR to numer bitu a nie wartość binarna bitu? Obie
to int. Obie się skompilują.

Ktoś może powiedzieć: ale to trzeba wiedzieć!

Nie. Kiedy pisałem sporo kodu pod SAM7, programiści z Atmela mieli
bardzo swobodne metody na nazywanie wartości binarnych i numerów bitów i
*nigdy* nie było wiadomo. Czarę goryczy przelały pliki konfiguracyjne do
cpu, gdzie raz było #define BAR 16 a w innym, podobnym, #define BAR 4
(najwidoczniej ktoś poprawił).

Ten problem da się rozwiązać za pomocą C++ i szablonów. W taki sposób,
że błedne użycie NIE będzie możliwe. Kod szablonowy będzie dośc długawy,
ale na sam koniec będziesz to widział u siebie jako Foo |= BAR; lub
podobnie. Ba, nie będzie się dało pomylić rejestru, flagi będa
przypisane do konkretnego.

Czy to dobrze?

Okazuje się że nie.

Przychodzi embedowiec, widzi te wszystkie "debilizmy z templates" i
biadoli ile to kodu w CPU zjada i dlaczego nie działa z Harvardem.

A zjada 0 Flasha. Tak naprawdę, to "kod templaetowy" wykonuje się na
etapie kompilacji, jako metajęzyk.

... po czym miesiąc szuka kodu, w którym pomylił flagę.

Czasami ciezko pojąć, że ludzie wkręcają śrubki młotkiem, ale tak to
wygląda z mojej perspetkywy.

do góry

On 21/07/2022 14:59, Janusz wrote:
>> Rzecz w tym, że nie masz pojęcia o czym mówisz.
> Widziałem te twoje wypociny, daruj sobie.

I co, nie działają?

do góry

W dniu 2022-07-21 o 14:17, Piotr Gałka pisze:
> W dniu 2022-07-21 o 12:53, Janusz pisze:
>> W dniu 2022-07-21 o 09:28, heby pisze:
>>> On 21/07/2022 09:20, Janusz wrote:
>>>>> Zaraz po tym jak określisz dlaczego dynamiczny polimorfizm działa
>>>>> na moim Harvardzie.
>>>> A w którym miejscu napisałem że nie może?
>>>
>>> Tutaj:
>>>
>>> On 19/07/2022 18:35, Janusz wrote:
>>>  >> Jak to zaprząc do realizacji różnych funkcji przez każdą kopię (nie
>>>  >> wiem jak to się nazywa) tego templates.
>>>  > Ale na avr-ze to nie pójdzie bo ten procek nie wykonuje programu z
>>> ram-u
>>>  > (architektura Harvard) więc żadnej kopi nie uruchomi.
>>>
>>> Co prawda dotyczy to statycznego, ale tym gorzej dla Ciebie.
>> Co gorzej, odpowiedz na pytanie, czy avr wykona program z ramu?
>>
>
> Janusz,
> sorry, ale dzielnie bronisz pozycji nie do obrony.
>
> Kluczowe słówko: 'bo'.
> Kwestia nie wykonywania z RAMu była użyta tylko jako wytłumaczenie
> dlaczego do głównej tezy, że program wygenerowany z templates nie
> pójdzie w avr.
Bo to co robi kompilator na avr to jest proteza, skoro nie da się kodu
modyfikować podczas wykonania to robimy kody na każdy argument, osobne.
Więc niby masz narzędzie ale de fakto to samo miałeś wcześniej pisząc
sobie sam
funkcje. Narzędzie jedynie 'ukrywa' przed tobą typ argumentu, wołasz raz
a kompilator sam dobiera ścieszkę. W '86 nie trzeba takich protez robić
bo kod może być zmieniany podczas wykonania programu.

> Chodzi o prawdziwość/nie prawdziwość tej głównej tezy a nie użytego
> argumentu za nią.
>
> Skojarzenie....
> Kiedyś (+- 1990) potrzebowaliśmy aby 8751 'wykonywał' program ze swojego
> RAMu (128 bajtów).
> Zrealizowaliśmy to jako interpreter programu pisanego w opracowanym
> przez nas języku na bazie języka Forth (opiera się na odwrotnej notacji
> Polskiej).

czyli zrobiliście maszynę wirtualną.


--
Janusz

do góry

W dniu 2022-07-21 o 15:34, heby pisze:
>
> Zakładałeś, że mógł nie zrozumieć idei?

Mógł. Bo dopiero pierwszy raz widzi cokolwiek na ten procesor.
Ale ogólnie to chyba mniej więcej ogarnął co autor miał na myśli.
Ta rozmowa była ponad tydzień temu. Od tamtej pory cały czas się grzebie
w tym i mam mu nie przeszkadzać, bo czas nas goni.
Niestety akurat w kwestii USB tak mało wiem, że nie potrafię nic
szczegółowo.
Jak lata temu czytałem specyfikację USB (wtedy jeszcze nie było 3) to
nie wyobrażałem sobie to ogarnąć. Od strony komputera jakoś łączę się z
naszymi urządzeniami z naciskiem na 'jakoś'.

Przy okazji takie pytanie o przykład.
Jakieś 5 lat temu próbowałem rozwiązać jakiś mój problem z GUID i
poległem. Problem polega na tym, że nie jestem pewien o co chodziło więc
mogę źle napisać.

Ja normalnie robię tak, że klasa urządzenia USB ma funkcję statyczną
wyszukującą urządzenia tego typu.

Dokładnie wygląda to tak (przepisuję ręcznie z drugiego komputera):

int Usb485::FindDevs()
{
GUID g= {0x42C884DE, 0xCC54, 0x4014, {0x88, 0x99, 0xAA, 0xBB, 0xCC,
0xDD, 0xEE, 0xFF}};
return DevTab.FindDevs(g);
}

88,99,... to fałszywe wartości

Próbowałem w jakiś inny sposób definiować ten GUID - jako ciąg bajtów -
chyba nie byłem w stanie.

Chciałem móc przekazać GUID jako parametr konstruktora - chyba mi się
nie udało.

Tak na prawdę to nie wiem co chciałem i na czym poległem (za dawno było).
Pamiętam jedynie, że wniosek był - tylko tak to mi działa.

Wiedząc jak robię czasem inne klasy to zapewne:

- chciałem mieć klasę bazową, która ma GUID jako parametr konstruktora.
- ona ma funkcję FindDevs która korzysta z tego guid z konstruktora.
- konstruktor klasy pochodnej woła konstruktor klasy bazowej wpisując
tam znany już w tym miejscu swój guid.
- klasa pochodna ma dostępną funkcję FindDevs klasy bazowej i ona umie
użyć tego guid wpisanego w jej konstruktorze.

To chyba jest to, co mi się nie udało i w każdej klasie pochodnej mam
jej własną statyczną FindDevs.

Nie pamiętam, gdzie się pojawia problem. Jakiekolwiek próby najwcześniej
poniedziałek Dziś jeszcze nie wziąłem się za dokończenie płytki, która
dziś mam skończyć, a jutro jest wyjątkowy dzień - coś załatwiamy i nie
będzie czasu.

> Taki kod: Foo = 1<<BAR;

Od lat 90-tych widuję te foo i bar i nigdy nie wiem co o tym sądzić.
Skąd się to wzięło i jak o tym mysleć.

> A zjada 0 Flasha. Tak naprawdę, to "kod templaetowy" wykonuje się na
> etapie kompilacji, jako metajęzyk.

Na razie o ile wiem to według brata przykład USB na załatwienie prostej
rzeczy zabiera 10x za dużo miejsca i nie zostaje miejsca na naszą
aplikację, a chcemy się zmieścić w 1/2 flasha z powodu upgrade'ów.
P.G.

do góry

W dniu 2022-07-21 o 15:34, heby pisze:
> On 21/07/2022 14:59, Janusz wrote:
>>> Rzecz w tym, że nie masz pojęcia o czym mówisz.
>> Widziałem te twoje wypociny, daruj sobie.
>
> I co, nie działają?
Nie wiem, nie mam takiej potrzeby ich używania.
Jak już coś pisze to piszę prosty kod zrozumiały dla mnie.


--
Janusz

do góry

W dniu 2022-07-21 o 16:25, Janusz pisze:

> Bo to co robi kompilator na avr to jest proteza, skoro nie da się kodu
> modyfikować podczas wykonania to robimy kody na każdy argument, osobne.

Prawie na pewno się mylisz. Funkcje wirtualne nigdy nie są realizowane
poprzez modyfikowanie kodu w RAMie.

> Więc niby masz narzędzie ale de fakto to samo miałeś wcześniej pisząc
> sobie sam
> funkcje. Narzędzie jedynie 'ukrywa' przed tobą typ argumentu, wołasz raz
> a kompilator sam dobiera ścieszkę. W '86 nie trzeba takich protez robić
> bo kod może być zmieniany podczas wykonania programu.

Z tego co pamiętam (Stroustrup pisał jak jego funkcje wirtualne mają być
implementowane) to nie jest do tego wykorzystywane modyfikowanie kodu
podczas pracy programu.
P.G.

do góry

W dniu 2022-07-21 o 15:21, heby pisze:
> On 21/07/2022 15:06, Janusz wrote:
>> Szablony tak, ale polimorfizm dynamiczny już nie, tzn pójdzie bo
>> będzie de fakto statyczny czyli stałe procedury wygenerowane na każdą
>> okoliczność wsadzone w rom.
>
> To *jest* polimorfizm dynamiczny, kiedy kod *jest* wygenerowany przez
> kompialtor ,a całośc procesu sterowania nim odbywa sie przez indirect call.
Przecież statyczny jest tak samo wywoływany, nie tu tkwi różnica, ale
brnij dalej.

>
> Myslisz to z "kodem dynamicznym" albo "kodem samomodyfikującym" który
> nie ma z tym nic wspólnego.
Polimorfizm dynamiczny na dużych maszynach był tak osiągany, czy teraz
to nie wiem bo dawno w kod nie zaglądałem, pewnie ze względów
bezpieczeństwa już tak nie robią
tym bardziej że wielkość pamięci przestałą być krytyczna.


--
Janusz

do góry

W dniu 2022-07-21 o 15:34, heby pisze:
> ... po czym miesiąc szuka kodu, w którym pomylił flagę.
To chyba o sobie piszesz :) bo ja już trochę programów napisałem i nie
miałem takiego problemu. Może dlatego że zamiast szablonów to używam
struktur np bitowych gdzie mam wszystko jasno opisane, ale wiem szablony
sa lepsze :)

--
Janusz

do góry

On 21/07/2022 16:25, Piotr Gałka wrote:
> Chciałem móc przekazać GUID jako parametr konstruktora - chyba mi się
> nie udało.

Czy GUIDy są zmienne? Pisałeś o statycznych.

To miejsce na tempaltes, jesli są statyczne.

> Tak na prawdę to nie wiem co chciałem i na czym poległem (za dawno było).
> Pamiętam jedynie, że wniosek był - tylko tak to mi działa.
> Wiedząc jak robię czasem inne klasy to zapewne:
> - chciałem mieć klasę bazową, która ma GUID jako parametr konstruktora.

class KlasaBazowa {
public:
KlasaBazowa( GUID const& _guid ) : m_guid( _guid );
[...]
private:
GUI const& m_guid;
};

> - ona ma funkcję FindDevs która korzysta z tego guid z konstruktora.

Więc w tej funkcji masz m_gui który jest typu GUID i o wartości jaką
przekazano do konstruktora klasy bazowej.

> - konstruktor klasy pochodnej woła konstruktor klasy bazowej wpisując
> tam znany już w tym miejscu swój guid.

static GUI konkretnyGUID = { };

class KlasaKonkretna : public KlasaBazowa {
public:
KlasaKonkretna() : KlasaBazowa( konkretnyGUID ) { [...] };

[...]
};

Zaznaczam, że to nie jest optymalne. Tracisz 4 bajty na pole m_guid.

Poprawnie było by to zrobione za pomocą szablonów i techniki mixin.
Klasa bazowa nie musiała by wtedy trzymać GUIDa, ale mogła by z niego
korzystać dzięki specjalizacji szablonem.

> - klasa pochodna ma dostępną funkcję FindDevs klasy bazowej i ona umie
> użyć tego guid wpisanego w jej konstruktorze.

Tak jak powyżej.

> To chyba jest to, co mi się nie udało i w każdej klasie pochodnej mam
> jej własną statyczną FindDevs.

Hmmm... całośc tego wydaje mi się niejasna, co w zasadzie było problemem.

Niewątpliwie ten kod przydałby się w wersji invitro aby móc coś wiecej
dysputować.

>> Taki kod: Foo = 1<<BAR;
> Od lat 90-tych widuję te foo i bar i nigdy nie wiem co o tym sądzić.

To metasłowa. Może być GORZAŁKA i ZAGRYCHA.

> Skąd się to wzięło i jak o tym mysleć.

Nijak. Programiści musza czasami pokazać składnię czegoś w oderwaniu od
konkretów. Używa się też "spam", "Alice" i kilku innych.

https://en.wikipedia.org/wiki/Foobar

>> A zjada 0 Flasha. Tak naprawdę, to "kod templaetowy" wykonuje się na
>> etapie kompilacji, jako metajęzyk.
> Na razie o ile wiem to według brata przykład USB na załatwienie prostej
> rzeczy zabiera 10x za dużo miejsca i nie zostaje miejsca na naszą
> aplikację, a chcemy się zmieścić w 1/2 flasha z powodu upgrade'ów.

Gcc ma flagę -Os? Symbole debugowe wyłaczone w docelowej binarce?

Raczej nie dam wiary, że jest tak źle. Prosty kod usb UARTa na STM32
zajmował jakies kilobajty. Ba, w małym AVR potrafili to zmieścić, z
softwareową emulacją.

do góry