On 19/07/2022 20:08, Piotr Gałka wrote:
>> albo, co najważniejsze:
>> ModBusProtocol< UartMock > modbus;
> Nie rozumiem dlaczego napisałeś, że najważniejsze.

Bo testowanie własnego kodu invitro, unittestami, jest waznym etapem
pisania jakiegokolwiek kodu, z miganiem diodą włacznie.

> Czy STM32UART0, AtmegSoftwarUartImpl i UartMock to pochodne
> _HardwreUartImplementation ?

W templates "nie muszą być pochodne". Zgodnośc interfejsu badana jest
podczas wypełniania szablonu. Jeśli tylko jakaś klasa ma metodę foo() i
ktoś chce ją zawołać w momencie specjalizacji szablonem, to zadziała. W
dynamicznym polimorfizmie musisz dodawać wartwę interfejsu z metodami
wirtualnymi. W statycznym nie. Można by powiedzieć, że statyczny
polimorfizm bazuje na "opóźnionej kompilacji, do ostatniej chwili, kiedy
już wszystki wiadomo"

>> 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 ;)
> Z innej wypowiedzi zrozumiałem, że virtual w ogóle nie da się jak kod
> jest wykonywany z flasha.

Bzdura. Stosowny przykład podałem kilka postów wyżej.

> Ale nie wiem czy na pewno. Przecież zestaw
> wskaźników na funkcje wirtualne danej klasy może być w flashu. Obiekt
> danej klasy znajdujący się w RAMie może mieć wskaźnik na tę tabelkę
> wskaźników więc może wywołać odpowiednią dla siebie funkcję. Jak nawet
> wywołamy według wskaźnika na obiekt to też sobie to znajdzie.

Bo to bzdura. Wirtualizacja działa na praktycznie wszyskich procesorach,
od 6502 po współczesne. Jeśli gdzies nie działa, to będzie jakiś
wyjątkowy wyjątek.

>> 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.
> O includowaniu pisałem jako właśnie o złym rozwiązaniu w sytuacji, gdy
> próbujemy dynamicznego polimorfizmu

Dynamiczny jest w embedded troche niepotrzebny. On jest przydatny kiedy
programujemy obiektowo. W malym embedded potrzeba obiektowości jest
sporadyczna.

>> Statyczny polimorfizm nie wymaga C++11.
> Temat C++11 pojawił się w temacie mojego popróbowania innych nowych
> możliwości C++.

Jesteś ograniczony i tak Builderem oraz bratem używającym z niechęcią C.
Wątpie, aby cokolwiek z C++11 miało jakąkolwiek wartość przed RAII czy
szablonami. Nie warto. No może dla "auto" warto.

> A statyczny polimorfizm jest w temacie embedded a tam są środowiska
> dostarczane przez producentów procków więc pewnie bardziej aktualne.

Nie widuję. Statyczny polimorfizm stosowany jest w niektórych
biblitekach Arduino. Został zaakceptowany przez środowisko embedded
tylko dlatego, że nikt głośno nie powiedział, że to C++. Jak by
powiedział, to od razu by się obrazili, jak Janusz. Teraz muszą używac,
nie ma odwrotu. Pękło bredzenie o tym, jak to C++ się nie nadaje do
embedded.

> Czyli powinienem teraz przekonać brata do C++ koniecznie z templates.
> Będzie trudno :)

Nie. Za późno. Jesli mysli asemblerem, to nie przekonasz. Nie próbuj
nawet. Jesli robi dobrze to, co robi, to niech robi, to co robi.

To taka dysputa teoretyczna. Przecież obaj wiemy, że nie będziesz
zmieniał przyzwyczajeń bez powodów.

>> Nie mam rozwiązania tej bolączki. Może poza zmianą stylu pisania na
>> poprawny ;)
> Mam się obrazić? :)

Prawidłowo: ewoluować. To białko ma się dostosować do zmian w
komputerach, a nie odwrotnie.