On 19/07/2022 18:21, Piotr Gałka wrote:
>> Tak. To statyczny polimorfizm. Wykonuje się go w C++ za pomocą
>> templates. Dokładnie tak jak opisujesz - umożliwia np. rozdzielenie
>> implementacji hardwareowej UART od kodu implementującego protokół bez
>> ani jednej nadmiarowej  instrukcji asm.
> Chyba muszę jeszcze raz poczytać o templates. Dotychczas rozumiałem, że
> to się głównie nadaje do opisania tego samego typu działań realizowanych
> na różnych typach zmiennych.

To prymitywna wersja templates. Z lat 90. Od tamtego czasu przeszliśmy
długą drogę.

> Dla każdego typu zmiennych powstaje osobny
> kod (ale robi w sumie to samo tylko uwzględnia tym zmiennych).
> Jak to zaprząc do realizacji różnych funkcji przez każdą kopię (nie wiem
> jak to się nazywa) tego templates.


Tak:

template< class _HardwreUartImplementation >
ModBusProtol {
...
}

Raz w kodzie msz wtedy:

ModBusProtocol< STM32UART0 > modbus;

albo

ModBusProtocol< AtmegSoftwarUartImpl > modbus;

albo, co najważniejsze:

ModBusProtocol< UartMock > modbus;


> Jak to zaprząc to machania na innej nodze gdy LED jest gdzie indziej
> podłączony.

Dostarczyć inna klasę, implementująca "setState( bool )" w inny sposób,
jako parametr szablonu klasy Blinker<>. Blinker może też przyjąc inną
klasę jak paramter, na przykłąd implemetacje timera, Albo trzeci,
decydujący o kontroli wypełnienia.

Klasy akceptują klasy jako parametry = i dzięki temu budujesz swój kod
niejako z bloków. Kompilator, po rozwiązaniu wszystkich templaces widzi
jeden wielki spagetti kod, który slicznie optymalizuje i po tych
wszystkich machlojkach nie ma śladu w kodzie wynikowym.

>> To się też da zrobić dynamicznym polimorfizmem (polimorficzne klasy z
>> metodami wirtualnymi), ale ktoś może marudzić, że to zajmuje cenne
>> cykle zegarowe na indirect call. Dlatego istnieje też polimorfizm
>> statyczny, który nie generuje dodatkowego kodu.
> To chyba nie tyle chodzi o czas na indirect call co o wkładanie do kodu
> tylko tego co potrzeba.

Czasami chodzi. Ludzie w embedded mają fobie związane ze słowem virtual,
czasami jest podnoszone, że jest "niebezpieczne". Przyjmuje to do
wiadomości, ale od 100km nad poziomem gruntu ;)

> Jak mamy 20 pochodnych danej klasy z funkcjami wirtualnymi (wszystko
> opisane w jednym cpp) to kompilator potrafi zorientować się, że w tej
> aplikacji używana jest ta jedna klasa i nie wstawić kodu pozostałych?

To robi statyczny polimorfizm. Redukuje kod do 0.

Dynamiczny polimorfizm nie, choć nie do końca - pewne sztuczki pozwalają
kompilatorowi usuwać kod co do którego ma pewnośc, że jest niedostepny.
Wiec tak i nie. Zalezy. To skomplikowane.

> Bo jak zrobimy to w 20 plikach i będziemy ręcznie dokładać do projektu
> tylko to co potrzeba to właściwie my załatwiamy to co miało 'się załatwić'.

Ktoś tą decyzję podejmie, jaki parametr przekazać do szablonu. Jak to
zrobić, zalezy. Może być ifdef, jeśli jest potrzeba.

Nie dostrzegasz koncepcji: nie ma inkludowania przypadkowych plików,
bazując na katalogu w którym jesteś, aby emulować statyczny polimorfizm.
To jest już bardzo duży postęp.

>> Napisałeś, że nie możesz używać C++ bo używasz Buildera. A po co
>> używac Buildera?
> Używam C++. Nie mogę użyć C++ 11.

Statyczny polimorfizm nie wymaga C++11.

> Używam Buildera 5 bo go kiedyś kupiliśmy i załatwia mi (łatwo i w znany
> mi sposób) interfejs użytkownika.

Rozumiem, że zaleta jest w łatwym do ogarnięciu GUI?

> W pakiecie z Builderem 2010 jest jakaś biblioteka komunikacji przez
> internet, którą z wielkim trudem udało mi się (z 8 lat temu - już nic
> nie pamiętam) na tyle ogarnąć, aby się po UDP z naszymi urządzeniami
> komunikować. Jakieś udane próby TCPIP też chyba robiłem, ale nie
> rozumiem całej tej koncepcji z serwerami z komunikacją z wieloma
> chętnymi. Nie miałem musu tego robić, bo ja nie piszę aplikacji dla
> ludzi tylko tak na prawdę nasze programiki testowe.

Z dwóch powyższych wnosze, że to raczej prototypowanie, a nie programowanie.

Obecnie używanie do tego celu C++ mija się z celem.

Python?

> Jak nie używać Buildera to napisz mi co mam używać.

Nie wiem co w nim używasz. Niestety czas RADów, czyli "wyklikaj mi
onClicka" już mija, ten sposób pisania nie sprawdził się, słabo się
skaluje i wręcz narzuca błędy projektowe. Współczesne środowiska do
tworzenia GUI są inne. Nie będziesz zadowolony.

> Ale nie chcę się zajmować samemu tworzeniem interfejsu użytkownika
> (dawno dawno temu, używając Turbo C++ 1.0, pisałem swoją obsługę okienek
> pod DOS).

Nikt go nie robi ręcznie. Rzecz w tym, że środowiska do pisania GUI
odsunely się od koncepcji onClicków z Delphi i stały się czymś w rodzaju
dodatku do pisania kodu a nie kodem samym w sobie.

QtCreator na przykład.

Nie spodoba Ci się.

Nie mam rozwiązania tej bolączki. Może poza zmianą stylu pisania na
poprawny ;)